As you may or may not know, I’m a bit crazy when it comes to DNS, it’s something that’s is conceptually easy, very complex, and there’s something new EVERY DAY.
So why is i t a bad idea to test your dns records immediately after publishing them, or before adding them, or any of that?
Let’s start by checking your test plan, do you check with ping, host, dig, nslookup, web tool, chrome, etc? Well if you are using your systems default resolution path, you’re likely hitting a cache tier (dns recursive resolver) and shooting yourself in the foot. If you know the records are cached with your domain managed TTL that you control, but what about records that don’t exist? They don’t cache…right? WRONG. They absolutely do, and some systems like Microsoft’s DNS Server cache nxdoamin answers for up to an hour by default! No wonder folks like godaddy say “please allow up to 48 hours blah blah blah”
So what IS a good test plan.
- do what your resolver does, ask a nameserver. a simple dig @ your authoritive nameserver will do it. my personal favorite way is using a quick one line bash script.
for NS in $(dig NS +short example.com); do dig @$NS A example.com +short; done
- Once the record is resolved at your nameservers, Check the SOA record, it MAY have changed (not all dns these days uses the dns method of notifying slaves with a soa serial bump)
dig SOA +short example.com; dig SOA +short @a.iana-servers.net
- If the SOA matches, you’ve got a good chance your cache server is ready for that fresh dns record.
As always, hopefully this answered the why to your problem, now that you know more about it you can level up your google-fu and find more about this topic!