The Domain Name System (DNS), & Other Important ‘Utility’ Protocols 635.413.31 – Summer 2007

1. The Domain Name System (DNS), & Other Important ‘Utility’ Protocols635.413.31 – Summer 2007

2. Why is name resolution necessary? • Allows the use of easily remembered names to access Internet resources instead of IP addresses • Really set the stage for mass adoption of the Internet • Originally accomplished with a static mapping table in each host • Static mapping could not scale with the tremendous growth of the Internet so a better system was necessary • In addition the original flat namespace could not scale either • The Domain Name System was developed in the early 80’s and formalized in RFCs 882 & 883 • Updated in RFCs 1034 & 1035 along with numerous informational RFCs • DNS provides two things: • Name syntax & structure for delegation of authority • The protocol & other mechanisms necessary for mapping names to addresses

3. Goals of the Domain Name System • There are four general goals for the Domain Name System • Be Efficient • Keep DNS local when possible • Cache data • Be Reliable • Multiple servers for redundancy • No single machine or network failure should take down DNS • Be General Purpose • As seen later, DNS provides for the mapping of different types of objects • Even the domain names and labels defined by the responsible Internet authorities could be changes or replaced in private DNS implementations • Be Distributed & Flexible • DNS is heirarchical, with the ability to delegate authority for portions of the namespace • Indeed, the logical structure of DNS does not have to follow the physical structure of the network

4. Basic example of how DNS works • The host application wants to open a TCP connection • The application has domain name of the destination but needs an IP address to open the TCP connection • The application asks a special software process called the resolver on the local host to find the mapping from domain name to IP address • The local name server looks up the domain name and returns the mapping to the host resolver • The resolver returns IP address to application • The application then opens TCP connection using the IP address of the destination

5. The structure of domain names & the DNS tree • DNS defines a hierarchical namespace with structure that allows for delegation of authority • The structure of a domain name • A domain name consists of a series of alphanumeric labels up to 63 characters long separated by dots • The only generally accepted ‘special’ character is the dash (“-“); some name servers also allow the underscore (“_”) • The structure of the DNS tree • The top of the DNS tree (typically drawn upside down) is known as the ‘root’ or ‘dot’ • Below the root are the Top Level Domains (TLDs) • ICANN (formerly IANA) is responsible for oversight of Top Level Domains and delegates authority for lower parts of the DNS tree

6. The structure of domain names & the DNS tree Top Level Domains are currently organized into 3 different ‘groups’ 1. The Organizational Top Level Domains or ‘generic’ TLDs • There are currently seven organizational TLDs • COM – commercial organizations • EDU – Universities and educational institutions • GOV – United States government • INT – international organizations formed by global treaty • MIL – United States military • NET – network providers and ISPs • ORG – organizations not fitting into any of the above categories (non-profit groups, etc) • GOV and MIL domains reserved exclusively for the U.S.government and military; INT and EDU have other restrictions • COM, NET, and ORG are generally available via registrars • Recently more TLDs have been defined by ICANN (.biz, .info, etc.) and are discussed later

7. The structure of domain names & the DNS tree 2. The Geographic Top Level Domains • Also known as the Country Domains because each country has a two character TLD in this group • Each country responsible for choosing a service provider to register domains under its TLD • Two letter country codes are defined by ISO (.us equals United States) 3. The ARPA Top Level Domain • Defines the reverse (or inverse) mapping between domain names and IP addresses; reverse mapping is not as easy as it seems! • The whole IP address space laid out underneath this TLD • As explained later, implementation of reverse mapping handled independently from the name to IP address (forward) mapping

8. The structure of domain names & the DNS tree • How the structure of a domain name relates to the DNS tree • A Fully Qualified Domain Name (FQDN) • Traces the full path from the root to the node of the tree • The root node is unnamed or sometimes known as ‘dot’ because an FQDN ends with a ‘dot’ • Provides a globally unique name • Queries must contain a FQDN! • A relative domain name • Provides a locally unique name only! • Hosts use relative names for efficiency

9. Primary, Secondary, & Root Servers • Root servers form the top of the physical DNS hierarchy and contain the information necessary to contact the authoritative name servers for all second level domains • Every name server must know how to contact the root name servers • Typically the root name server IP addresses are configured into a name servers DNS configuration file • Currently 13 root name servers geographically distributed around the world • Root servers in the United States (some commercial, some military, & some at educational institutions) • Root servers in the rest of the world • Many of these machines are actually clusters for high reliability • Current list available at ftp://rs.internic.net/domain/named.root • The primary name server contains all the DNS information on disk and is the single administration point for all DNS information in its zone • Secondary name servers obtain all their DNS information by downloading it from the primary name server

10. DNS Zones • A zone is a contiguous piece of the DNS tree that is administered separately from the rest of the tree • DNS zones do not necessarily have to correlate one-to-one to the IP address structure • There is a technical difference between domains and zones – domains denote namespace divisions and zones denote division of authority • Other characteristics of DNS Zones • Zones can be broken into sub-zones with delegated administration • The zone administrator must provide a primary name server for the zone and at least one secondary name server • The designated primary and secondary name servers are considered authoritative for their zone • The name servers should be as independent as possible to maximize availability • A set of primary & secondary name servers can serve more than one zone

11. Zone Transfers • The method of transferring a DNS mapping table from a primary to a secondary name server • Zones transfers are typically initiated by the secondary name server at regular intervals but if necessary they can be initiated on demand (e.g. - initialization of a new name server) • Zone transfers typically use TCP connections for reliability • For security zone transfers should be restricted to your network (if not down to the name servers themselves)

12. DNS Caching • Caching minimizes name server load and network traffic (VERY important) • All name servers will cache the domain name information they receive • Depending on their complexity, host resolvers might cache DNS information • Most large multi-user systems cache for increased efficiency • Windows XP resolver (ipconfig /displaydns -> displays contents of the resolver cache)

13. DNS Message format • A DNS message has three general parts: • Header • Questions • Resource Records (which are typically answers to questions) • General Structure of a DNS Message

14. DNS Message format • Header • DNS messages have a fixed 12 byte header • IDENTIFICATION field • Set by client and used to match DNS replies with requests • FLAGS field • QR bit – bit set (=1) denotes a DNS response; otherwise it is a DNS query • OPCODE field (4 bits) – normally set to zero (standard query) but can be one (a reverse query) or two (DNS server status request) • AA bit – bit set (=1) denotes name server responding is the authoritative server for the domain in the question

15. DNS Message format • Header Flags (continued) • RD bit – bit set (=1) denotes a request for the name server to perform a recursive query -- otherwise the request is for an iterative query • Recursive Query: If the name server does not have an authoritative answer it will handle the name resolution itself returning the answer to the originating name server • Resolvers almost always request recursive queries • Iterative Query: If the name server does not have an authoritative answer it will return to the requester the next name server to contact for the answer • Name servers use mostly iterative queries • Roots server typically do nothing but iterative queries because of load demands

16. DNS Message format • Header Flags (continued) • RA bit – bit set (=1) in a response denotes the name server supports recursive queries • RCODE field (4 bits) – Specifies an error code (if any) in a DNS reply. Common values are zero (no error) or three (name error – the specified domain does not exist)

17. DNS Message format • Questions • There is normally one question per DNS message • Question portion consists of three fields: query name, query type, & query class • Query Name: the domain name being looked up encoded in a special format • Query Type: denotes the type of question contained in the DNS message. Typical value is one (for a domain name lookup) or twelve (for a reverse lookup) • Query Class: should be one for IP (this field isn’t really necessary anymore; it was there to allow the DNS to handle name resolution for other network protocols)

18. DNS Message format • Resource Records • The final part of a DNS message consists of three subparts which all share a common format called a Resource Record • The subparts are known as: • Answer Resource Records • Authority Resource Records • Additional Information Resource Records • Resource Record Format:

19. DNS Message format • Common Fields in all Resource Records • Domain Name field (variable length): the data in this field specifies the name to which the data in the resource records pertains to • Type field (16 bits): specifies the resource record information type; same values as the Query Type field in the DNS Question • Class field (16 bits): as with the type field same as the Query Class field in the DNS Question • Time-to-Live field (32 bits): specifies the number of seconds that the Resource Record can be cached for in a non-authoritative name server. A typical TTL is two days • Resource Data length field (16 bits): the length in bytes of the data in the Resource Record • Resource Data field (variable): the data field length typically depends on the type of Resource Record (example: an A record’s data field would contain a four byte IP address)

20. Examples Root Name Server • A DNS name resolution query in more detail • Example of a DNS Pointer query (Reverse Mapping) • Why is this functionality necessary? • Primarily for security (to discourage spoofing) • Also helps make server log files more readable • Reverse mapping of 128.220.10.11 ibm.com Zone 2 3 6 Destination Host fun.ibm.com ibm.com Name Server 5 jhu.edu Name Server Client resolver 4 1

21. Other important DNS resource records • HINFO (Host Info) • Allows two sets of arbitrary character strings in the Resource Record typically to specify a hosts CPU and Operating System • Originally used to assist in troubleshooting network problems • Rarely used anymore for security reasons • MX (Mail Exchange) • Allows flexibility in how e-mail is delivered • Provides the following functionality: • Allows a site not permanently connected to the Internet to use a ‘proxy’ site as its mail exchanger (very important when UUCP was widely used) • Allows for the definition of ‘backup’ mail servers for redundancy • Allows the definition of a easy-to-remember virtual ‘mail’ domain (user@acme.com) for users on the Internet • Allows organizations with firewalls to limit connectivity to internal systems • MX records include a 16 bit preference value; if multiple MX records exist for a destination the one with the lowest preference value will be used

22. Other important DNS resource records • SOA (Start of Authority) • Resource Record found specifying the primary name server for a zone and indicating its authority for the zone • Only one SOA RR found in the server at the start of the config file • Contains information necessary for operation of the secondary name servers (time between zone transfers, when the DNS configuration changes, etc.) • NS (Name server) • The name server record specifies the name server(s) for a domain • Most important use is specifying secondary name servers (the primary is also specified in the SOA RR) • CNAME (Canonical Name) • Also known as an alias • Allows one domain name to be mapped to another • VERY useful for organizations with general services (WWW, FTP, etc) that they would like to advertise at easy-to-remember names (www.acme.com, etc) • Allows the implementation of a rudimentary form of load sharing & redundancy

23. Example Zone Configuration • Portion of an actual Zone File from a Name Server

24. DNS Implementation • Use of TCP and UDP • For queries and replies UDP is typically used though if the reply is larger than 512 bytes (the maximum size for a UDP datagram) the client will need to reissue the request; it and the reply will be via TCP • For both TCP and UDP, the DNS uses the well-known port 53 • Zone transfers are done via TCP because of the size of the DNS configuration data and to provide high reliability • Name Server Software • BIND (Berkeley Internet Name Domain) and Named • Arguably the most widely used name server software in existence; found on most flavors of UNIX • Current version is 9.4.1, though versions 8.4, 9.2, & 9.3 are commonly used • Windows Family of Servers • NT Server 2000/2003 have a native DNS server • NT Server 4.0 supports several third party ports of BIND as well as a ‘native’ version in the NT Option Pack

25. DNS Implementation • Useful DNS commands for troubleshooting • Nslookup • Common way to check to see that DNS is working properly • Found on all common Unix variants & later Windows systems • Syntax: nslookup [-option ...] [host-to-find | -[server]] • Example: > nslookup www.yahoo.com Server: ns2.umd.edu Address: 128.8.76.2 Non-authoritative answer: Name: www.yahoo.akadns.net Addresses: 216.109.118.66, 216.109.118.67, 216.109.118.69, 216.109.118.71 216.109.118.72, 216.109.118.79, 216.109.117.205, 216.109.118.65 Aliases: www.yahoo.com >

26. DNS Implementation • Another good DNS command: DIG > dig umd.edu mx ; <<>> DiG 8.3 <<>> umd.edu mx ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5 ;; QUERY SECTION: ;; umd.edu, type = MX, class = IN ;; ANSWER SECTION: umd.edu. 16h40m IN MX 10 mailfw1.umd.edu. umd.edu. 16h40m IN MX 10 mailfw0.umd.edu. ;; AUTHORITY SECTION: umd.edu. 16h40m IN NS ns2.umd.edu. umd.edu. 16h40m IN NS noc.umd.edu. umd.edu. 16h40m IN NS ns1.umd.edu. ;; ADDITIONAL SECTION: mailfw0.umd.edu. 5M IN A 128.8.70.20 mailfw1.umd.edu. 10M IN A 128.8.10.57 noc.umd.edu. 5M IN A 128.8.5.2 ns1.umd.edu. 16h40m IN A 128.8.74.2 ns2.umd.edu. 16h40m IN A 128.8.76.2

27. DNS Futures • New Top Level Domains (TLDs) • The growth in use of the Internet and domain names has spurred the creation of a new set of TLDs to augment the existing seven • Are now in use – see http://www.iana.org/gtld/gtld.htm • Some of the new TLDs that have been implemented • BIZ – for businesses • INFO – unrestricted use, but intended for information resources • PRO – unrestricted use, but for professionals • NAME – unrestricted use, for individuals • AERO – restricted use, for aviation industry • COOP – restricted use, for cooperatives • MUSEUM – restricted use • MOBI – for mobile providers and services • More are undoubtedly on the way!!

28. DNS Futures • DNS competition • Competition is here for DNS registration – there is now a large number of organizations certified to register domain names in the central registry • Management of the core TLD registry for COM, ORG, and EDU is currently run by one company under contract to the Department of Commerce however other companies certified by ICANN can add to the registry (for a flat fee) • There have been attempts by other organizations to set up competing DNS trees and Top Level Domains • There is also a movement to create a set of non-English TLDs and corresponding DNS hierarchy • Proposals for IDNs (International Domain Names) are under debate within ICANN

29. DNS Futures • Dynamic DNS • A protocol that allows automated configuration of DNS servers with updated name to IP address mapping • Supported in later versions of BIND (I believe anything version 8 and later), Windows 2000/2003, & Lucent’s QIP • Active Directory relies on D-DNS for fundamental operation • Also makes use of the SRV RR defined in RFC 2782 • D-DNS protocol specified in RFC 2136 • Implemented with AD but otherwise relatively uncommon (and there are security issues surrounding such functionality) • Supposed to conceptually work in conjunction with DHCP to automate host configuration

30. DNS Futures • Secure DNS (aka DNSSec) • One big problem with DNS is its openness & lack of security • The DNS has been used as a basis of attack & been a target itself • DNSSec is supposed to help provide a solution • Defined in RFCs 4033, 4034, and 4035 • Provides for authentication and integrity checking on DNS data • What DNSSec entails • A PKI-like public key infrastructure (keys & chains of trust from a root) • New Resource Records & DNS Message Fields (RRSIG, DNSKEY, etc.) • New Protocol Functions (e.g. – answering a negative reply with a special ‘signed’ NSEC RR response) • Current Challenges • Like PKI, deployment & maintenance of key infrastructure is a hurdle • Does not address privacy nor denial-of-service (DoS) attacks • Not really supported on Windows 2003 (OK on BIND 9.x)

31. The Bootstrap Protocol (BOOTP)

32. What is BOOTP used for? • Designed to provide better support for systems that required dynamic network configuration • Intended to replace RARP for four reasons • Can provide more configuration data than RARP; which just provides an IP address • Requests and replies can be forwarded by routers (RARP only good on the local subnet) • More bandwidth efficient because replies are not typically broadcast • RARP is a very low level protocol that usually requires direct hardware access; difficult to implement in applications • Defined in RFC 951 & updated in RFC 1542 • Uses UDP for transport and well-known port numbers 68 for the BOOTP server and 69 for the BOOTP client

33. What is BOOTP used for? • BOOTP Message Format

34. BOOTP message format • Always 300 bytes long • Opcode field (8 bits): specifies whether message is a BOOTP request (=1) or a BOOTP reply (=2) • Hardware type field (8 bits) & HW address length fields (8 bits): specifies the physical/DL layer protocols in use (Ethernet = 1) • Hop Count field (8 bits): set to zero by a BOOTP client; used by BOOTP relay agents to record how far the message has been sent (it is SUGGESTED that any relay agent receiving a BOOTP message with a Hop Count greater than three should toss it) • Transaction ID field (32 bits): set by the client to a locally unique value; used by the client to match a response with a request • Number of Seconds field (16 bits): set by the client with the time since it began trying to boot; allows a secondary server to respond only if the primary appears to be down

35. BOOTP message format • IP Address fields • Client IP address: contains either the client IP address if known or 0.0.0.0 if the client is issuing a BOOTP request for its IP address • Your IP address: field filled in by the BOOTP server with the client’s IP address • Server IP address: IP address of the BOOTP server issuing the reply • Gateway IP address: filled in by a BOOTP relay agent if it forwards a request to a BOOTP server on a remote network • Client Hardware Address field (16 bytes): filled in by the client when issuing request; actual length of the hardware address is usually less than 16 bytes • Server Hostname field (64 bytes): filled in by the server in a reply (optional) • Boot filename field (128 bytes): used to specify an optional null-terminated pathname of a file to boot from • Vendor-specific information field (64 bytes): can be used by server in a reply to supply additional information necessary for the client to complete its bootstrap routine

36. BOOTP in use A typical example for a diskless workstation • Client boots and issues a limited broadcast (source = 0.0.0.0 and destination = 255.255.255.255) BOOTP request message • BOOTP server constructs and issues reply with a valid IP address and a bootfile name in the bootfile field (Note: more than one BOOTP server can respond) • Client uses the BOOTP reply from the first server to respond and broadcasts gratuitous ARP with its new mapping • Client broadcasts ARP request for BOOTP server it chose • BOOTP server issues an ARP reply • Client initiates file transfer (typically using a protocol called TFTP studied later) to download bootfile • Transfer of bootfile completes and workstation continues to boot using its new configuration information

37. BOOTP implementation BOOTP Server Design • In some instances a server will need to broadcast its BOOTP reply • The RFCs do not cover any details on the implementation of the BOOTP server client configuration database; typically a static mapping table is used Implementation Issues • Multi-homed hosts: each network interface requires a separate BOOTP negotiation • BOOTP clients force the use of UDP checksums and does not allow fragmentation

38. BOOTP through a router • Routers can be configured to act as BOOTP relay agents (This function is separate than its IP forwarding function and typically has to be explicitly configured) • BOOTP relay agents will receive a broadcast BOOTP request from a client on a directly connected network and reissue a unicast BOOTP request to the server • All other BOOTP relay agents between the initial relay agent and the server will do nothing to the unicast BOOTP request except increment the hop count • Only the BOOTP relay agent filling in the Gateway IP address field should intercept a BOOTP server reply and attempt to send it to the requesting client.

39. Transmission of vendor specific information via BOOTP • Format of this field covered in RFC 2132 (DHCP Options & BOOTP Vendor Extensions) • If the server wants to use this field the first data in the field must be the Magic Cookie (the value equal to the IP address 99.130.83.99) • Following the Magic Cookie are a list of items structured in TLV format (Type, Length, & Value fields) • Pad: one byte with type=0 • End: one byte with type=255 • Subnet Mask: type=1, length=4, and data equals a four byte subnet mask • Time Offset: type=2, length=4, and data equal to the number of seconds past midnight GMT January 1, 1900 • Gateway(s): type=3, length = 4 x N where N= number of gateways, and list equals a set N of gateways from most to least preferred • Other items are defined for more specific purposes

40. The Dynamic Host Configuration Protocol (DHCP)

41. Introduction to DHCP • DHCP is designed to be an enhancement to BOOTP by moving closer to the goal of completely automated network host configuration • Defined in RFC 2131 • Uses the same message structure as BOOTP with some enhancements • Special item in Option field differentiates a DHCP message from a BOOTP message • In general DHCP is much more flexible than BOOTP, which cannot easily accommodate mobile and multi-boot systems • The two protocols are generally compatible (more on this later)

42. Differences between BOOTP and DHCP DHCP has two major advantages over BOOTP: • The vendor specific field is no longer fixed size and can hold a lot more configuration information • DCHP supports two more IP address allocation methods besides the manual allocation mode also found in BOOTP • With manual allocation means the network administrator explicitly configures a permanent IP address for a client into the BOOTP/DHCP server mapping file • Automatic allocation • The DHCP server permanently assigns an IP address to a client as in manual allocation • The particular IP address assigned to the client is determined internally in the server: first-come first-served, geographically, through some formula, etc.

43. Differences between BOOTP and DHCP • DHCP Address Allocation Modes • Dynamic allocation • Address is assigned dynamically from a pool of IP Addresses • Addresses are ‘leased’ to a client for a defined period of time • When lease expires the client should relinquish the IP address • Infinite leases are possible • Client can request extension of the lease • Servers should try to reallocate the same address to clients though it should never be assumed by clients that they will get the same one

44. Interoperability with BOOTP • DHCP servers should service BOOTP clients (though BOOTP clients have no concept of IP address ‘leasing’) • A DHCP server will have to make provisions for the simplicity and ignorance of BOOTP clients (especially with address ‘leasing’) • BOOTP servers should be able to respond to typical DHCP client requests • DHCP clients should prefer an Offer from a DHCP server over a reply from a BOOTP server • Routing acting as BOOTP relay agents should also act as DHCP relay agents (and vice versa)

45. DHCP Options • DHCP does not add fields to the BOOTP message nor does it change the meanings of most fields • Most DHCP enhancements are encoded in the options field • Options are encoded in TLV (type-length-value) format • The most important options for DHCP operation are the DHCP message types • There is also a special Option Overload option, which allows the DHCP server to use the SERVER HOST NAME and BOOT FILE NAME fields for transmission of additional DHCP options

46. DHCP Message Types • DHCP Discover (Client->Server) - Client broadcast to locate available servers • DHCP Offer (S->C) - Response from one or more servers to DHCPDISCOVER with offer of configuration parameters • DHCP Request (C->S) – Client request in one of the following situations: • Accepting configuration parameters from one server and implicitly declining parameters from any other DHCP servers that responded with an offer. • Confirming correctness of assigned IP address after some event such as a system reboot • Extending the lease on an IP address

47. DHCP Message Types • DHCP ACK (S->C) - Servers response that the offered configuration parameters are correct and committed to the DHCP client • DHCP NAK (S->C) - Server’s response to a client that the client’s notion of its assigned IP address is incorrect or informing a client that its lease has expired • DHCP Decline (C->S) - Client informing server that the offered network address is already in use • DHCP Release (C->S) - Client informing server that it is relinquishing lease on and use of a particular IP address • DHCP Inform (C->S) - Client requesting only local configuration parameters; used when client already has an IP address

48. DHCP State Diagram

49. DHCP in Action • An example of a client configuration sequence (match with the state diagram in the textbook) 1. Client boots 2. Client broadcasts DHCP Discover message 3. One or more servers responds with a DHCP Offer message containing IP address and network configuration parameters based on the DHCP administrator’s policies 4. The client chooses one of the DHCP Offer messages and broadcasts a DHCP Request with the chosen server specified in the ‘server identifier’ field – all other DHCP servers that responded with offers know by examining the request that they were not chosen

50. DHCP in Action • Client configuration example (continued) 5. The chosen DHCP server receives the Request message and commits the client’s assigned address in its database. The server responds (typically unicast) to the client with a DHCP ACK confirming successful reservation of the IP address • If the client detects that the IP address is in use by another host (and they should check using a ping) instead of sending an ACK it should send a DCHP Decline • If for some reason the server believes the client is using an incorrect IP address (via the DHCP Request message it received) it will send a DHCP NAK message and the client will be forced to restart the configuration process 6. After receiving the DHCP ACK the client should be fully configured and able to communicate on the TCP/IP network