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:
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
ro#conf tNext, 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):
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
ro(config)#interface FastEthernet 0/0The name server received in the DHCP reply (192.168.2.2) is now missing from the running configuration:
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
ro#show run | include name-server
ip name-server 192.168.2.1
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.
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
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.
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
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.