The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the steps used to configure DNS servers within Bash to allow for the resolution of DNS hostnames to IP addresses.
Cisco Nexus 3000 and 9000 series devices allow access to NX-OS's underlying Linux system through Bash (Bourne-Again SHell). Bash enables system management and monitoring through a Linux environment. For more information about Bash on NX-OS, refer to the Bash chapter of the Cisco Nexus 9000 Series NX-OS Programmability Guide.
It may be necessary to translate human-friendly domain names into numeric IP addresses while performing normal tasks in the Bash shell. Such tasks include using the curl
or wget
utilities to access resources from a web server or to download Docker images using the docker pull
command.
This document is not restricted to specific software and hardware versions.
Note: The Bash shell is to be enabled on your Cisco Nexus device. Refer to the "Accessing Bash" section of the Bash chapter in the Cisco Nexus 9000 Series NX-OS Programmability Guide for instructions to enable the Bash shell.
The information in this document is based on these software and hardware versions:
The information in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
The Linux environment accessed through the Bash shell utilizes the /etc/resolv.conf file to store DNS configuration, similarly to most other Unix-like operating systems.
1. Log in to the Bash shell as the root user through the run bash sudo su -
command.
Nexus# run bash sudo su - root@Nexus#whoami root
2. View the current contents of the /etc/resolv.conf file. In this example, the file is empty.
root@Nexus#cat /etc/resolv.conf root@Nexus#
3. Open the /etc/resolv.conf file for editing using the vi
text editor.
root@Nexus#vi /etc/resolv.conf
4. Press the i
key to enter INSERT mode, then enter your desired configuration. Refer to the /etc/resolv.conf File Format section of this document for more information about how the format of configuration within the /etc/resolv.conf file.
5. After the file is modified, press the ESC
key to exit INSERT mode, then enter :x
to save all changes to the file and close it.
Once the changes are made to the Bash shell's DNS configuration, verify that the changes result in successful domain name resolution. The simplest method of testing domain name resolution is through using the ping
utility using a domain hostname as a target. This document demonstrates how to verify valid DNS configuration using a test host of test.cisco.com and DNS servers of 192.168.2.1 and 192.168.2.2.
By default, the Bash shell uses the default network namespace unless instructed otherwise. Network namespaces are logically equivalent to NX-OS VRFs, and the ip netns
the command displays a list of namespaces that are available to the Bash shell, as demonstrated below:
root@Nexus#ip netns EXAMPLE-VRF (id: 2) management (id: 1) default (id: 0)
A valid network namespace to test with is one that has IP connectivity to the DNS nameservers configured in the /etc/resolv.conf file, as well as IP connectivity to the IP address that your test host resolves to.
One can utilize the ip netns exec {namespace} {desired-command}
command to execute a command {desired-command}
in the namespace {namespace}
. Alternatively, one can execute the Bash shell within the context of a specific namespace with the ip netns exec {namespace} bash
command. The former methodology is used in the example here, it is verified that the management namespace has IP connectivity with the IP address owned by the test.cisco.com host (which is 192.168.2.100) and both DNS servers (192.168.2.1 and 192.168.2.2).
root@Nexus#ip netns exec management ping 192.168.2.100 -c 5 PING 192.168.2.100 (192.168.2.100) 56(84) bytes of data. 64 bytes from 192.168.2.100: icmp_seq=1 ttl=59 time=0.277 ms 64 bytes from 192.168.2.100: icmp_seq=2 ttl=59 time=0.284 ms 64 bytes from 192.168.2.100: icmp_seq=3 ttl=59 time=0.280 ms 64 bytes from 192.168.2.100: icmp_seq=4 ttl=59 time=0.274 ms 64 bytes from 192.168.2.100: icmp_seq=5 ttl=59 time=0.297 ms --- 192.168.2.100 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4001ms rtt min/avg/max/mdev = 0.274/0.282/0.297/0.017 ms root@Nexus#ip netns exec management ping 192.168.2.1 -c 5 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=59 time=0.277 ms 64 bytes from 192.168.2.1: icmp_seq=2 ttl=59 time=0.284 ms 64 bytes from 192.168.2.1: icmp_seq=3 ttl=59 time=0.280 ms 64 bytes from 192.168.2.1: icmp_seq=4 ttl=59 time=0.274 ms 64 bytes from 192.168.2.1: icmp_seq=5 ttl=59 time=0.297 ms --- 192.168.2.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4001ms rtt min/avg/max/mdev = 0.274/0.282/0.297/0.017 ms root@Nexus#ip netns exec management ping 192.168.2.2 -c 5 PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data. 64 bytes from 192.168.2.2: icmp_seq=1 ttl=59 time=0.277 ms 64 bytes from 192.168.2.2: icmp_seq=2 ttl=59 time=0.284 ms 64 bytes from 192.168.2.2: icmp_seq=3 ttl=59 time=0.280 ms 64 bytes from 192.168.2.2: icmp_seq=4 ttl=59 time=0.274 ms 64 bytes from 192.168.2.2: icmp_seq=5 ttl=59 time=0.297 ms --- 192.168.2.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4001ms rtt min/avg/max/mdev = 0.274/0.282/0.297/0.017 ms
Use the ping
utility with a target of the test host's hostname. If ICMP Replies are received from the test host, and the IP address contained within the ICMP Replies is the IP address we expect the hostname to resolve to, then DNS resolution is confirmed to be working within the Bash shell.
This example here demonstrates how the ping
utility is used within the management namespace to verify correct DNS resolution. Note how the domain hostname of test.cisco.com resolves to 192.168.2.100, which is the IP address we expect that hostname to resolve to.
root@Nexus#ip netns exec management ping test.cisco.com -c 5 PING test.cisco.com (192.168.2.100) 56(84) bytes of data. 64 bytes from test.cisco.com (192.168.2.100): icmp_seq=1 ttl=59 time=0.617 ms 64 bytes from test.cisco.com (192.168.2.100): icmp_seq=2 ttl=59 time=0.341 ms 64 bytes from test.cisco.com (192.168.2.100): icmp_seq=3 ttl=59 time=0.310 ms 64 bytes from test.cisco.com (192.168.2.100): icmp_seq=4 ttl=59 time=0.379 ms 64 bytes from test.cisco.com (192.168.2.100): icmp_seq=5 ttl=59 time=0.296 ms --- test.cisco.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 0.296/0.388/0.617/0.119 ms
If the namespace used to test DNS resolution has IP connectivity to the Internet, one can ping cisco.com to verify that external domain names can be resolved in addition to internal domain names. This is particularly important if one needs to use utilities such as curl
and wget
against public web servers. The example here demonstrates how the ping
utility can be used within the management namespace (which has IP connectivity to the Internet) to verify correct external DNS resolution.
root@Nexus#ip netns exec management ping cisco.com -c 5 PING cisco.com (72.163.4.161) 56(84) bytes of data. 64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=1 ttl=239 time=29.2 ms 64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=2 ttl=239 time=29.2 ms 64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=3 ttl=239 time=29.3 ms 64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=4 ttl=239 time=29.2 ms 64 bytes from www1.cisco.com (72.163.4.161): icmp_seq=5 ttl=239 time=29.2 ms --- cisco.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 29.261/29.283/29.335/0.111 ms
Some common configuration parameters are explained here. Ensure to modify all the configuration parameters to match your environment.
{domain-name.tld}
to append to hostnames that do not end with a period. There can only be one domain
entry within the /etc/resolv.conf file.{domain-name-1.tld}
and, optionally, [domain-name-2.tld]
) to append to hostnames. Note: The domain
and search
entries are mutually exclusive - only one can be in use at a time. If both entries are included in the /etc/resolv.conf file, the entry that appears last in the file is used.
{address-1}
for a DNS server where DNS resolution requests are forwarded to. Multiple nameserver
entries are allowed within a single file, up to a maximum of three.This example shows the contents of the /etc/resolv.conf file where the default domain of the environment is cisco.com and DNS servers within the environment have IP addresses of 192.168.2.1 and 192.168.2.2. In this scenario, if the Bash shell needs to resolve the IP address for a device with a hostname of foo, it appends cisco.com to the end of the hostname such that the Fully Qualified Domain Name (FDQN) of the host is foo.cisco.com.
domain cisco.com nameserver 192.168.2.1 nameserver 192.168.2.2
The following example shows the contents of the /etc/resolv.conf file where either the cisco.com or the bar.com domain names may be used to resolve DNS hostnames. DNS servers within the environment have IP addresses of 192.168.2.1 and 192.168.2.2. In this scenario, if the Bash shell needs to resolve the IP address of a device with a hostname of foo, it attempts to resolve foo.cisco.com first, then attempt to resolve foo.bar.com next if the resolution for foo.cisco.com fails.
search cisco.com bar.com nameserver 192.168.2.1 nameserver 192.168.2.2