Ask the Expert: Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS)

[ciscomoderator]

Welcome to this Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about the Dynamic Host Configuration Protocol (DHCP) and the Domain Name System (DNS), two primary services in today's IPv4 and IPv6 networks. This event will focus on discussing and answering questions concerning the detailed operation of these protocols and services and their implementation, optimization, and troubleshooting.

Cisco Designated VIP Peter Palúch is an assistant professor and a Cisco Networking Academy instructor/instructor trainer at the University of Zilina, Slovakia. His fields of interest include routing, switching, and service provider technologies. He is a seasoned teacher who has cooperated in various educational activities in Slovakia and abroad, focusing particularly on networking and Linux-based network server systems. Peter holds a doctoral degree in the area of VoIP quality degradation factors; he is CCIE no. 23527 certified in routing and switching.

Remember to use the rating system to let Peter know if you have received an adequate response. 

Because of the volume expected during this event, Peter might not be able to answer every question. Remember that you can continue the conversation in the Network Infrastructure Community, under the subcommunity IPv6 Integration and Transition, shortly after the event. This event lasts through July 18, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

[Antonio Moraes]

Hello, Peter!

Yes, you got it right! I was asking about a Dynamic DNS Client for use in my CentOS.

Actually, I use good old dyndns.org and my classic Linksys WRT56G AP/Router at home does the trick. I was just curious if a Linux box could act more like a windows host when it is an Active Directory member doing dynamic registering on a Domain Controller. But, hey, this is getting completely out of scope! ehehehehehe :D

Thank you again! You are just great!

Best regards,

Antonio.

[ivandolnak]

Hi Peter! :)

Is there any possibility how to bind IP address to MAC address in IOS?

Thanks.

[Ananth B Shankar Rao]

Hi ivabdolnak

When DHCP server hands over the ip address - it creates a binding of IP address and the mac address of the  host which requested the IP address.

But, there is no in built security in DHCP. What I mean is, suppose Host A has mac address X and requests  an IP address from Server B. The server B hands over an IP address 1.1.1.2 and creates an entry in the DHCP binding table -  X -1.1.1.2. Now suppose A again requests an IP address , B will check the binding table and return the same ip address 1.1.1.2 .

If  Host A changes mac address to Y and requests IP address again, the server will handover a new IP address. This is the famous DHCP Starvation attack.

To solve this DHCP Snooping was created. DHCP Snooping actually prevents rogue DHCP server attack but it creates a database which has IP address , MAC address and interface from the request came.This is configured on the switch.

For example 1.1.1.2   X Fa0/0 

But this still does not prevent the DHCP starvation attack. 

To mitigate this attack - IP Spoof guard  is created which actually checks if the IP address is coming from the proper port and is it using the proper mac address.

This along with Port security on the switches and dot1x authentication can actually create a secure IP address to mac address binding.

 

[Peter Paluch · Accepted solution]

Hi anbs,

Thank you for sharing your insight.

I believe Ivan was focused on a different issue - he was not asking about maintaining an IP/MAC correspondence gained by gleaning the DHCP communication but rather how to configure the DHCP server itself so that you can manually bind an IP address to a particular host identified by its MAC or Client ID.

The DHCP Snooping is actually a very nice and relevant topic to this thread. The purpose of DHCP Snooping is multifold:

• Prevent broadcasted client messages (DISCOVER, REQUEST, DECLINE, INFORM, RELEASE) from leaking to other clients
• Prevent broadcasted server messages (OFFER, ACK, NAK, LEASEQUERY) from leaking to any other client than the one for whom they are intended
• Prevent clients from sending server messages
• Prevent clients from sending client messages on behalf of other clients
• Prevent clients from sending malicious messages (for example, clients inserting Option 82, or clients sending messages with the chaddr field being different from their MAC address)
• Prevent clients (and even servers) from sending excessive amounts of DHCP traffic

Discussing its details would be a delight - but let's see first if anyone of our readers is interested.

To mitigate this attack - IP Spoof guard  is created which actually checks if the IP address is coming from the proper port and is it using the proper mac address.

I am sorry but I do not agree with this statement. DHCP communication is basically a control plane traffic. IP Source Guard protects primarily the data plane traffic by making sure it is sourced only from an IP address (and optionally a corresponding MAC address) that was assigned to a particular station on a particular switchport by the DHCP server. I do not believe that IP Source Guard is able to prevent the DHCP Starvation attack because for a particular IP/MAC combination, it can start doing its job only after DHCP performs the assignment, not before.

The DHCP Starvation attack in particular can be prevented by a combination of countermeasures: configuring DHCP Snooping rate limiting if high intensity attacks are expected, and then by the tools you have suggested yourself: using Port Security to limit the maximum number of MAC addresses on a port, and potentially 802.1X per-host authentication.

Best regards,
Peter

[Peter Paluch]

Hi Ivan,

Thank you for joining!

Cisco IOS does allow you to define manual IP/MAC bindings. Be aware, though, of the following facts:

• The IP/MAC bindings can either be specified directly in the running-config, or they can be stored and imported using a text file.
  • Storing the bindings in the running-config requires you to create one pool per host. Fortunately, IOS DHCP server supports what is called an attribute inheritance: you can configure a separate pool for the entire network where the static leases also fall under, define all common parameters (default gateway, domain name, DNS servers, etc.) and then configure only minimalistic per-host pools, and they will inherit the common parameters so you don't need to repeat them in each per-host pool.
  • Using the text file allows you to use a single pool for all IP/MAC bindings specified in the file, but you have to create the text file manually and make it available to IOS, and if you want to change it, you must disable the DHCP service entirely in the IOS and reenable it after you have finished editing the file - or at least remove and recreate the pool that refers to the static bindigs file.
• Hosts can identify themselves to a DHCP server using DHCP Option 61 - the DHCP Client ID. This depends on the particular operating system running on the host. Most clients including Windows and IOS nowadays use it. The IOS DHCP server has a peculiarity - it prefers the Client ID to the MAC address. If the client has identified itself using Option 61 then only Option 61 value, and not the MAC address, must be used in the per-host pool or the text file. You could specify the host's MAC address in the pool but it would be ignored - it would be used only if the client did not send the Option 61 in its DHCP messages. Option 61 is an opaque value, it can be several tens of bytes long, and finding out its value used by a particular client may require sniffing the DHCP traffic, as the operating system might not show you this value without digging deep. In addition, because the value of Option 61 is defined by the operating system, you may end up having multiple Client IDs for a single station if it runs different operating systems, quite a nightmare to manage.

In any case, what you request is doable.

Assuming you want to proceed with the per-host pool configuration, consider this example:

ip dhcp excluded-address 192.168.1.0 192.168.1.255
!
ip dhcp pool BasicLAN
  network 192.168.1.0 /24
  default-router 192.168.1.1
  dns-server 4.2.2.2
  domain-name example.com
!
ip dhcp pool Host1
  host 192.168.1.11 /24
  hardware-address 0200.0102.0304
!
ip dhcp pool Host2
  host 192.168.1.12 /24
  client-identifier 0063.6973.636f.2d30.3031.322e.3830.3031.2e32.3030.302d.4661.302f.30

First of all, notice that the excluded address range covers the entire range defined in the BasicLAN pool. In combination with the per-host pools, this causes the DHCP server to not assign any dynamic leases, and only respond to requests from the two hosts defined in the per-host pools Host1 and Host2. In other words, this configuration does not assign any addresses to clients that are not defined statically in the per-host pools. Of course, you are free to allow dynamic leases as well - in that case, you would simply modify the ip dhcp excluded-address statement appropriately. You do not even need to explicitly exclude those addresses that are mapped statically.

The BasicLAN pool in this example is not mandatory and could be omitted along with the ip dhcp excluded-address command. However, for all clients, both dynamic and static in the 192.168.1.0/24 range, it defines the common parameters - gateway, DNS, domain. If I did not create this pool then I would need to define all these attributes in per-host pools repeatedly. Therefore, even though no client is currently going to be dynamically served from the BasicLAN pool itself, it is still beneficial as a placeholder for all common attributes that will be inherited by more specific pools.

Afterwards, two per-host pools follow. The Host1 pool is an example of a pool that would be used for a client using the MAC address 0200.0102.0304 - but if and only if this client does not send Option 61 in its DHCP requests. If it does then the value of the Option 61 will be used as the key to match the appropriate pool, and as a result, the Host1 pool will be ignored.

The Host2 pool is an example of using the Option 61, or the Client ID, to identify a particular client. The Client ID used in the example is rather extreme but this is exactly how Cisco IOS presents itself as a DHCP client. Usually, Windows operating systems use a 7 octet Client ID, starting with 0x01 (the Ethernet HW type indicator) and followed by 6 octets of the MAC address - but do not bet your last dime on it

The host lines in both per-host pools then define the static IP address and netmask assigned to particular hosts. This is how the inheritance is accomplished: Because both specified IP addresses fall under the 192.168.1.0/24 network in the BasicLAN pool, its attributes are inherited onto the more specific per-host pools.

Should you be interested in learning more about the text file approach then please visit the IOS DHCP Configuration Guide that describes the format of the file quite nicely - probably better than I can

Please feel welcome to ask further!

Best regards,
Peter

[huangedmc]

hello Peter,
Nowadays the source IP no longer represents the actual location of the endpoint.
You can have an IP range obtained from RIPE advertised in the U.S.

Many GSLB products that work in conjunction w/ DNS, such as Cisco's GSS, rely on the IP-to-location mapping to provide geo-location information.

How do you think people can work around this caveat?

thanks,
Kevin

[Peter Paluch]

Hi Kevin,

I apologize for my late answer - this has been a busy week and I had to do some research on your question. As always, you've got some great issue at hand.

I believe that with geographical DNS, we simply cannot rely on IP addresses alone to do a decent geographical guess. You have noted yourself that because of various reasons, IP addresses governed by one RIR can be advertised in a different geographical region. That essentially breaks all schemes that have so far used the relation between an IP address and the RIR it belonged under.

And this is, in my opinion, going to be even worse. With the shortage of IPv4 addresses, I can very well see some companies, especially those with Class A and Class B network addresses purchased a long time ago, consolidating their internal address space and profitably selling off parts of their address ranges. And add LISP and similar technologies to the soup! In LISP, there is the notion that an IP address currently conveys both the identity and the location of the endpoint, and these two aspects should be split. A host's identity, once assigned, should never change unless the host itself changes. And if the host moves,it's identity should remain the same, just the location information has changed. So, regardless of where the host resides, it is going to be identified by the same address again and again. Tunnelling servers and mapping services are going to provide the translation between the identity and its current location, and tunnel the packets accordingly. Because LISP is a service that is enabled in the network infrastructure and not on hosts themselves, the hosts never know that the IP address they communicate with is possibly only an EID (Endpoint ID) and that it is going to be tunneled to a possibly different RLOC (Routing LOCator). The interaction between the host's identity, its current IP location, and its true geographical location just becomes more complex.

My personal opinion on this is that unless there is true geographical data stored for individual entries in DNS, resorting to IP addresses and RIRs is just doing a best guess, and won't get better over time. Now, DNS actually has two Resource Record types for the geographical position. In RFC 1712, the GPOS RR type is defined to carry basic geographical coordinates. It is considered superseded by RFC 1876 where the LOC RR type is defined, using GPS style of coordinates. Just for your information, RFC 1712 was published in 1994, RFC 1876 was published in 1996. Now it's 2014 and despite all substantiated worries about GSLB based on IPs alone being inadequate, it is simply interesting to see that the tools to solve this problem have been available almost all the time.

So my personal view on this is that GSLB has benefitted a lot from the former close ties of IPs to geographical regions but as these ties are becoming weaker, so is the GSLB's ability to make correct choices. As the IPs become uncoupled from their location, also thanks to LISP and similar technologies, they simply cannot be used anymore as location keys. I believe that the proper solution would be to start using true geographical data in DNS to allow the GSLB servers to make proper choices.

What is your idea on all of this?

Best regards,
Peter

[huangedmc]

hi Peter,

Thanks for the reply.

I know this is a tough issue, which is why GSS also includes other mechanism to influence the load balance decision, such as RTT in ICMP reply, to see which datacenter is closer to the endpoint.

This still doesn't solve the issue at hand, which is a mapping between IP & physical location.

Very interesting find on the two RFC's that actually allow us this ability in the past 10 years, but nobody's using it.

Wouldn't it be scary, and useful at the same time?

It's scary because if the ISP's were to populate the GPOS, or LOC records in DNS for the IP's that they assign to their customers, nobody would be anonymous anymore, when they browse the web.
It would be very easy for people to find where your home is, and use it for malicious purpose. (unless of course, you go through a VPN/proxy)

It's useful because law enforcement can locate exactly where the bad guys are w/o asking the ISP's, if they're dumb enough to leave their trail on the Internet.

It could also be useful for e-commerce...imagine you never have to key in your ship-to address again.
The Amazon shopping cart automatically populate the address field for you, w/o having to set up an account.

I always turn off location services on my iPhone by the way...

Kevin

[Peter Paluch]

Hi Kevin,

A great debate!

I know this is a tough issue, which is why GSS also includes other mechanism to influence the load balance decision, such as RTT in ICMP reply, to see which datacenter is closer to the endpoint.

Yes, these are much more relevant indicators - but they are true network performance parameters, and quite honestly, these are the ones we should be optimizing and using to make routing decisions.

This still doesn't solve the issue at hand, which is a mapping between IP & physical location.

That is correct. And as I explained earlier, the ties between an IP address and its geographical location have become wery weak and will continue to weaken further.

There is a different question, though: Is the mapping between an IP address and its geographical location truly relevant? Does it always translate into better performance? You have indicated yourself that there are other parameters we can use to estimate the network performance, and just having the clients and servers in the same geographical area does not necessarily translate into the best performance. It all depends on the network infrastructure. So ultimately, the question is: even if we had the correct geolocations of IP addresses mapped in some service, would it be worth the effort? As for myself, I am not that sure.

Very interesting find on the two RFC's that actually allow us this ability in the past 10 years, but nobody's using it.

It's really strange, isn't it?

Wouldn't it be scary, and useful at the same time?

There certainly is a potential for a gross misuse but at the same time, you have to be aware of an important fact.

The first fact is that it is you, not the DNS alone, who is going to create those GPOS or LOC entries in the DNS. The data in these records is entirely defined by you. Nobody wants you to make it precise or absolutely truthful. It is sufficient for you to point somewhere in your country, not necessarily directly to your premises.

And if the idea was good, you could always come up with a similar location DNS record type that holds only an approximate, intentionally inaccurate (to a certain point) data about the location that does approximate your geolocation but does not reveal your precise spot on the Earth's surface.

I'd say... if there is a will, there are lots of means to do things right. Should there be a will.

As always, your insight is most welcome!

Best regards,
Peter