BAI513 - PROTOCOLS

1. BAIST – Network Management BAI513 - PROTOCOLS DNS

2. Objectives • Understand the types of services that DNS provides • Explain the structure and layout of the domain name hierarchy and the DNS namespace • Understand how DNS servers handle name resolution requests, including the role of nearby and root servers in the resolution process, and the difference between recursive and iterative name resolutions requests

3. Objectives • Explain how DNS queries and responses work, and how they handle name resolution, and reverse DNS queries

4. DNS History and Background • Early methods for resolving symbolic names, such as microsoft.com and course.com, to numeric IP addresses relied completely on static text files, called HOSTS • Paul Mockapetris created the original RFCs for DNS in response to this situation—namely RFCs 882 and 883—and in 1984, built the first reference implementations of DNS, which he named JEEVES

5. DNS History and Background • Kevin Dunlap wrote another implementation of DNS, called BIND (Berkeley Internet Name Domain), for BSD UNIX version 4.3 in 1988 • DNS was designed as a distributed database of information about domain names and addresses • Individual portions of such databases are sometimes called database segments, meaning they include only a portion of the overall namespace that DNS can access for its clients

6. DNS History and Background • DNS combines the following virtues: • It allows local control over domain name database segments • Data from all database segments is available everywhere • Database information is robust and highly available.

7. DNS History and Background • By caching DNS data from one or more database segments on one or more DNS servers, DNS also provides a mechanism whereby it can attempt to satisfy name resolution requests locally before attempting them remotely, thereby greatly improving the speed of such name resolution • Although DNS was designed over 15 years ago, and has been subject to various enhancements and improvements, it still represents one of the most effective uses of distributed database technology in the world today

8. DNS Database Structure • The structure of the DNS database mirrors the structure of the domain namespace itself • Beneath the root, you find the top-level or primary domains • In the United States, these top-level domains usually take the form of the following three-letter code: • .com • .edu • .gov • .mil • .net • .org

9. Tree Diagram of the IBM Domain Name houns54.clearlake.ibm.com

10. DNS Database Structure • This can best be understood as a tree structure (actually, it’s an inverted tree because the root is usually drawn at the top of such a figure) • When you examine record data in DNS database files, you should understand that this final period is important when constructing fully qualified domain names (FQDNs) • In fact, an FQDN consists of all elements of a domain name, in which each is followed by a period, and the final period stands for the root of the DNS hierarchy itself

11. A DNS Overview • Domains can be broken into subdomains as needed • This permits local control over database segments; in essence, it’s a form of delegations of authority • By pushing custodianship of database segments far enough down into the domain hierarchy, local administrative groups can take responsibility for all the names and addresses that they must manage

12. Delegating DNS Authority • Some domains are simply too big and too complex to reside in a single database container • That’s the primary reason why DNS permits the database record for the primary DNS server for ibm.com to delegate authority for various subdomains to DNS servers lower in the domain namespace • Actually, such delegations of authority translates into assignment of authority for subdomains to different domain name server, usually at various locations within an organization’s overall scope and geographical layout

13. The Client Side of DNS • Ultimately, requests for address translations and other DNS services originate from a network client • The piece of software that accesses DNS name servers is called a name resolver, or just a resolver • Resolvers issue requests for service, called name queries or address requests, to domain name servers • A name query seeks to resolve an address to a domain name, also known as an inverse DNS query or reverse DNS lookup, and an address request seeks to resolve a domain name to a corresponding numeric IP address

14. The Client Side of DNS • Resolvers also interpret responses from the name servers that they query, regardless of whether those responses contain resource record data or error messages • Such errors may stem from any of the following causes, among others: • Invalid domain name / IP address • Inability to locate an IP address that corresponds to the requested domain name • Inability to reach an authoritative name server for the requested domain

15. How DNS Servers Work • The process by which the queried domain name server replies works as follows: • DNS servers retrieve name data from the general domain namespace • Any given DNS server can always provide data about zones for which that server is authoritative • Any given DNS server can search its cached domain name data and answer queries for which that server is not authoritative

16. How DNS Servers Work • When a local server does not have the information available in its database or its name cache, it may turn to a caching-only server or to other known name servers in the “neighborhood” • If none of these searches produces a result, the name server sends a request for name resolution to a root server, which directs the query to the authoritative server for the database segment in question by contacting the root server for the domain • This process is known as domain name resolution, or name resolution

17. DNS Root-Level Servers • The real process is actually a bit more complex, so first we will explain some related terminology: • Recursive query: Most DNS resolvers issue what is called a recursive query from the client side. This means that they delegate the first DNS server that they contact to go out and find the necessary address translation on their behalf • Iterative or non-recursive queries: When one DNS server receives a recursive request, that DNS server issues what are called iterative queries, or non-recursive queries, to the name servers in its hierarchy, or to servers provided as pointers in reply to earlier iterative requests, until an answer is received

18. Standard DNS Query Format

19. DNS Query/Response Packet Formats • DNS response packets include the original question as well as the reply • There are four sections in the DNS response packets: • Question section • Answer section • Authority section • Additional section

20. DNS Responses Include the Question in the Reply

21. DNS Query/Response Packet Formats ID Number Field • The 2-byte ID Number field is used to associate DNS queries with their responses QR (Query/Response) Field • This 1-bit field indicates whether this is a DNS query (set to zero) or a DNS response (set to one) Opcode (Operation Code) Field • This 4-bit field defines the type of query that is contained in this message

22. DNS Query/Response Packet Formats AA (Authoritative Answer) Field • This bit is only valid in responses TC (Truncation) Field • This is typically seen only in responses • This bit indicates that the response was truncated because it was too large to fit in the data portion of the packet

23. DNS Query/Response Packet Formats RD (Recursion Desired) Field • This bit indicates that the client requests a recursive query if the target name server does not contain the information requested RA (Recursion Available) Field • This bit is valid in the response, and indicates whether the responding name server supports recursive queries Z (Reserved) Field • Although RFC 1035 defines this field as “reserved” and states that the field should be set to all zeroes, some DNS advancements extended the Rcode field into the Reserved field area

24. DNS Query/Response Packet Formats Rcode (Response Code) Field • This 4-bit field is used in DNS responses to indicate if any errors occurred Question Count Field • This field indicates the number of entries contained in the question section Answer Count Field • This field indicates the number of RRs contained in the answer section

25. Response Code Field Values

26. DNS Query/Response Packet Formats Name Server Count Field • This field indicates the number of name server RRs in the authority records section Additional Records Field • This field indicates the number of other RRs contained in the additional records section Question Name Field • This variable-length field consists of a series of length fields followed by some octets of data

27. DNS Query/Response Packet Formats Question Type Field • This 2-byte field indicates the type of the query • The values possible are defined in the table on the following slide

28. Question Type Values

29. DNS Query/Response Packet Formats Question Class Field • This 2-byte field indicates the class for the query • The value one indicates Internet class Name Field • This field contains the domain name to which this RR belongs • When compression is used, the leading bits in this field must be 11 (binary)

30. Redundancy in a DNS Reply

31. DNS Query/Response Packet Formats Type Field • This 2-byte type field is the RR type code for data contained in the Resource Data field of the response Class Field • This 2-byte field specifies the class of the data contained in the Resource Data field Time to Live Field • This 4-byte field indicates how long the data contained in the Resource Data field should be cached before it is discarded

32. DNS Query/Response Packet Formats Resource Data Length Field • This 2-byte field indicates the length of the Resource Data field Resource Data Field • This variable-length field contains the resource information itself, and in some ways may be said to contain the real “payload” of the RR

33. DNS Implementation • DNS implementations in the real world have two major purposes • One is providing name resolution to your users so they can reach the services provided by the rest of the world, and the other is providing the authoritative hostname-to-IP mapping so that the rest of the world can reach any services you choose to provide, such as a Web server, e-mail server, and perhaps an FTP server

34. The Trouble with DNS • Despite DNS’ stout capabilities and its many advantages, it does suffer from some short-comings • Chief among these is that DNS database updates normally require that a qualified administrator—one with the proper knowledge and necessary access rights to the zone files—operate directly on the DNS database files, or use special-purpose tools (such as NSUPDATE in the UNIX environment) to make changes

35. The Trouble with DNS • Another problem to which DNS falls prey might be called “propagation delay,” which relates to the amount of time it takes for cached values to catch up with changes to authoritative databases once changes are made to those “master copies” of DNS records

36. Summary • Because it provides the essential way to get from a symbolic, human-readable domain name for an Internet location to a corresponding numeric, machine-readable IP address, the Domain Name System provides the key address resolution service that makes today’s Internet possible • The impetus for DNS arose from the difficulty of maintaining static HOSTS files for computers on the ARPANET after the number of hosts climbed into the thousands

37. Summary • DNS maintains its data on a large collection of name servers around the Internet by carving the domain namespace into a disjoined collection of domain or subdomain databases, also known as database segments, or database zones, each of which belongs to a single authoritative name server for that zone

38. Summary • DNS clients rely on a software component called a resolver to interact with an available DNS server for name resolution services • DNS packet structures incorporate type information that identifies the kind of RR being carried, and that otherwise describes the record’s contents and validity