Q7 DNS TTL and Resolution

Question 1

(2023) Discuss the pros and cons of using a shorter TTL value for a DNS resource record.

Answer 1

Pros and Cons of Shorter DNS TTL:
◦ TTL (Time To Live): A value in a DNS resource record that tells caching DNS servers and client resolvers how long they should store the record in their cache.

Pros of Shorter TTL:
▪ Faster Propagation of Changes: When a DNS record is updated (e.g., changing the IP address for a hostname), a shorter TTL means that caching servers and clients will expire their old cached information sooner and request the new record. This allows changes to take effect more quickly across the Internet. This is particularly useful when migrating services or changing IP addresses.

Cons of Shorter TTL:
▪ Increased Load on Authoritative Servers: Clients and caching servers have to query the authoritative DNS servers more frequently as cached entries expire faster. This can significantly increase the traffic volume and load on the authoritative servers.
▪ Potential Performance Impact: Increased query traffic can potentially add latency to DNS lookups if servers are heavily loaded.
▪ Increased Vulnerability (indirect): Higher server load can potentially make authoritative DNS servers more susceptible to Distributed Denial of Service (DDoS) attacks.

Question 2

(2024) Describe how the servers in DNS resolve the fully qualified domain name www.google.com collaboratively (assuming a computer inside the domain otago.ac.nz needs to access it).

Answer 2

1. Client Resolver Query: A computer in the otago.ac.nz domain wants to access www.google.com. Its operating system’s DNS resolver library (or client) first checks its local cache and host files (/etc/hosts) for the IP address of www.google.com.
2. Query Local Name Server: If the address is not found locally, the client sends a query to its configured local DNS server (typically specified in /etc/resolv.conf), which is a name server for the otago.ac.nz domain. This is often a recursive query request.
3. Local Server Queries Root Servers: The otago.ac.nz name server is not authoritative for google.com. It needs to resolve this name. It queries one of the well-known root DNS servers.
4. Root Server Refers to .com TLD Servers: The root server does not have the specific record for www.google.com, but it knows which servers are authoritative for the Top-Level Domain (TLD) .com. It responds to the otago.ac.nz name server with a list of .com TLD name server IP addresses (an iterative response).
5. Query .com TLD Servers: The otago.ac.nz name server then queries one of the .com TLD name servers. The .com server does not have the final record, but it knows which servers are authoritative for the google.com domain. It responds with a list of google.com authoritative name server IP addresses.
6. Query google.com Authoritative Servers: The otago.ac.nz name server queries one of the google.com authoritative name servers. This server contains the actual DNS records for google.com, including www.google.com. It finds the A or AAAA record for www.google.com and returns the corresponding IP address to the otago.ac.nz name server.
7. Local Server Caches and Responds: The otago.ac.nz name server receives the IP address for www.google.com. It caches this information (respecting the record’s TTL) for future queries. It then sends the IP address back to the original client resolver.
8. Client Caches and Connects: The client resolver receives the IP address, caches it, and provides it to the application (e.g., web browser), which can then initiate a connection to the web server using the IP address.