The Domain Name System DNS,

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
  80s 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/do
  main/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
  isnt 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 records data field would
  contain a four byte IP address)

20
Examples

• 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

Root Name Server
ibm.com Zone
3
2
6
Destination Host fun.ibm.com
ibm.com Name Server
jhu.edu Name Server
Client resolver
5
1
4
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_at_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
• -HEADERid 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
  

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,
  Lucents 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 clients 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 type0
• End one byte with type255
• Subnet Mask type1, length4, and data equals a
  four byte subnet mask
  
• Time Offset type2, length4, and data equal to
  the number of seconds past midnight GMT January
  1, 1900
  
• Gateway(s) type3, 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) - Servers response to a client
  that the clients 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
  administrators 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 clients 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

51
Reading Homework

• Reading
• Comer Chapters 23 and 24
• Homework Assignment 3 (due Thursday 6/28)
• Chapter 13 13.1
• Chapter 14 14.4, 14.9
• Chapter 15 15.8, 15.12, and 15.14
• Chapter 16 16.4, 16.7, and 16.9
• Chapter 22 22.9, 22.11, and 22.12
• Chapter 23 23.13 and 23.14
• A number of organizations run controlled
  interfaces to their routers that allow limited
  access to outsiders for troubleshooting. A list
  of these looking glass routers can be found at
  http//www.caida.org/analysis/routing/reversetrace
  / Use at least three routers on different
  continents to do BGP path lookups and traceroutes
  to www.apl.jhu.edu. List your results and
  explain the differences and similarities you
  see.
• Note These five classes cover all the material
  on the mid-term!