The Domain Name System DNS, - PowerPoint PPT Presentation

Loading...

PPT – The Domain Name System DNS, PowerPoint presentation | free to view - id: 11978-NzNjN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

The Domain Name System DNS,

Description:

Even the domain names and labels defined by the responsible Internet authorities ... The structure of domain names & the DNS tree ... – PowerPoint PPT presentation

Number of Views:548
Avg rating:3.0/5.0
Slides: 52
Provided by: Audrey92
Category:
Tags: dns | domain | name | names | system

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: The Domain Name System DNS,


1
The Domain Name System (DNS), Other Important
Utility Protocols 635.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!
About PowerShow.com