BIND config error in ip/nameserver

Question

I setup a couple of nameservers and updated my domain to use them, and as far as I can tell everything went fine and the nameservers have been updated, or so says every whois and dnstools type site ive used, (intodns, who.is etc are all saying the same thing: the new nameserrvers are in effect, and the site points to the new ip just fine). Problem is that The site is not showing up, and dig tells me that the old ip/nameservers are still effective.

In my DNS Records I have:

domain. A IN NS ns1.newnameserver

domain. A IN NS ns2.newnameserver

ns1 IN A newipaddress

ns2 IN A newipaddress

domain. IN A newipaddress

I'm very short on time and haven't found anything on the interweb, so any help would be much appreciated

Answer 1

The old IP address is probably being cached by the server you queried. First of all, check that BOTH your new authoritative nameservers are publishing the correct address by querying them directly with dig:

dig @ns1.newnameserver domain. a
dig @ns2.newnameserver domain. a

Assuming those queries give correct answers, dig some other servers that aren't:

dig domain. a     # Use the system's default resolvers
dig @8.8.8.8 domain. a     # Use Google's public resolver
dig @some.other.ip.address domain. a

If it gives the old answer, look at the TTL. That's the numeric field listed in the answer just after the name and before "IN". That's how many seconds you have to wait until the server you queried discards its cached data and will query the authoritative servers again.

Ask those same nameservers where they think "domain." is delegated:

dig domain. ns     # Use the system's default resolvers
dig @8.8.8.8 domain. ns     # Use Google's public resolver
dig @some.other.ip.address domain. ns

You want to see 2 NS reocrds for "domain.", one pointing to "ns1.newnamserver" and the other one to "ns2.newnameserver", but the resolvers likewise cache that information so they might still have the old nameservers. If so, look at the TTL on those NS records too. If the TTL on those records is longer than the TTL on the A records, those resolvers may still go to the old nameservers to get "domain."'s A records even when their currently cached copy expires... so you may need to wait for that TTL to expire first, and then for the TTL on the actual A record to expire again!

Another thing you can do is query some of the authoritative nameservers for the PARENT domain of your domain to see if they are indeed delegating it to "ns1.newnameserver" and "ns2.newnameserver". This will verify that the delegation in DNS matches what's in WHOIS.

dig com. ns      # If your domain's parent domain is "com."
dig @<one-of-the-servers-that-resulted-from-that-query> domain. ns

Again, you want to see 2 NS reocrds for "domain.", one pointing to "ns1.newnamserver" and the other one to "ns2.newnameserver".

Answer 2

If the old nameservers are still running, either:

1. make sure they aren't, or
2. make sure they've also got the new zone data

Some people will still be talking to the old nameservers, and until they either stop answering or give the right answer, they won't learn the new nameservers from the parent zone.