Understanding DNS DIG Query Results: Decoding TTL Values in Additional Section Records


12 views

When executing dig queries, the Additional Section contains extra records that weren't explicitly requested but are related to the query. These typically include:

;; ADDITIONAL SECTION:
host.example.com.   300 IN  A   192.0.2.1

Each record in the Additional Section follows this structure:

<domain>.       <TTL>  IN  <record type>  <value>
janus.radore.com.   831 IN  A   109.235.251.213
  • 831/458/586: These numbers represent the Time To Live (TTL) in seconds
  • IN: Internet class (virtually always present)
  • A: Record type (A record in these examples)
  • IP address: The actual resolution

Let's examine a complete dig query and its output:

$ dig @8.8.8.8 google.com NS +additional

;; ANSWER SECTION:
google.com.     21599   IN  NS  ns2.google.com.
google.com.     21599   IN  NS  ns1.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.     74569   IN  A   216.239.32.10
ns2.google.com.     45794   IN  A   216.239.34.10

To analyze your nameserver performance, you can:

  1. Check response times with multiple dig runs
  2. Compare TTL values across different queries
  3. Monitor changes in additional records over time

Here's a bash script to measure response times:

#!/bin/bash
DOMAIN="yourdomain.com"
NAMESERVERS=("ns1.yourprovider.com" "ns2.yourprovider.com")

for ns in "${NAMESERVERS[@]}"; do
    echo "Testing $ns"
    time dig @$ns $DOMAIN > /dev/null
done

Use these dig flags for deeper investigation:

dig +stats +nocomments +nocmd google.com
dig +trace example.com
dig +short google.com NS | xargs -I {} dig +short {} A

TTL values indicate how long records can be cached:

  • High TTL (e.g., 74569): Stable infrastructure, less frequent changes
  • Low TTL (e.g., 300): More dynamic infrastructure, potential changes coming

Besides A records, you might see:

;; ADDITIONAL SECTION:
mail.example.com.   3600    IN  MX  10 mail.server.com.
_server._tcp.example.com. 3600 IN  SRV 0 5 5060 sip.example.com.

When executing dig queries, the additional section provides supplementary DNS records that weren't explicitly requested but are related to the query. The format follows this structure:

;; ADDITIONAL SECTION:
hostname.          TTL   IN  RECORD_TYPE  VALUE

The numeric values you're seeing (like 831, 458, 586) represent the Time-To-Live (TTL) in seconds. This indicates how long the record can be cached before it should be refreshed.

Let's analyze Google's nameserver records from your example:

ns1.google.com.     74569   IN  A   216.239.32.10
ns2.google.com.     45794   IN  A   216.239.34.10

Key observations:

  • Extremely high TTL values (20+ hours) indicate stable infrastructure
  • Multiple nameservers provide redundancy
  • IP addresses are in the same network range for consistency

To evaluate your nameservers' performance, consider these approaches:

# Basic response time test
$ time dig @ns1.yourdomain.com yourdomain.com

# Comprehensive test with DNSPerf
$ dnsperf -s ns1.yourdomain.com -d queryfile.txt -c 10 -l 30

Key metrics to monitor:

  • Query response time (should be < 100ms ideally)
  • Success rate (should be > 99.9%)
  • Consistency across different geographic locations

Your domain's records show varying TTLs:

janus.radore.com.   831 IN  A   109.235.251.213
mimas.rh.com.tr.    458 IN  A   77.75.34.2

This suggests:

  • Medium TTL values (10-15 minutes) allow for flexibility in IP changes
  • Different TTLs across servers might indicate different update frequencies
  • You should verify if all nameservers respond consistently

Here's a Python script to analyze multiple nameservers:

import dns.resolver
import time

nameservers = ['ns1.yourdomain.com', 'ns2.yourdomain.com']
test_domains = ['yourdomain.com', 'www.yourdomain.com']

for ns in nameservers:
    resolver = dns.resolver.Resolver()
    resolver.nameservers = [ns]
    
    print(f"\nTesting {ns}")
    for domain in test_domains:
        start = time.time()
        try:
            answer = resolver.resolve(domain)
            latency = (time.time() - start) * 1000
            print(f"{domain}: {latency:.2f}ms - {answer.rrset.ttl}s TTL")
        except Exception as e:
            print(f"{domain}: ERROR - {str(e)}")

This script measures both response time and verifies TTL values across all configured nameservers.

When adjusting TTL values for performance:

  • Lower TTL (300-900) before planned infrastructure changes
  • Higher TTL (86400+) for stable production environments
  • Gradual TTL reduction when preparing for DNS changes
  • Consider geographic distribution requirements