DNS over UDP is a fundamental networking protocol that allows devices to resolve domain names into IP addresses, and it primarily uses port 53 for its operations.
Let’s see a DNS query in action. Imagine your machine wants to visit www.example.com.
dig @8.8.8.8 www.example.com
You’ll see output similar to this:
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> @8.8.8.8 www.example.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 300 IN A 93.184.216.34
;; Query time: 12 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon May 20 10:00:00 UTC 2024
;; MSG SIZE rcvd: 59
The SERVER: 8.8.8.8#53 clearly indicates that your machine (the client) sent a query to 8.8.8.8 (a Google public DNS server) on port 53. The QUERY: 1 shows it was a single request, and ANSWER: 1 confirms a single IP address was returned. The Query time: 12 msec is the latency for this exchange. The MSG SIZE indicates the total packet size.
The core problem DNS over UDP solves is efficient name resolution across a distributed network. Before DNS, maintaining a single hosts.txt file on every machine was unscalable. DNS introduced a hierarchical, distributed database. UDP (User Datagram Protocol) was chosen for its speed and low overhead. Unlike TCP, UDP doesn’t establish a persistent connection or guarantee delivery order, making it faster for the small, often single-request/response nature of DNS queries. The query is sent to the DNS server’s port 53, and the server immediately sends back a response on the same port.
The entire process is straightforward: a client sends a UDP packet containing a DNS query to a DNS server’s IP address on port 53. The DNS server processes the query and sends back a UDP packet containing the answer, also on port 53. This is why firewalls are typically configured to allow UDP traffic on port 53 for both inbound and outbound connections for DNS.
The id field in the header is crucial for matching queries to responses, especially when a client might have multiple outstanding queries. The flags field indicates various states, such as qr (query/response) and rd (recursion desired). recursion desired means the client is asking the server to perform the full resolution on its behalf, rather than just forwarding the query to another server.
The QUESTION SECTION specifies what is being asked: the domain name (www.example.com.) and the record type (A for IPv4 address). The trailing dot . is significant; it signifies the root of the DNS namespace.
The ANSWER SECTION contains the actual result. www.example.com. is the name, 300 is the Time To Live (TTL) in seconds, indicating how long the client should cache this record, IN means "Internet" class, A is the record type, and 93.184.216.34 is the IP address.
The OPT PSEUDOSECTION is for Extended DNS (EDNS), which allows for larger UDP packet sizes and additional options. udp: 512 here indicates the client’s advertised UDP payload size limit for the response. If the response would exceed this, the server might truncate it and send a message indicating that the client should retry with TCP or a larger UDP buffer.
The "surprise" about DNS over UDP is that despite its ubiquity and simplicity, it’s fundamentally insecure by default. Queries and responses are sent in plain text, meaning they can be easily intercepted, read, or even modified by an attacker. This has led to the development of DNS over TLS (DoT) and DNS over HTTPS (DoH) to provide encryption.
One aspect often overlooked is the role of the client’s ephemeral port. While the DNS server listens on port 53, the client sends its query from a random, high-numbered ephemeral port (e.g., 54321). The DNS server then sends its response back to this ephemeral port on the client’s IP address. This is why firewall rules typically allow UDP port 53 for both directions, but specifically, the server-to-client traffic is directed to the ephemeral port that originated the query.
The next logical step after understanding basic DNS resolution is exploring how DNSSEC adds integrity and authentication to these queries, or how DNS caching works to reduce latency and load.