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


3 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