Master DNS: Basics, Configuration, and Real-World Troubleshooting with Docker

1 DNS Basics

The Internet uses TCP/IP; domains and subdomains (e.g., .com, .org, .edu) organize hosts. A hostname (e.g., example.com) is human‑readable, while machines communicate via IP addresses. DNS (Domain Name System) translates hostnames to IPs, and DNS servers provide this service.

2 Prepare Test Environment

To follow the exercises, a privileged Alpine container is created.

$ sudo docker pull alpine:3.8

$ sudo docker run -d --privileged --name ctn-1 alpine:3.8 sleep 3600d
$ sudo docker ps

Enter the container and inspect its network configuration.

$ sudo docker exec -it ctn-1 sh
# ifconfig

3 DNS Configuration

3.1 View DNS configuration

Linux reads DNS servers from /etc/resolv.conf. Inside the container:

# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.11
nameserver 192.168.1.12

3.2 Modify DNS configuration

Editing /etc/resolv.conf lets you specify preferred DNS servers, which is useful in private networks where internal DNS can also resolve public domains faster than ISP DNS.

4 DNS Troubleshooting

4.1 Machine without DNS configuration

Symptom: Network connectivity works (ping IP) but DNS lookups always fail.

Cause: No DNS server configured.

Solution: Add appropriate nameserver lines to /etc/resolv.conf.

Example with a correctly configured container:

# nslookup example.com
Name:    example.com
Address: 93.184.216.34
Address: 2606:2800:220:1:248:1893:25c8:1946

After commenting out the nameserver entries:

# nslookup example.com
nslookup: can't resolve 'example.com': Try again

4.2 DNS service too slow

Symptom: DNS queries take noticeably longer.

Cause: Inefficient or distant DNS server.

Solution: Switch to a faster DNS server in /etc/resolv.conf.

Install the powerful dig tool: # apk update && apk add bind-tools Query using an internal DNS server:

# dig example.com
... Query time: 0 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)

Switch to Google’s public DNS (8.8.8.8) and re‑run:

# dig example.com
... Query time: 150 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

4.3 Hard‑coded /etc/hosts bypasses DNS

Symptom: A domain resolves to the same IP every time, or becomes unreachable.

Cause: An entry in /etc/hosts overrides DNS.

Solution: Remove or correct the hard‑coded entry.

Before editing, repeated ping baidu.com shows different IPs (thanks to DNS load‑balancing). After adding a static entry:

# echo "123.125.115.110 baidu.com" >> /etc/hosts
# ping baidu.com
PING baidu.com (123.125.115.110): 56 data bytes
...

The IP no longer changes, which may degrade performance or cause failures.

4.4 Unstable DNS queries caused by traffic‑control (tc) or iptables

Symptom: DNS lookup latency varies wildly.

Cause: tc or iptables rules introduce artificial delay or packet loss.

Solution: Inspect and remove problematic rules.

Install iproute2 and add a 600 ms delay to the container’s eth0 interface:

# apk add iproute2
# tc qdisc add dev eth0 root netem delay 600ms
# dig example.com
... Query time: 600 msec

Delete the rule to restore normal latency:

# tc qdisc del dev eth0 root

4.5 Unstable reverse DNS lookups

A machine may experience long pauses when pinging a hostname, even though dig and direct IP ping are fast. Tracing shows the pause occurs in gethostbyaddr(), which performs a reverse DNS lookup. Changing the DNS server in /etc/resolv.conf resolves the issue.

References

https://stackoverflow.com/questions/614795/simulate-delayed-and-dropped-packets-on-linux

https://docs.docker.com/engine/reference/commandline/run/#options

https://support.suso.com/supki/What_is_the_difference_between_a_hostname_and_a_domain_name

https://en.wikipedia.org/wiki/Domain_name