The Domain Name System does something wonderful and transparent for us: It takes the hostname we enter into a web browser – usually a website’s URL – and translate it into the IP address that’s actually needed to make the communication between host and website happen.
A DNS Query is sent out asking for a translation of a given hostname to an IP address, a DNS Server answers the query, and we’re off to the races.
we tend to think of DNS being used only for website URL – IP mapping, but it’s used to resolve internal hostnames as well.
In this example Host A needs the IP address of a device it knows only as “hostb”.

Then it has to send a query out to the DNS server.
The DNS query is received by the server, which answers with the correct IP address for the host. The server can respond and say “OK the address you actually want is 192.168.1.2.”
How did the host learn about the location of the DNS server to begin with?
It could be hard-coded on that host, but more than likely Host A received its IP address via DHCP, and DHCP would also tell that host where to find the DNS server.
You can see that info on a PC with ipconfig/all .
Here, I have an IPv6 address for a DNS server in addition to the more-familiar IPv4 address.

If we had an IPv6, it would show up above the highlighted line.
I got this information from DHCP when I got my IP address and everything else I need to operate on this particular subnet.
Knowing Host B’s IP address is half the battle. We need Host B’s MAC address as well, ( while we tend to concentrate on that Layer3 address, we’ve got to have a destination Layer2 address as well), and that’s where the Address Resolution Protocol (ARP) comes in.
ARP doesn’t have the equivalent of a DNS server. Instead, the ARP process uses a series of broadcasts and replies along with cache of addresses.(You might think “I thought we’re trying to get rid of those!” Yes we try to keep them to a minimum. We’re never going to get rid of them totally.)
To see the ARP cache on a PC, use arp -a .

We have couple of entries there.
Physical address is another name for a MAC address which is another name for “burned in” address.
Type dynamic means these are all learned addresses and we did not put these ARP entries statically.
Host A has no entry for a MAC address of bb-bb-bb-bb-bb-bb,( Mac address of all b’s which we assume the host B has), so Host A will send an ARP Request to the all-Fs Layer 2 broadcast address (ff-ff-ff-ff-ff-ff).
The request contains the IP address of Host B and is requesting the host with that address answer the request.

If we have four host connected to a switch, here’s how it’s going to go. Layer2 destination comes into that switch, forwarded at every port except the one it came in on.
So those ARP requests are all going to go out and everybody’s going to look at it.
So C and D are going to look at it and say: “OK I’m not 192.168.1.2 so I don’t care!” and it’s just discarded.
Host B though over there is going to say :” Hey I’m 192.168.1.2 ! I’m going to send an ARP reply.”

And the ARP reply goes straight back to the original request store and Host A gets the forwarded ARP reply from the switch. Host C and D are out of the picture by that point, and at that point Host A now has the IP address of Host B and the MAC address of Host B, and can start sending data and it’s going to make the entry just like the one we see here at the bottom:

The natural question at this point is : How long will this stay in the cache?
Because as long as this entries stay in the cache, Host A doesn’t have to send broadcast out again. If it wants to send something to 192.168.1.2 , it knows exactly how to do it.
Anyway the answer to that question is : from 5 to 20 minutes.

As you can see, these are the actual IP addresses on this particular router (10.2.1.1. and 10.1.1.1) and they are on a couple of FastEtherent ports, and the hardware address etc.
They’re not going to age out because they are local interfaces and that’s how you see the ARP cache of a router ( ‘show ip arp’)
DHCP: The Network Admin’s Best Friend
DNS and ARP perform important network functions, but our host needs some very important info before it can put those two protocols to work, and one of those pieces of information is “where is the DNS server?”.
The host is not created knowing what address we’re using for that on our network.
That host also needs to know:
What is my IP address?
What’s my network mask?
What are the IP addresses of the DNS servers?
What’s my default gateway?
You and I, the network admins, have two options when it comes to getting that info to the hosts:
- Visit each and every host on the network and configure all of this information manually (bad idea)
- Use DHCP to allow the hosts to acquire their IP address dynamically (good idea)
DHCP isn’t just for dynamic IP address assignment. Sooner or later, an important piece of DHCP info is going to change. – say, the IP address of your internal DNS server. (as you can see on this picture)

We would have two options to get that piece of information out.
If we’re using static configuration, we get to configure every single host yet again and change that one setting ( and add a DNS server), and then maybe you bring that server online and then you’ve got to go back and take that one out because your boss told you had to.
With DHCP, you get to let the hosts know about the change dynamically, and the hosts update their info themselves. Today’s networks demand dynamic assignment of IP address info, and that’s what DHCP is all about.
There are four DHCP message types used in such an address acquisition:
- Discover
- Offer
- Request
- Acknowledgment
A style note: Many DHCP docs use all upper case to describe the packets we’re about to see fly around our network – DHCPDISCOVER, DHCPOFFER, etc. that burns the eyes after a while, so I’m writing them in a friendlier style.
Our host gets the DHCP ball rolling by sending a DHCP Discover packet to the Layer 3 broadcast address 255.255.255.255. basically, this is the host yelling “Is anyone out there a DHCP server?”

Each and every DHCP server that receives that message responds with a DHCP Offer containing:
- The IP Address being offered to the client (from that server’s IP address pool. Our DHCP servers are going to have pools of addresses and then one of those addresses is taken from the pool and put in this offer and it can’t be given to anybody else while this negotiation is still going on.)
- The network mask offered to the client.
- The amount of time the client can keep and use this address (the lease)
- The IP address of the DHCP server making this offer.
This particular host with the Discover message is only going to be able to reach one DHCP server, but on other networks that’s not the case. You may have redundancy and you may keep them both on line all the time and you can have a wonderful situation like this:

We’ll take all the redundancy we can get and if we have two DHCP servers, they can actually answer that initial message. They will both send back DHCP offers and you can see they’re coming from two different servers and the host now has to choose which offer it’s going to accept.
You may think in this world of logic and Cisco Networking and etc., that it is extremely complex operation and algorithm that the host will use to choose which offer it’s going to take. You’d be wrong on that!
Should the host receive multiple DHCP offers, it uses a highly scientific method of choosing the best offer: It accepts the first offer received!!
The host will then broadcast another packet called a DHCP Request, identifying the server whose offer has been accepted. When a DHCP Server sees this request identifying another DHCP server as the one whose offer was accepted, the “rejected” server is then free to give the offered IP address to another client.(it returns the IP address to the pool)

The DHCP request is all about letting all the servers that made offers know: “Hey here’s the one I took and if I didn’t take yours, go ahead and throw that address back in the pool. We’re moving forward.”

Finally we wrap up with a DHCP Ack and this is the end of the process. This is a little bit more information that the host is going to need, and it’s all over. So that ack would be the ending of the acronym D.O.R.A .
You can configure a Cisco router to serve as a DHCP server. It’s a good backup. It’s a good skill to have. And a lot of people don’t have it and you can also have a Cisco router or a switch on the SVI acquire it’s IP address via DHCP, and you may think that’s not something we do terribly often! And you’d be right because we usually want those addresses to be stable. We don’t want to be pulling a random address out of the pool and putting it on a FastEthernet interface. But that skill comes handy once in a while too.