Explain the role of DHCP and DNS within the network | Practonet

Explain the role of DHCP and DNS within the network

In the world of TCP/IP, the word host refers to any device with an IP address: your phone, your tablet, a PC, a server, a router, a switch—any device that uses IP to provide a service or just needs an IP address to be managed. The term host includes some less-obvious devices as well: the electronic advertising video screen at the mall, your electrical power meter that uses the same technology as mobile phones to submit your electrical usage information for billing, your new car.

No matter the type of host, any host that uses IPv4 needs four IPv4 settings to work properly:

■ IP address
■ Subnet mask
■ Default routers
■ DNS server IP addresses

Dynamic Host Configuration Protocol (DHCP)

Dynamic Host Configuration Protocol (DHCP) provides one of the most commonly used services in a TCP/IP network. The vast majority of hosts in a TCP/IP network are user devices, and the vast majority of user devices learn their IPv4 settings using DHCP. Using DHCP has several advantages over the other option of manually configuring IPv4 settings. The configuration of host IP settings sits in a DHCP server, with each client learning these settings using DHCP messages. As a result, the host IP configuration is controlled by the IT staff, rather than on local configuration on each host, resulting in fewer user errors. DHCP allows both the permanent assignment of host addresses, but more commonly, DHCP assigns a temporary lease of IP addresses. With these leases, the DHCP server can reclaim IP addresses when a device is removed from the network, making better use of the available addresses.

DHCP also enables mobility. For example, every time a user moves to a new location with a tablet computer—to a coffee shop, a client location, or back at the office—the user’s device can connect to another wireless LAN, use DHCP to lease a new IP address in that LAN, and begin working on the new network. Without DHCP, the user would have to ask for information about the local network and configure settings manually, with more than a few users making mistakes.

Although DHCP works automatically for user hosts, it does require some preparation from the network, with some configuration on routers. In some enterprise networks, that router configuration can be a single command on many of the router’s LAN interfaces ( ip helper-address server-ip), which identifies the DHCP server by its IP address. In other cases, the router acts as the DHCP server. Regardless, the routers have some role to play.

DHCP Concepts

The host acts as a DHCP client. As a DHCP client, the host begins with no IPv4 settings—no IPv4 address, no mask, no default router, and no DNS server IP addresses. But a DHCP client does have knowledge of the DHCP protocol, so the client can use that protocol to (a) discover a DHCP server and (b) request to lease an IPv4 address. DHCP uses the following four messages between the client and server. (Also, as a way to help remember the messages, note that the first letters spell DORA):

Discover: Sent by the DHCP client to find a willing DHCP server
Offer: Sent by a DHCP server to offer to lease to that client a specific IP address (and inform the client of its other parameters)
Request: Sent by the DHCP client to ask the server to lease the IPv4 address listed in the Offer message
Acknowledgment: Sent by the DHCP server to assign the address and to list the mask, default router, and DNS server IP addresses.

DHCP clients, however, have a somewhat unique problem: they do not have an IP address yet, but they need to send these DHCP messages inside IP packets. To make that work, DHCP messages make use of two special IPv4 addresses that allow a host that has no IP address to still be able to send and receive messages on the local subnet : An address reserved for use as a source IPv4 address for hosts that do not yet have an IP address. The local broadcast IP address. Packets sent to this destination address are broadcast on the local data link, but routers do not forward them.

To see how these addresses work, example of the IP addresses used between a host (A) and a DHCP server on the same LAN. Host A, a client, sends a Discover message, with source IP address of because host A does not have an IP address to use yet. Host A sends the packet to destination, which is sent in a LAN broadcast frame, reaching all hosts in the subnet. The client hopes that there is a DHCP server on the local subnet. Why? Packets sent to only go to hosts in the local subnet; router R1 will not forward this packet. (This example shows details assuming the DHCP client chooses to use a DHCP option called the broadcast flag; all examples in this book assume the broadcast flag is used.)

Now look at the Offer message sent back by the DHCP server. The server sets the destination IP address to again. Why? Host A still does not have an IP address, so the server cannot send a packet directly to host A. So, the server sends the packet to “all local hosts in the subnet” address ( (The packet is also encapsulated in an Ethernet broadcast frame.)

Note that all hosts in the subnet receive the Offer message. However, the original Discover message lists a number called the client ID, which includes the host’s MAC address, that identifies the original host (host A in this case). As a result, host A knows that the Offer message is meant for host A. The rest of the hosts will receive the Offer message, but notice that the message lists another device’s DHCP client ID, so the rest of the hosts ignore the Offer message.

Supporting DHCP for Remote Subnets with DHCP Relay

Do network engineer put a DHCP erver in every LAN subnet or locate a DHCP server in a central site? The question is legitimate. Cisco routers can act as the DHCP server, so a distributed design could use the router at each site as the DHCP server. With a DHCP server in every subnet, the protocol flows stay local to each LAN. However, a centralized DHCP server approach has advantages as well. In fact, some Cisco design documents suggest a centralized design as a best practice, in part because it allows for centralized control and configuration of all the IPv4 addresses assigned throughout the enterprise.

With a centralized DHCP server, those DHCP messages that flowed only on the local subnet somehow need to flow over the IP network to the centralized DHCP server and back. To make that work, the routers connected to the remote LAN subnets need an interface subcommand: the ip helper-address server-ip command.

Theip helper-address server-ip subcommand tells the router to do the following for the messages coming in an interface, from a DHCP client:

1. Watch for incoming DHCP messages, with destination IP address
2. Change that packet’s source IP address to the router’s incoming interface IP address.
3. Change that packet’s destination IP address to the address of the DHCP server (as configured in the ip helper-address command).
4. Route the packet to the DHCP server.

Note: This feature, by which a router relays DHCP messages by changing the IP addresses in the packet header, is called DHCP relay.

Host A sits on the left, as a DHCP client. The DHCP server ( sits on the right. R1 has an ip helper-address command configured, under its G0/0 interface. At step 1, router R1 notices the incoming DHCP packet destined for Step 2 shows the results of changing both the source and destination IP address, with R1 routing the packet.

The router uses a similar process for the return DHCP messages from the server. First, for the return packet from the DHCP server, the server simply reverses the source and destination IP address of the packet received from the router (relay agent). The Discover message lists source IP address, so the server sends the Offer message back to destination IP address
When a router receives a DHCP message, addressed to one of the router’s own IP addresses, the router realizes the packet might be part of the DHCP relay feature. When that happens, the DHCP relay agent (router R1) needs to change the destination IP address, so that the real DHCP client (host A), which does not have an IP address yet, can receive and process the packet.

when R1 receives the DHCP Offer message sent to R1’s own address. R1 changes the packet’s destination to and forwards it out G0/0, because the packet was destined to G0/0’s IP address. As a result, all hosts in that LAN (including the DHCP client A) will receive the message .

Many enterprise networks use a centralized DHCP server, so the normal router configuration includes an ip helper-address command on every LAN interface/subinterface. With that standard configuration, user hosts off any router LAN interface can always reach the DHCP server and lease an IP .

Information Stored at the DHCP Server

A DHCP server might sound like some large piece of hardware, sitting in a big locked room with lots of air conditioning to keep the hardware cool. However, like most servers, the server is actually software, running on some server OS. The DHCP server could be a piece of software downloaded for free and installed on an old PC. However, because the server needs to be available all the time, to support new DHCP clients, most companies install the software on a very stable and highly available data center, with high availability features. The DHCP service is still created by software, however.

To be ready to answer DHCP clients and to supply them with an IPv4 address and other information, the DHCP server (software) needs configuration. DHCP servers typically organize these IPv4 settings per subnet, because the information the server tells the client is usually the same for all hosts in the same subnet, but slightly different for hosts in different subnets. For example, IP addressing rules tell us that all hosts on the same subnet should use the same mask but hosts in different subnets would have a different default gateway setting.

The following list shows the types of settings the DHCP server needs to know to support DHCP clients:

Subnet ID and mask: The DHCP server can use this information to know all addresses in the subnet. (The DHCP server knows to not lease the subnet ID or subnet broadcast address.)
Reserved (excluded) addresses: The server needs to know which addresses in the subnet to not lease. This list allows the engineer to reserve addresses to be used as static IP addresses. For example, most router and switch IP addresses, server addresses, and addresses of most anything other than user devices use a statically assigned IP address. Most of the time, engineers use the same convention for all subnets, either reserving the lowest IP addresses in all subnets or reserving the highest IP addresses in all subnets.
Default router(s): This is the IP address of the router on that subnet.
DNS IP address(es): This is a list of DNS server IP addresses.

The DHCP server sits on the right. For each subnet, the server defines all the items in the list. In this case, the reserves the lowest IP addresses in the subnet to be used as static addresses. The configuration can list other parameters as well. For example, it can set the time limit for leasing an IP address. The server leases an address for a time (usually a number of days), and then the client can ask to renew the lease. If the client does not renew, the server can reclaim the IP address and put it back in the pool of available IP addresses. The server configuration sets the maximum time for the lease.

DHCP uses three allocation modes, based on small differences in the configuration at the DHCP server. Dynamic allocation refers to the DHCP mechanisms and configuration described throughout this chapter. Another method, automatic allocation, sets the DHCP lease time to infinite. As a result, once the server chooses an address from the pool and assigns the IP address to a client, the IP address remains with that same client indefinitely. A third mode, static allocation, preconfigures the specific IP address for a client based on the client’s MAC address. That specific client is the only client that then uses the IP address.

Additionally, the DHCP server can be configured to supply some other useful configuration settings. For instance, a server can supply the IP address of a Trivial File Transfer Protocol (TFTP) server. TFTP servers provide a basic means of storing files that can then be transferred to a client host. As it turns out, Cisco IP phones rely on TFTP to retrieve several configuration files when the phone initializes. DHCP plays a key role by supplying the IP address of the TFTP server that the phones should use.

Configuring DHCP

Cisco routers and switches support a variety of features. Routers can be configured to act s a DHCP server with just a few straightforward commands—a feature useful in the lab and in some limited cases. More commonly, the enterprise uses a centralized DHCP server (that does not run on a router) but with the router DHCP relay feature on most every router interface. Finally, Cisco routers and switches can also act as DHCP clients, learning their IP addresses from a DHCP server.

Configuring DHCP Server

Router# confing t
Router(Config)# hostname Server
Server#configure terminal
Server(config)#ip dhcp excluded-address
Server(config)#ip dhcp pool test

Above you can see that I’ve configured the DHCP server with the following parameters:

The IP addresses from the – range will not be assigned to hosts, if you want to exclude some ip address in dhcp you can use this,
The DHCP pool was created and named test (ip dhcp pool poolname)
The IP addresses assigned to the hosts will be from the range
The default gateway’s IP address is
The DNS server’s IP address is (use can give your DNS server ip address)

To view information about the currently leased addresses, you can use the show ip dhcp binding command:

Router#show ip dhcp binding
IP address Client-ID/ Lease expiration Type
Hardware address 0060.5C2B.3DCC -- Automatic

To display information about the configured DHCP pools, you can use the show ip dhcp pool command.

Configuring a Switch as DHCP Client

Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# interface vlan 1
Switch(config-if)# ip address dhcp
Switch(config-if)# no shutdown
Switch(config-if)# ^Z

Use the show dhcp lease command to see the (temporarily) leased IP address and other parameters. (Note that the switch does not store the DHCP-learned IP configuration in the running-config file.) Note also that the switch learns its default-gateway setting using DHCP as well.

Configuring a Router as DHCP Client

Router# configure terminal
Router(config)#hostname PC
PC(config)# interface fastethernet0/0
PC(config-if)# ip address dhcp

Configuring a Router as DHCP Relay

Relay agent router(config)#int f1/0
Relay agent router(config-if)#ip helper-address
Relay agent router(config-if)#exit

Domain Name System (DNS)

DNS is a host name to IP address translation service. DNS is a distributed database implemented in a hierarchy of name servers. It is an application layer protocol for message exchange between clients and servers. Every host is identified by the IP address but remembering numbers is very difficult for the people and also the IP addresses are not static therefore a mapping is required to change the domain name to IP address. So DNS is used to convert the domain name of the websites to their numerical IP address.

DNS Overview

If your network devices require connectivity with devices in networks for which you do not control name assignment, you can assign device names that uniquely identify your devices within the entire internetwork. The global naming scheme of the Internet, the DNS, accomplishes this task. This service is enabled by default. The following sections summarize DNS concepts and function.

Hostnames for Network Devices – Each unique IP address can have an associated hostname. DNS uses a hierarchical scheme for establishing hostnames for network nodes. This allows local control of the segments of the network through a client-server scheme. The DNS system can locate a network device by translating the hostname of the device into its associated IP address.

Domains Names for Groups of Networks – IP defines a naming scheme that allows a device to be identified by its location in the IP. This is a hierarchical naming scheme that provides for domains. On the Internet, a domain is a portion of the naming hierarchy tree that refers to general groupings of networks based on organization type or geography. Domain names are pieced together with periods (.) as the delimiting characters. For example, Cisco is a commercial organization that the IP identifies by a com domain name, so its domain name is cisco.com. A specific device in this domain, the File Transfer Protocol (FTP) system, for example, is identified as ftp.cisco.com.

Name Servers – To keep track of domain names, IP has defined the concept of a name server. Name servers are programs that have complete information about their namespace portion of the domain tree and may also contain pointers to other name servers that can be used to lead to information from any other part of the domain tree. Name servers know the parts of the domain tree for which they have complete information. A name server may also store information about other parts of the domain tree. Before domain names can be mapped to IP addresses, you must first identify the hostnames, then specify a name server, and enable the DNS service.

Cache – To speed the process of converting names to addresses, the name server maintains a database, called a cache, of hostname-to-address mappings for use by the connect, telnet, and ping EXEC commands, and related Telnet support operations. The cache stores the results from previous responses. Upon receiving a client-issued DNS query, the name server will check this local storage to see if the answer is available locally.

Name Resolvers – Name resolvers are programs that extract information from name servers in response to client requests. Resolvers must be able to access at least one name server. The resolver either uses that name server's information to answer a query directly or pursues the query using referrals to other names servers. A resolver will typically be a system routine that is directly accessible to user programs. Therefore, no protocol is necessary between the resolver and the user program.

Zones – The domain namespace is divided into areas called zones that are points of delegation in the DNS tree. A zone contains all domains from a certain point downward, except those for which other zones are authoritative.

Authoritative Name Servers – A name server is said to be an authority for the parts of the domain tree for which it has complete information. A zone usually has an authoritative name server, often more than one. An authoritative name server has been configured with host table information or has acquired host table information though a zone transfer (the action that occurs when a secondary DNS server starts up and updates itself from the primary server).

Hierarchy of Name Servers

Root name servers
It is contacted by name servers that can not resolve the name. It contacts authoritative name server if name mapping is not known. It then gets the mappin g and return the IP address to the host.

Top level server
It is responsible for com, org, edu etc and all top level country domains like uk, fr, ca, in etc. They have info about authoritative domain servers and know names and IP addresses of each authoritative name server for the second level domains.

Authoritative name servers
This is organization’s DNS server, providing authoritative hostName to IP mapping for organization servers. It can be maintained by organization or service provider. In order to reach cse.dtu.in we have to ask the root DNS server, then it will point out to the top level domain server and then to authoritative domain name server which actually contains the IP address. So the authoritative domain server will return the associative ip address.

Domain :

There are various kinds of DOMAIN :
1. Generic domain : .com(commercial) .edu(educational) .mil(military) .org(non profit organization) .net(similar to commercial) all these are generic domain.

2. Country domain .ae (UAE) .in(INDIA) .us(UNITED STATES) .uk (UNITED KINGDOM) .np(NEPAL) .au(AUSTRALIA) .pk(PAKISTAN)

3. Inverse domain if we want to know what is the domain name of the website. Ip to domain name mapping.So DNS can provide both the mapping for example to find the ip addresses of practonet.com then we have to type nslookup www.practonet.com.

The client machine sends a request to the local name server, which , if root does not find the address in its database, sends a request to the root name server, which in turn, will route the query to an intermediate or authoritative name server. The root name server can also contain some hostName to IP address mappings. The intermediate name server always knows who the authoritative name server is. So finally the IP address is returned to the local name server which in turn returns the IP address to the host.

How to Configure DNS

Configuring the Device as a DNS Server

Perform this task to configure the device as a DNS server. A Cisco IOS device can provide service to DNS clients, acting as both a caching name server and as an authoritative name server for its own local host table. When configured as a caching name server, the device relays DNS requests to other name servers that resolve network names into network addresses. The caching name server caches information learned from other name servers so that it can answer requests quickly, without having to query other servers for each transaction.

When configured as an authoritative name server for its own local host table, the device listens on port 53 for DNS queries and then answers DNS queries using the permanent and cached entries in its own host table. An authoritative name server usually issues zone transfers or responds to zone transfer requests from other authoritative name servers for the same zone. However, the Cisco IOS DNS server does not perform zone transfers.

When it receives a DNS query, an authoritative name server handles the query as follows:

1. If the query is for a domain name that is not under its zone of authority, the authoritative name server determines whether to forward the query to specific back-end name servers based on whether IP DNS-based hostname-to-address translation has been enabled via the ip domain lookup command.

2. If the query is for a domain name that is under its zone of authority and for which it has configuration information, the authoritative name server answers the query using the permanent and cached entries in its own host table.

3. If the query is for a domain name that is under its zone of authority but for which it does not have any configuration information, the authoritative name server does not forward the query elsewhere for a response; instead the authoritative name server simply replies that no such information exists.



Device#configure terminal

Device(config)#ip dns server
[Activates the DNS server on the device]

Device(config)#ip name-server server-address1 [server-address2... server-address6]
[Example: Device(config)# ip name-server ]

Device(config)#ip dns server queue limit {forwarder queue-size-limit
[Example: Device(config)# ip dns server queue limit forwarder 10] , [Configures a limit to the size of the queues used by the DNS server processes.]

Device(config)#ip host [vrf vrf-name] [view view-name] hostname {address1 [address2 ... address8] | additional address9 [address10 ... addressn]}
[Device(config)# ip host user1.example.com] [(Optional) Configures local hosts.]

Device(config)#ip dns primary domain-name soa primary-server-name mailbox-name [refresh-interval [retry-interval [expire-ttl [minimum-ttl]]]]
[Device(config)# ip dns primary example.com soa ns1.example.com mb1.example.com], [Configures the device as the primary DNS name server for a domain (zone) and as the start of authority (SOA) record source (which designates the start of a zone).]

Device(config)#ip host domain-name ns server-name
[Device(config)# ip host example.com ns ns1.example.com ], [(Optional) Configures the device to create an name server (NS) resource record to be returned when the DNS server is queried for the associated domain.]

Configuring DNS Spoofing

Perform this task to configure DNS spoofing. DNS spoofing is designed to allow a device to act as a proxy DNS server and “spoof” replies to any DNS queries using either the configured IP address in the ip dns spoofing ip-address command or the IP address of the incoming interface for the query. This feature is useful for devices where the interface toward the Internet service provider (ISP) is not up. Once the interface to the ISP is up, the device forwards DNS queries to the real DNS servers.

This feature turns on DNS spoofing and is functional if any of the following conditions are true:

- The no ip domain lookup command is configured.
- IP name server addresses are not configured.
- There are no valid interfaces or routes for sending to the configured name server addresses.

If these conditions are removed, DNS spoofing will not occur.


Device#configure terminal

Device#ip dns server

Device#ip dns spoofing [ip-address]
[Device(config)# ip dns spoofing], [Configures DNS spoofing.The IP address used for DNS spoofing can be an IPv4 or IPv6 address. The device will respond to the DNS query with the configured ip-address when queried for any hostname other than its own. The device will respond to the DNS query with the IP address of the incoming interface when queried for its own hostname.]

Mapping Hostnames to IP Addresses

Perform this task to map hostnames to IP addresses. A name server is used to keep track of information associated with domain names. A name server can maintain a database of hostname-to-address mappings. Each name can map to one or more IP addresses. In order to use this service to map domain names to IP addresses, you must specify a name server.

The name lookup system can be statically configured using the commands described in this task. Some other functions in Cisco IOS software, such as DHCP, can dynamically modify the state of the name lookup system. Use the show hosts command to display the cached hostnames and the DNS configuration.


Device#configure terminal

Device(config)#ip host name [tcp-port-number] address1 [address2 ... address8]
[Device(config)# ip host cisco-rtp], [Defines a static hostname-to-address mapping in the hostname cache. The host IP address can be an IPv4 or IPv6 address. Typically, it is easier to refer to network devices by symbolic names rather than numerical addresses (services such as Telnet can use hostnames or addresses). Hostnames and IP addresses can be associated with one another through static or dynamic means. Manually assigning hostnames to addresses is useful when dynamic mapping is not available.]

Device(config)# ip domain name name
[Device(config)# ip domain name cisco.com], [Defines a default domain name that the Cisco IOS software will use to complete unqualified hostnames.]


ip domain list name
[Device(config)# ip domain list cisco1.com], [Defines a list of default domain names to complete unqualified hostnames.]

Device(config)#ip name-server server-address1 [server-address2 ... server-address6]
[Device(config)# ip name-server], [Specifies one or more hosts (up to six) that can function as a name server to supply name information for DNS.]

Device(config)#ip domain lookup [source-interface interface-type interface-number]
[Device(config)# ip domain lookup], [ Enables DNS-based address translation. DNS is enabled by default. Use this command if DNS has been disabled.]