Fundamentals 15 min read

Master DNS: Basics, Docker Setup, and Real-World Troubleshooting

This guide explains DNS fundamentals, shows how to set up a Docker container for testing, demonstrates configuring and modifying DNS settings, and walks through common DNS issues such as missing resolvers, slow queries, hosts file overrides, and unstable reverse lookups, with practical command‑line examples.

Open Source Linux
Open Source Linux
Open Source Linux
Master DNS: Basics, Docker Setup, and Real-World Troubleshooting

1 DNS Basics

The Internet is built on the TCP/IP protocol. To simplify host management, the Internet is divided into domains and sub‑domains, e.g., .com, .org, .edu are top‑level domains, while google.com is a sub‑domain of .com.

Every host belongs to a domain and has a hostname, e.g., example.com is a host name within the .com domain.

Hostnames are human‑readable; machines communicate using IP addresses. The Domain Name System (DNS) translates hostnames to IP addresses, and the servers that perform this translation are called Domain Name Servers.

When a browser accesses example.com, it first queries a DNS server for the IP address, establishes a TCP connection to that IP, and then sends an HTTP request.

A domain can map to one IP or multiple IPs. When multiple IPs exist, DNS returns one of them, enabling high availability (e.g., baidu.com resolves to several IPs).

Unstable DNS service can be caused by misconfigured DNS servers, network packet loss, or incorrect host DNS settings. The following sections explore several cases.

2 Preparing Test Environment

To follow the hands‑on exercises, a container environment is set up.

Pull Docker image: $ sudo docker pull alpine:3.8 Run the container with privileged mode (required for later tc commands):

$ sudo docker run -d --privileged --name ctn-1 alpine:3.8 sleep 3600d
$ sudo docker ps
CONTAINER ID    IMAGE       COMMAND          CREATED        STATUS          PORTS  NAMES
233bc36bde4b    alpine:3.8  "sleep 3600d"   1 minutes ago  Up 14 minutes          ctn-1

Enter the container: $ sudo docker exec -it ctn-1 sh View container network information:

# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:AC:11:00:09
          inet addr:172.17.0.9  Bcast:0.0.0.0  Mask:255.255.0.0

3 DNS Configuration

3.1 View DNS configuration

Linux stores DNS settings in /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

The file inherits the host's DNS configuration.

3.2 Modify DNS configuration

Edit /etc/resolv.conf to set the desired nameserver(s). In private networks, using an internal DNS server can provide faster resolution for both internal and external domains.

4 DNS Troubleshooting

This section simulates common scenarios that cause slow or failed DNS queries and provides troubleshooting steps.

4.1 No DNS configuration leads to lookup failure

Symptom: Network connectivity works (e.g., ping IP succeeds) but DNS lookups always fail.

Possible cause: The machine has no DNS server configured.

Solution: Edit /etc/resolv.conf to add appropriate nameserver entries.

Example using nslookup inside a normal container:

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

Comment out the nameserver lines in /etc/resolv.conf to simulate a missing DNS configuration, then run the lookup again:

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

Thus, verify /etc/resolv.conf when DNS lookups fail.

4.2 DNS service is too slow

Symptom: DNS queries are unusually slow.

Possible cause: The configured DNS server is sub‑optimal.

Solution: Change /etc/resolv.conf to use a faster DNS server.

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

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

Replace the nameserver with Google’s public DNS (8.8.8.8) and query again:

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

The latency increased from sub‑millisecond to 150 ms, showing the impact of a slower DNS server.

4.3 Hard‑coded entries in /etc/hosts bypass DNS

Symptom: Specific domain resolves to the same IP every time, or access to a domain is slow or fails.

Possible cause: The domain is hard‑coded in /etc/hosts.

Solution: Remove or correct the entry in /etc/hosts.

Example: pinging baidu.com yields different IPs on successive runs because DNS returns multiple addresses.

# ping baidu.com (first run)
PING baidu.com (220.181.57.216): 56 data bytes
... 
# ping baidu.com (second run)
PING baidu.com (123.125.115.110): 56 data bytes
...

Adding a hard‑coded line in /etc/hosts forces the same IP:

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

Therefore, avoid hard‑coding domain entries in /etc/hosts.

4.4 DNS queries become unstable

Symptom: DNS query latency varies widely.

Possible cause: Traffic control ( tc) or iptables rules introduce delay or packet loss.

Solution: Remove or adjust the offending rules.

Install iproute2 to use tc: # apk add iproute2 Check existing tc rules (none by default) and add a fixed 600 ms delay:

# tc qdisc add dev eth0 root netem delay 600ms
# tc -p qdisc ls dev eth0
qdisc netem 8001: root refcnt 2 limit 1000 delay 600.0ms

Querying DNS now shows the added delay:

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

Random or percentage‑based delays can be added similarly, and the rule can be removed with tc qdisc del dev eth0 root. Similar effects can be caused by iptables rules.

4.5 Unstable reverse DNS lookups

In a real‑world case, pinging an internal domain hung for several seconds, while dig returned results instantly. Tracing the ping process revealed it was blocked in gethostbyaddr(), which performs a reverse DNS lookup.

Running nslookup, host, or dig -x on the same IP exhibited the same hang. Changing the DNS server in /etc/resolv.conf resolved the issue, confirming that the problem lay with the reverse lookup on the DNS server.

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

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

DockerlinuxDNS
Open Source Linux
Written by

Open Source Linux

Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.