Why Does NSLOOKUP Return Both Old and New DNS Records When Querying Authoritative Nameserver?


5 views

When you query your authoritative nameserver directly using nslookup and see both old and new IP addresses, several technical factors could be at play:

nslookup example.com ns1.exampledns.com
Server:  ns1.exampledns.com
Address:  192.0.2.1

Name:    example.com
Addresses:  203.0.113.45  # Old IP
      198.51.100.22  # New IP

The most common reason for seeing both IPs is that the old record hasn't expired from cache yet. Even when querying authoritative servers directly, intermediate caching may occur. Check your DNS record's TTL value:

dig +nocmd +noall +answer +ttlid a example.com @ns1.exampledns.com
example.com.  3600  IN  A  203.0.113.45
example.com.  3600  IN  A  198.51.100.22

Some DNS setups intentionally return multiple IPs for load balancing. Verify if this is your case by checking the DNS configuration:

# BIND zone file example
example.com.  IN  A  203.0.113.45
example.com.  IN  A  198.51.100.22

To properly transition DNS records:

  1. Lower TTL values 24-48 hours before making changes
  2. Use DNS change verification tools:
# Linux/macOS verification command
for i in {1..10}; do 
  dig +short example.com @ns1.exampledns.com | sort -u
  sleep 5
done

For deeper investigation, use these commands:

# Check all authoritative name servers
dig +trace example.com

# Verify against each nameserver individually
for ns in $(dig +short ns example.com); do
  echo "Querying $ns:"
  dig +short example.com @$ns
done

When you query your authoritative nameserver directly using nslookup and see both old and new IP addresses, it typically indicates one of these scenarios:

# Example showing both IPv4 and IPv6 addresses
nslookup example.com ns1.example.net
Server:  ns1.example.net
Address:  2001:db8::1

Name:    example.com
Addresses:  203.0.113.45  # Old IP
          198.51.100.67  # New IP

Many developers assume this is a propagation issue, but when querying authoritative servers directly, we can rule out caching. The real reasons are more technical:

  • DNS Record Configuration: Multiple A records configured intentionally
  • TTL Mismatch: Different TTL values for records
  • Load Balancing: Round-robin DNS configuration
  • Transition Period: Gradual migration strategy

For deeper analysis, use dig to see the complete DNS response:

dig @ns1.mynameserver.com mydomain.com A

; <<>> DiG 9.16.1 <<>> @ns1.mynameserver.com mydomain.com A
;; ANSWER SECTION:
mydomain.com.    3600    IN    A    222.222.222.222
mydomain.com.    3600    IN    A    333.333.333.333

During DNS migrations, administrators often:

# Temporary DNS configuration during migration
$ORIGIN mydomain.com.
@    3600    IN    A    222.222.222.222
@    300     IN    A    333.333.333.333  # Lower TTL for new record

To check if this is intentional, examine your zone file:

# Sample BIND zone file snippet
mydomain.com.    IN    A    222.222.222.222
mydomain.com.    IN    A    333.333.333.333
www              IN    CNAME mydomain.com.

If you need to verify connectivity to just the new IP:

nslookup -type=A mydomain.com ns1.mynameserver.com | grep -A1 "Addresses" | tail -n1

Use this Python script to monitor when old IP disappears:

import dns.resolver

def check_dns(domain, nameserver):
    resolver = dns.resolver.Resolver()
    resolver.nameservers = [nameserver]
    answers = resolver.resolve(domain, 'A')
    return [answer.address for answer in answers]

current_ips = check_dns('mydomain.com', '111.111.111.111')
print(f"Current IPs: {', '.join(current_ips)}")