Chapter 23 – Domain Name System (DNS) 23.2 Names for Machines

1. Chapter 23 – Domain Name System (DNS) 23.2 Names for Machines It is usually easier to refer to a machine as juniper than as 138.26.66.6 23.3 Flat Namespace ► Early ARPAnet: unique names for machines, registered with Network Information Center ► Continued until 1000 machines ► Beyond that a massive bureaucracy would have been necessary to ensure uniqueness of names ► The Domain Name System was created

2. Chapter 23 – Domain Name System (DNS) - continued 23.4 Hierarchical Names City “Athens” – Athens, AL or Athens, GA or Athens, TN … ? Specifying state removes ambiguity. 23.5 Delegation of Authority for Names If you want to start a new city and call it “Athens,” you probably need permission from the state – you will probably be allowed to do it if there is not already and “Athens” in your state. Once you have permission for the city name, you probably have the authority to name the neighborhoods. In DNS “The topmost level of the hierarchy divides the namespace and delegates authority for each division; it need not be bothered by changes within a division.”

3. 23.6 Subset Authority This can be carried down to more levels: local.group.site There is an analogy to the telephone numbering system: <area code> – <exchange> – <extension> (although in this case the highest level is written on the left).

4. In the Internet, hierarchical machine names are assigned according to the structure of organizations that obtain authority for parts of the namespace, not necessarily according to the structure of the physical network connections. Example 1: Two small departments, philosophy and foreign languages, might share a floor in the Humanities building; their domain names, pl.uab.edu and fl.uab.edu are different but they may share a single LAN and therefore have the same IP (sub)network address. Example 2: The CIS department has a large number of hosts and several LANs. All hosts have domain names with the same suffix, cis.uab.edu but their IP addresses are 138.26.64.x 138.26.65.y 138.26.66.z

5. 23.7 Internet Domain Names The Domain Name System has two, conceptually independent aspects: ■ (“abstract”) - name syntax and delegating authority over names ■ (“concrete”) - distributed computing system that efficiently maps names to addresses Section 23.7 continues with the first topic.

6. 23.7 Internet Domain Names – continued Domain name cs.purdue.edu contains three labels. This is the lowest-level domain or third-level domain. Any suffix of a label in a domain name is also called a domain: purdue.edu is the second-level domain edu is the top-level domain (labels can be up to 63 ASCII characters long; the total length of the name can be up to 255 characters long)

7. 23.8 Top-Level Domains Figure 23.1 Top-level domains

8. 23.8 Top-Level Domains - continued The domain name space can be represented by a rooted tree: Different from Comer! More later top-level domain second-level domain third-level domain merlin Figure 23.2

9. 23.8 Top-Level Domains - continued top-level domain second-level domain third-level domain The domain name of a subtree is a list of its labels, separated by periods, along the path to the root. All domain names end in . e.g. cs.purdue.edu. but the . is usually omitted in speech (not omitted in coding).

10. 23.8 Top-Level Domains - continued Conceptually, the top-level names permit two independent naming hierarchies: ■ geographic ■ organizational For the geographic scheme each country has a two-letter code e.g. us for United States Beneath this top level there are second-level domains for each state, e.g. al.us An organization can choose which way it wants to be known. In the US we mostly see the organizational structure e.g uab.edu notuab.al.us Other countries often use the geographic hierarchy e.g. bham.ac.uk for the University of Birmingham (England).

11. 23.8 Top-Level Domains - continued There is a registrar for each top-level domain, e.g. edu An organization applies to the top-level registrar for approval of a second-level domain, e.g. uab.edu A department of an organization applies to the organization administration for approval of a third-level domain, e.g. cis.uab.edu The departmental administrator may assign fourth-level domains, e.g. juniper.cis.uab.edu

12. 23.9 Name Syntax and Type A record in the domain name system specifies the domain name, and also the type of this particular record, e.g. ■ IP address of the named machine (type A) ■ mailbox (type MX – name of the machine running the SMTP server) At first we’ll use the first type for examples – other types later

13. 23.9 Name Syntax and Type - continued The syntax of a domain name does not determine what type of object is represented. gwen.purdue.edu could be an individual machine (leaf of tree), although cs.purdue.edu Is a non-leaf domain, with numerous machines under it.

14. Comer’s example: machine gwen.purdue.edu. gwen One cannot distinguish the names of subdomains from the names of individual objects or the type of an object using only the domain name syntax.

15. 23.10 Mapping Domain Names to Addresses Recall that: DNS has two, conceptually independent aspects: ■ (abstract) - name syntax delegating authority over names ■ (“concrete”) - a distributed computing system that efficiently maps names to addresses Now we consider the second aspect.

16. 23.10 Mapping Domain Names to Addresses – continued The domain name system includes an ■ efficient ■ reliable ■ general-purpose ■ distributed system for mapping names to addresses.

17. 23.10 Mapping Domain Names to Addresses – continued What is meant by these characteristics? ■ efficient most names can be mapped locally, without needing Internet traffic (probably not true of home network) ■ reliable no single machine failure will prevent the system from operating correctly ■ general-purpose not restricted to mapping machine domain names to IP addresses (but we will often use this as our example) ■ distributed a set of servers at multiple sites cooperatively solve the mapping problem

18. 23.10 Mapping Domain Names to Addresses – continued Name Server This is a server that supplies name-to-address translation, mapping from domain names to IP addresses (the example we’re concentrating on). There is a cooperating system of such servers. The corresponding client software is called a name resolver, which accesses one or more name servers when needing to translate a name.

19. 23.10 Mapping Domain Names to Addresses – continued First, assume: ► name server for each level in the tree ► Search starts at root (top-down) ► Root server knows how to contact all top-level servers Line means “able to contact” not usually directly Figure 23.3 Similarly, the top-level domain server knows how to contact the server for each second-level domain … and so on. The servers can be physically located anywhere.

20. 23.10 Mapping Domain Names to Addresses – continued ► Arrangement on previous slide would produce a large number of small servers. ► In practice the tree of servers will be flattened. I don’t think this is right! See later. Figure 23.4

21. 23.10 Mapping Domain Names to Addresses – continued DNS is an amazing system, which made the Internet usable by ordinary people! (Contrast having to use IP addresses.) second-level domains (2008): ► 80,000,000 .com ► 10,000,000 .net ► 6,000,000 .org ► 174,000,000 total The company VeriSign runs the top-level server for .com, .net, and .org, and responds to: 6 – 18 billion requests per day (about 1 – 3 for each person on earth).

22. 23.11 Domain Name Resolution We continue to assume that name resolution proceeds top-down. There are two ways to use the system: ■ iterative – the client contacts the chain of servers, one at a time ■ recursive – the client contact the first server and asks it to take over the task or resolution. In either case the client forms a domain name query that has four components: ■ the domain name to be resolved ■ the class of the domain name (will always be IP for us) ■ the type of answer desired (e.g. machine IP address) ■ iterative or recursive resolution

23. 23.11 Domain Name Resolution - continued The entire DNS namespace is divided into non-overlapping zones of authority. Here is a very small portion of the divided namespace: There is a name server for each zone – authoritative server

24. 23.11 Domain Name Resolution - continued When a domain server receives a query it checks to see if the name lies in the subdomain for which this server is an authority. If yes: the server translates the domain name to an IP address, appends the answer to the query, and returns it to the client If not: the server checks to see if the client requested iterative or recursive If iterative the server replies to the client with a suggestion about the next server the client should contact If recursive, the server turns round and recursively becomes a client, acting on behalf of the previous client; eventually an authoritative server is reached, the translation found, and the recursion unwinds, returning the answer to the original client.

25. 23.11 Domain Name Resolution - continued Q: How does a client find a name server at which to begin the search? A: A client must know the IP address of at least one name server. (In UNIX systems these addresses are in the file /etc/resolv.conf) Q: How does a name server find another name server to contact if the first server cannot answer the query? A: A name server must know the IP address at least one root server (there are 13 root servers, spread around the world, referred to as A .. M – the A root server is 198.41.0.4). The domain name service uses well-known port 53, usually UDP.

26. 23.12 Efficient Translation We have pretended that resolution proceeds top-down, but this would be inefficient, because: ■ name resolution often refers to local names (questionable – not true in home environment; may be true in organizational environment); ■ if every client always went first to the top-level server, it might become overloaded; ■ failure of the top-level server, or of communication with it, would prevent resolution, even if a local server could resolve the name.

27. 23.12 Efficient Translation - continued So we adopt a two-step name resolution mechanism that preserves the administrative hierarchy but permits efficient translation: ■ resolution begins with a local name server ■ if this server cannot resolve the name, the query is sent to a higher server in the domain name system.

28. 23.12 Efficient Translation - continued Example: User on machine flits.cs.vu.nl pings machine linda.cs.yale.edu 130.37.16.112 209.86.66.94

29. 23.13 Caching: The Key to Efficiency Scenario: A name server receives a recursive request for a name not in the server’s zone of authority. The server recursively becomes a client and eventually receives back the requested mapping, which it provides to the original client. The server also retains the mapping in its DNS cache. If the server receives another request for this same mapping, it supplies the information from its DNS cache. However, it does not mark its reply asauthoritative. Since mappings may change, “soft state” is used. When an authoritative server provides a mapping, the server includes a Time to Live (TTL) that indicates how long the mapping may be assumed to remain valid. The receiving server deletes the mapping after the TTL has elapsed. TTL is usually set to 1 day

30. 23.13 Caching: The Key to Efficiency - continued Example: User on machine flits.cs.vu.nl pings machine linda.cs.yale.edu After step 7 the server cs.vu.nl would enter the mapping in its DNS cache and start a soft-state timer (and in step 8 provide the mapping to the name resolver on machine flits).

31. 23.13 Caching: The Key to Efficiency – continued We can now refine the algorithm for a DNS server receiving a query: IF query domain is in server’s Zone Of Authority reply with answer marked AUTHORITATIVE ELSE IF query domain is in server’s cache reply with answer not marked AUTHORITATIVE and provide source of information ELSE IF recursion requested & available server becomes client and searches ELSE IF iteration requested or recursion not available return no answer, but provide suggestions of other servers that may be helpful

32. 23.14 Domain Name System Message Format This format is used for all messages (requests and replies): Figure 23.5

33. 23.14 Domain Name System Message Format - continued 4-bit op-code 9 reserved 10 authenticated 11 disabled Response code Figure 23.6

34. 23.14 Domain Name System Message Format – continued Format of the QUESTION section of the general format: juniper.cis.uab.edu. A IP Figure 23.7

35. The domain name system database consists of a collection of resource records juniper.cis.uab.edu. A IP 1 day 4 138.26.66.6 Figure 23.8 All DNS replies (ANSWER section, AUTHORITY section, and ADDITIONAL INFORMATION section are in the form of resource records

36. 23.15 Compressed Name Format The first paragraph is not actually about compression! Q: Because DNS labels and names are variable in length, how can we represent them internally? A: Domain names are stored as a sequence of labels; each label begins with an octet that specifies its length. Q: How do we know when the name is complete? A: All names end at the root, which has a “zero-length name,” so the length prefix at the end of the name will be zero (explains why not “un-named root”). So juniper.cis.uab.edu is stored as 07 6a 75 6e 69 70 65 72 03 63 69 73 03 75 61 62 03 65 64 75 00 j u n i p e r c i s u a b e d u End of name Count byte

37. 23.15 Compressed Name Format – continued To conserve space in the reply, name servers compress by sending only the first copy of each domain name. Subsequent mentions of the name, or parts of it, are represented by pointer bytes to the first occurrence. Pointers always occur at the beginning of a label and replace the count byte. Q: How do we distinguish count bytes from pointers? A: Labels cannot be more than 63 characters long, so the leftmost two bits of a count byte must be 00 Pointers are distinguished by having the leftmost two bits 11 The next 14 bits of a two-byte field are the pointer.

38. Part of a Wireshark trace of DNS reply to query for juniper.cis.uab.edu The complete name is in the RR but it is compressed in the answer section. AUTHORITY and ADDITIONAL INFORMATION sections

39. 23.16 Abbreviation of Domain Names Telephone analogy: If destination and source are in same area, it’s (usually) not necessary to dial the area code Similarly, within CIS department juniper may be used for juniper.cis.uab.edu.

40. 23.16 Abbreviation of Domain Names - continued The DNS system allows for lookup of fully-qualified domain names only. Although the human user may key in “juniper” the client software must add the suffix before accessing the domain name system. (in a UNIX system file /etc/resolv.conf contains possible values of the suffix)

41. 23.17 Inverse Mappings and 23.18 Pointer Queries We have been concentrating on mapping from a machine’s domain name to its IP address. Sometimes we need the inverse mapping (given address, find name) There is a special domain in-addr.arpa for this For an IP address 138.26.66.6 the form of the query to the DNS system is 6.66.26.138.in-addr.arpa which should give the reply juniper.cis.uab.edu

42. 23.19 Object Types and Resource Record Contents Recall that in reply to a query the DNS sends a copy of the relevant resource records. DNS contains several types of resource record. Here are some: Figure 23.9

43. 23.19 Object Types and Resource Record Contents - continued A server always returns helpful information in the ADDITIONAL INFORMATION SECTION of the response. For example, the ANSWER SECTION responding to a mail-server question contains the domain name of a server for the requested domain. The ADDITIONAL INFORMATION SECTION will provide the corresponding IP address ( a type A resource record)

44. Wireshark trace of DNS reply to query for juniper.cis.uab.edu

45. 23.19 Object Types and Resource Record Contents - continued A small portion of a possible DNS database for domain cs.vu.nl

46. 23.20 Obtaining Authority for a Subdomain Before an organization is granted authority for a second-level domain it must agree to operate a DNS server that meets stringent standards. The Internet authority requires that the information in every second-level domain server be replicated. The information must appear in at least two independent name servers. Q: What is the definition of independent? “Independent” means that the servers have no single common point of failure. The servers ■ cannot be on the same physical network; ■ cannot obtain electrical power from the same source. In practice, an organization must find at least one other site that agrees to run a backup server. For UAB the backup is at deltacom.net