DNS resolver in Cisco IOS is auto-configured with parameters from a DHCP reply

If you're using DHCP to get IP interface addresses on your router (using the ip address dhcp interface configuration command), the router will also inherit the DNS resolver settings included in the DHCP reply. Makes sense, but the implementation is "a bit" unexpected: if you configure the DNS name servers manually with the ip name-server address-list command, the ones matching the values in the DHCP reply packet are not included in the running configuration and thus not saved to NVRAM. Even worse, the statically-configured name-servers overwritten by a DHCP reply are lost if the DHCP-configured interface goes down.

To avoid total confusion, you thus have these options:
  • Do not use DHCP to acquire IP interface addresses
  • Make sure the DHCP server does not send DNS-related parameters (a bit hard if you're using DHCP with your ISP)
  • Rely exclusively on DHCP to provide your router with the DNS name server addresses
Here is also an example of what can happen if you mix static configuration with DHCP. We'll start by configuring the name servers and verifying they are configured:
ro#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ro(config)#ip name-server 192.168.2.1 192.168.2.2
ro(config)#^Z
ro#show run | include name-server
ip name-server 192.168.2.1 192.168.2.2
Next, we'll configure DHCP client on an interface and watch the DHCP debugging to see what's actually going on (only parts of debugging printout are included):
ro(config)#interface FastEthernet 0/0
ro(config-if)#ip address dhcp
...
DHCP: Received a BOOTREP pkt
DHCP: Scan: Message type: DHCP Ack
DHCP: Scan: Server ID Option: 192.168.2.1 = C0A80201
DHCP: Scan: Lease Time: 86400
DHCP: Scan: Renewal time: 43200
DHCP: Scan: Rebind time: 75600
DHCP: Scan: Host Name: ro.address.net
DHCP: Scan: Subnet Address Option: 255.255.255.240
DHCP: Scan: Router Option: 192.168.2.1
DHCP: Scan: Domain Name: address.net
DHCP: Scan: DNS Name Server Option: 192.168.2.2
...
DHCP: Applying DHCP options:
Setting default_gateway to 192.168.2.1
Adding default route 192.168.2.1
Adding DNS server address 192.168.2.2
Setting default domain to address.net

%DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 192.168.2.5, mask 255.255.255.240, hostname ro
The name server received in the DHCP reply (192.168.2.2) is now missing from the running configuration:
ro#show run | include name-server
ip name-server 192.168.2.1

10 comments:

  1. Couldn't you use DNS views to remedy this problem and supply your own DNS settings? I would try something along these lines:

    ip dns view default
    dns forwarder 172.20.10.10
    dns forwarder 172.20.10.20
    ip dns view-list my-view
    view default 10
    ip dns server view-group my-view
    ip dns server

    You need to be running 12.4(9)T but it is a solution.
  2. DNS views don't help, the behavior stays the same, see below:

    r4#show ip dns view default
    DNS View default parameters:
    Logging is off
    DNS Resolver settings:
    Domain lookup is enabled
    Default domain name: test.com
    Domain search list:
    Lookup timeout: 3 seconds
    Lookup retries: 2
    Domain name-servers:
    192.168.0.1
    192.168.0.2
    192.168.0.3
    DNS Server settings:
    Forwarding of queries is enabled
    Forwarder addresses:
    r4#show run | section ip dns
    ip dns view default
    domain name-server 192.168.0.2
    domain name-server 192.168.0.3
  3. That seems to be the case when you use the domain name-server option, but not the domain forwarder option. I just checked my view I setup for a public network, and only the dns server I listed as the forwarder is there:

    DNS View public-view parameters:
    Logging is on (view used 1323 times)
    DNS Resolver settings:
    Domain lookup is enabled
    Default domain name:
    Domain search list:
    Lookup timeout: 3 seconds
    Lookup retries: 2
    Domain name-servers:
    DNS Server settings:
    Forwarding of queries is enabled
    Forwarder addresses:
    4.2.2.2

    This doesn't really matter now that you found the other dhcp client command in your latest post, but it does matter for those that are using multiple views.
  4. Finally I've found some time to investigate how it really works. The results are here.
  5. This article doesnt make much sense.

    Firstly, why would you want DNS servers received via DHCP to be placed into the running-config, or be written back to the startup-config? These are run-time variables, much the same as the routing tables that routing protocols build. These routes dont appear in the running configuration either as the next time the router boots up, some or all of them may no longer be vaild.

    If the router receives a list of DNS server addresses with a DHCP reply, and places them into the running-config, you now have potentially unstable run-time information in your configuration. If that configuration is written to NVRAM, you are now storing that potentially unstable information in your router.

    This somewhat defeats the purpose of DHCP which is to allow hosts to automatically configure themselves with the correct network settings. Having them statically configured also poses security risks, unless you control the DNS servers in question.

    Secondly, can you explain in more detail what you mean about the statically configured name servers being lost if the DHCP interface goes down?

    Name servers present in your startup/running configuration should not be "lost".

    Cheers,
    Tom
  6. Tom, I will not comment the first half of your comment, as we agree that the dynamic information (DHCP DNS, for example) should not be stored in static router config.

    As for the "lost DNS servers" - if you configure a static DNS server and subsequently receive the same DNS server's IP address in a DHCP reply, the dynamic DNS server overwrites the static declaration (IOS does not allow you to have two entries for a single DNS server) and is thus lost from the running/startup config ... as the example in the post has clearly demonstrated.
  7. We recently ran into a related issue involving VRF. If the interface obtaining config via DHCP receives name servers (requested or not) and the interface is assigned to a named VRF, the received name servers are associated with the global VRF instead of the named VRF. Makes front-door VRF somewhat less useful than it otherwise would be.
    Replies
    1. You might be able to work around that with DNS views, but it definitely is a stupid bug.
  8. A little late to the party here, but as a note, you can now use "no ip dhcp client request dns-nameserver" and "no ip dhcp client request domain-name" in the interface configuration for your client interface to ignore name server and hostname options when pulling a lease.
  9. Thanks Mikkel... saved my life.
Add comment
Sidebar