1. 1 Internet Networking Spring 2006 Tutorial 8 DNS and DHCP as UDP applications

2. 2 Domain Name System - DNS Provides mapping from ASCII domain names to IP addresses Hierarchical naming system. The set of names is divided into mutually exclusive parts. Supplies mechanism for global data storage and information retrieval. Most important principles: Distributed system – set of servers sharing information. Efficiency - most of the requests resolved by local servers. Use of Caching. Reliability – works even if some of the servers fail.

3. 3 DNS tree root orgcomgovnetil cnnibmgovcoac tautechnion

4. 4 Reliability over UDP DNS is an application which runs over UDP Advantage: not as complex as TCP. Disadvantage: requires reliability implementation at application level. Reliability scheme: Time out. Retransmissions - resends timed out query to a different server.

5. 5 DNS Terms Domain name: any name represented in the DNS format mail.yahoo.com \.name.example DNS label: each string between two ". “ ac.il – 2 labels DNS zone: a set of names that are under the same authority cs.technion.ac.il, ee.technion.ac.il and www.technion.ac.il Delegation: transfer of authority for a domain example.org is a delegation from org.

6. 6 DNS Elements Resolver: stub: simple, only asks questions; recursive: takes simple query and makes all necessary steps to get the full answer. Server (some perform both roles at the same time): authoritative: the servers that contain the zone file for a zone, one Primary, one or more Secondaries; caching: a recursive resolver that stores prior results and reuses them.

7. 7 How Does DNS Work? The resolver sends a DNS request message over UDP to a local domain name server. The resolver is configured with the address of a local domain name server. DNS caches store data for a short time defined by TTL on the Record. When a name server does not have the requested information, it starts at longest match on query name it has when looking for data. Every domain name server knows the IP address of the root server. The root server knows the IP address of each second-level domain name server. This info is forwarded back to the contacted server. Consequently, every server knows how to reach servers that are authorities for names further down the hierarchy. The resolver follows delegations until it receives an answer.

8. 8 DNS query example (from IETF slides) Root Server Ietf.org Server Org Server Ask org NS Ask ietf.org NS www.ietf.orgwww.ietf.org A 65.256.255.51 www.ietf.orgwww.ietf.org A 65.256.255.51 Recursive Resolver www.ietf.org Stub resolver

9. 9 Dynamic Host Configuration Protocol - DHCP RFC 2131 Runs over UDP as well Provides automatic configuration of the host connected to network or booted Provides hosts with initial configuration information upon bootup: IP address with subnet mask, default gateway, IP address of the DNS server.

10. DHCP (cont.) determine configuration determine configuration DHCP discover DHCP offer select configuration DHCP request DHCP ack Initialization completes graceful shutdown DHCP release discard lease using the allocated configuration (selected)(not selected)

11. 11 DHCP Messages DHCPDISCOVER The client broadcasts message in search of available DHCP servers. DHCPOFFER The server response to the client DHCPDISCOVER with offer of configuration parameters. DHCPREQUEST The client broadcasts to the server, requesting offered parameters from one server specifically. Confirms correctness of previously allocated address after, e.g., system reboot. Extends the lease on a particular network address. DHCPACK The server-to-client communication with configuration parameters, including committed network address. DHCPRELEASE The client-to-server communication, relinquishing network address and canceling remaining lease.

12. 12 DHCPNAK Server to client indicating client's notion of network address is incorrect (e.g., client has moved to new subnet) or client's lease as expired DHCPDECLINE The client-to-server communication, indicating that the network address is already in use. DHCPINFORM The client-to-server communication, asking for only local configuration parameters that the client already has externally configured as an address. DHCP Messages (Cont.)

13. 13 DHCP message format xid – Transaction ID. ciaddr – Client IP address yiaddr – Your IP address. siaddr Server IP address. chaddr Client MAC address

14. 14 DHCP message format (cont.) Transaction ID - a random number that is chosen by the client and is used by the client to match incoming DHCP messages with pending requests. All DHCP messages exchanged for a given DHCP transaction use the xid. Client IP address - used when client knows its IP address. Your IP address - the DHCP server will place the offered client IP address in this field, if the client IP address is 0.0.0.0. Server IP address - if the client knows the IP address of the DHCP server, this field will be populated with the DHCP server address. Otherwise, it is used in DHCPOFFER and DHCPACK from DHCP server. options - DHCP defines a 'client identifier' option that is used to pass an explicit client identifier to a server. (This option eliminates the overloading of the 'chaddr' field, which is used for identifying transaction otherwise).

15. 15 DHCP message filtering DHCPOFFER: only the client waiting for this message will accept it in UDP layer. But what if two clients are waiting for the offer simultaneously? In this situation, the filtering is possible only at the application layer. The transaction ID field in the DHCP message is responsible for this filtering. DHCPREQUEST: the message is broadcasted to all the servers. The server knows if its offer was accepted only upon reading the server identifier field in the DHCP message (application layer).

16. 16 DHCP as UDP application DHCP server - port 67, client - port 68 Reliability is not provided by UDP. Client is responsible for reliability The client implements timer to measure timeout for the messages that were not responded. The client adopts a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions. Every next message acts as an acknowledgment for the previous step. For example, DHCPREQUEST is an ACK for DHCPOFFER.