DHCP

1. DHCP, DNS

2. Introduction
 Client administration:
 IP address management:
 They need to ease the process of joining the network and they
do not want users to do any special configuration (DHCP)
 They want to network boot their workstations
 i.e. Diskless workstations or remote OS installation (acquiring the
network setting during boot process)
 Solution: Deploy a DHCP server
 Machine names management:
 They need to be able to name machines and access them by
names instead of IP addresses
 Solution: Deploy A DNS server

3. DHCP
 DHCP - Dynamic Host Configuration Protocol
 Provides configuration parameters specific to the DHCP client host
requesting, information required by the client host to participate on
an IP network
 Method of IP allocation
 Manual
 Only requesting clients with a MAC address listed in the table (MAC-
IP pairs) get the IP address according to the table
 Automatic
 DHCP server permanently assigns to a requesting client a free IP-
address from a range given by the administrator
 Dynamic
 The only method which provides dynamic re-use of IP addresses
 The request-and-grant process uses a lease concept with a
controllable time period.

4. DHCP cont.
 DHCP server can provide optional configuration
 e.g. Subnet Mask, Router, Name Server, …
 RFC 2132 defines DHCP options Usage
 DHCP relay agent (mostly in network routers/high-end switches)
 Relays DHCP Discover broadcasts from a LAN without DHCP to
a network which has one
 Usage
 US
 Cable Internet providers use DHCP
 DSL providers prefer PPPoE
 UK
 Many broadband ISP networks use DHCP
 XDSL providers use infinite lease  Semi-static IPs
 Office networks, public internet access
 Places where there are mobile nodes that want to access the net

5. DHCP Implementations
 Microsoft introduced DHCP on their NT server with Windows NT 3.5
in late 1994
 DHCP did not originate from Microsoft
 Internet Software Consortium published DHCP for Unix variants
 Version 1.0.0 released on December 6, 1997
 Version 2.0 on June, 1999 – A more RFC-compliant one
 Novell included a DHCP server in NetWare OS since v. 5, 1999
 It integrates with Novell eDirectory
 Weird solutions introducing a variety of multiplatform DHCP
implementations since 1997
 Cisco since Cisco IOS 12.0 in February 1999
 Sun added DHCP support in Solaris 8, July 2001

6. DHCP Anatomy
 Uses the same IANA assigned ports as BOOTP
 67/udp for the server, 68/udp for the client
 DHCP Messages
 Discover
 Client broadcasts on the local physical subnet to find servers
 UDP packet (broadcast dest. 255.255.255.255)
 Also request last-known IP address (optional parameter)
 Offer
 Server determines the configuration based on the client’s MAC addr.
 Server specifies the IP address and put optional parameters
 Request
 Client selects a configuration out the DHCP Offer packet and
broadcasts it again
 Acknowledge
 Server acknowledges the request and sends the ack to the client

7. DHCP Anatomy cont.
 Inform
 Client requests more information than the server sent with the
DHCPACK, or to repeat data for a particular application (e.g.
to obtain web proxy settings by a browser)
 Release
 Client requests the server to release the DHCP and the client
unconfigures its IP address
 Sending this message is not mandatory (unplug or …)

8. BOOTP
 BOOTstrap Protocol (RFC 951)
 UDP
 Used to obtain IP address automatically
 Usually in booting process of computers or OSs
 Diskless workstations
 Historically used for UNIX-like diskless workstations
 Also obtains the locations of the boot image
 Also can be used for installing a pre-configured OS
 Protocol became embedded in the BIOS of some NICs
 Allowing direct network booting without need for a floppy

9. BOOTP cont.
 Recently used for booting a Windows OS in diskless
standalone media center PCs
 DHCP is a more advanced protocol base on BOOTP
 Far more complex to implement than BOOTP
 Most DHCP servers also offer BOOTP support
 Duration based leases is the fundamental addition in DHCP
 Dynamic in DHCP is for this

10. RARP
 ARP
 Address Resolution Protocol
 Resolve a hardware address from a given IP address
 Try arp command in both Windows and Linux
 RARP
 Reverse Address Resolution Protocol (RFC 903)
 Complement of ARP
 Resolve an IP address from a given hardware address
 Needs manual configuration on a central server
 Not scalable
 Obsoleted by BOOTP and the more modern DHCP
 Try rarp command in Linux (if supported by Kernel), and RARP
daemon - RARPd

11. DNS
 Domain Name System (RFC 1034, 1035)
 RFC 1034 and 1035 made RFC 882, 883 obsolete
 A system that stores info associated with domain names
in a distributed database on networks (such as Internet)
 Many types of information for the domain provided by
DNS
 Most important, IP address associated with domain name
 Mail eXchange servers accepting e-mail for each domain
 Mainly UDP
 TCP only when response data size exceeds 512 bytes or
for things like zone transfer

12. DNS is Decentralized
 No single point of failure
 Less traffic volume
 Easier maintenance
 Scalable
 Less distant (delay) issues
 Delegation

13. Resolvers
 Clients that access name servers
 Querying a name server
 Interpreting responses
 Returning the information to the programs that requested it
 In BIND, the resolver is just a set of library routines that
is linked into programs
 Not even a separate process
 Most of the burden of finding an answer to the query is
placed on the name server
 The DNS specs call this kind of resolver a stub resolver

14. Types of DNS Servers
 Primary master
 Reads the data for the zone from a file on its host
 Secondary master (Slave)
 Gets the zone data from another ns that is authoritative for the
zone (master server)
 Often, master server is the zone’s primary master
 Not always the case
 Secondary master may get the info from another secondary server
 Zone transfer
 Contacting master ns and if necessary pulling the zone data
 Redundancy
 An authoritative ns may be master for some of its zones and be
slave for some others
 It’s imprecise to call an ns, master or slave!

15. DNS Applications
 Attach IP addresses to domain names (ease of use)
 Many to many mapping
 Virtual Hosting
 Sender Policy Framework
 Makes it possible for people to assign authoritative
names, without needing to communicate with a central
registrar
 Load balancing between hosts

16. DNS History
 Idea in ARPAnet
 Originally, each computer retrieved a file called
HOSTS.TXT from SRI which contained the mappings
 Hosts file exists today (Looked up before querying DNS)
 /etc/hosts, C:WINDOWSsystem32driversetchosts
 Limitations
 Not scalable
 Each time a given computer’s address changed, all computers
should update their Hosts file
 DNS invented by Paul Mockapetris in 1983
 First implementation was called JEEVES by himself

17. Parts of a Domain Name
 Domain name consists of two or more parts separated
by dots (here ce.sharif.edu for example)
 Rightmost label: Top-level domain (edu)
 Each label to the left specifies a subdomain of the domain
above it.
 Relative dependence, not absolute dependence
 sharif is a subdomain of the edu domain
 ce is a subdomain of the sharif.edu domain
 Theoretical limits: 127 level, each level 63 chars, total domain
name 255 chars
 A domain name with one or more IP addresses is called a
hostname (sharif.edu, ce.sharif.edu but not edu)

18. A Distributed Hierarchical Database
 Root Servers (13 root
servers worldwide)
 TLD Servers (.com, .org,
.net, .uk, .ir, …)
 Authoritative DNS Servers
(organization’s DNS
server)

19. Local DNS Server
 Does not belong to hierarchy
 Also called default name server
 Acts as a proxy (forwarder), forwards query into
hierarchy
 Caches the results if of interest

20. DNS Queries
 Recursive
 Contacted name server should recurs and find the mapping
for the requesting host
 Heavy load on the servers
 Iterative
 Contacted server replies with the name of the server to
contact
 An ns provides the name of the next ns
 Bootstrapping problem (another query is required and …)
 So the IP of the next ns is provided
 Glue record

21. DNS Queries
 Recursive query example

22. DNS Queries
 DNS in the real world

23. DNS Caching and Updating Records
 Once a name server learns mapping, it caches it
 It’ll expire (TTL defined by the authoritative server)
 TLD servers typically cached in local name server
 Root name servers not often visited
 Update/Notify Mechanisms
 RFC 2136
 TTL is specified in the Start Of Authority (SOA) record
 Serial – Incremented when the zone file modified, others know
when the zone has been changed and should be reloaded
 Refresh – Number of seconds between update requests
 Retry – Number of seconds between retries (if a request failed)
 Expire – Number of seconds before considering the data stale
 Minimum – Used for minimum TTL, used for negative caching

24. DNS Records
 Resource Records
 Tuples which are stored in the distributed database
 (name, value, type, ttl)
 Types
 There are many types, most famous ones (IPv4 mostly)
 A: Maps a hostname to an IPv4 address
 NS: Maps a domain name to a list of authoritative DNS
servers
 CNAME: Makes one domain name an alias of another
 MX: Maps a domain name to a list of mail exchange servers
 PTR: Maps an IPv4 address to canonical name for that host
 SOA: Specifies the authoritative DNS server
 Info like email of the domain administrator, serial number, …

25. Advanced Features of DNS Servers
 Address Match Lists and Address Control Lists
 i.e. defining a network and referring to it with the name we
defined. e.g.
 acl “ce” {
{ 81.31.164.0/24; 81.13.179.0/24; };
};
 DNS Notify
 Notify the listed servers on zone change
 DNS Dynamic Update
 This permits authorized updaters to add and delete
resource records from a zone for which the server is
authoritative
 Used in DNS, DHCP servers integration

26. Legal Users of Domains
 Registrant
 Administrative contact
 Technical contact
 Billing contact
 Name servers
 Try whois in Linux and see these information for different
hosts

27. DNS - BIND
 BIND (Berkeley Internet Name Domain) written for
Berkeley’s 4.3BSD UNIX OS by Kevin Dunlap
 It is not maintained by Internet Software Consortium
 The most popular implementation of DNS today
 Ported to many flavors of UNIX
 Shipped as a standard part of most vendors’ UNIX
offerings
 Has even been ported to Microsoft Windows