DNS propagation - why is a subdomain only accessible minutes after it's creation (own nameservers)

Question

we have a question about the behavior of DNS propagation for subdomains.

Here's the scenario we are trying to achieve:

User1 registers at our site "company.com". A subdomain "user1.company.com" is automatically created, not as add-on domain of "company.com", but as standalone account in WHM.

So, an own zone is being created & an A record is being set (same IP as company.com) NS records are also set to "ns1.domain2.com + ns2.domain2.com", our own nameservers (no clustering, 2 different IP's, BIND method, they are provided for the moment by the same WHM installation as for company.com & subdomains) Domain2.com is handled by our registrar GoDaddy, nameservers ns1 + ns2 are also defined there.

Our problem is that right after the creation the domain "user1.company.com" is not immediately accessible (unlike an add-on domain).

When we nslookup for example the new domain "user1.company.com" with the nameservers from our ISP, right after it's creation, we get "Non-existent domain". Then, after 1-15 minutes, and depending on the DNS we try, the nslookup answers with the correct IP address. The DNS from Google (8.8.8.8) for example immediately! answers with the correct IP address.

What exactly happens when the user tries to access his subdomain "user1.company.com"? Are our nameservers contacted to resolve the subdomain or are the subdomains somehow propagated across the DNS servers worldwide? But why does Google's DNS answer immediately, propagation can't be so fast!

Any ideas where may be the problem and how to make a subdomain account accessible immediately after its creation, regardless of the DNS being used by the user?

Many thanks

Marc

Answer 1

This is most likely due to negative caching. That is to say that a DNS server remembers that the subdomain doesn't exist, and replies with NXDOMAIN without checking if it's still true. You can find the TTL for negative caching in the SOA record of the apex domain. In your case: dig company.com.

Another, unlikely, cause could be that not all the authoritative DNS servers are in sync yet. Since they operate independently, it can take some time before all authoritative DNS servers have the same records. This is called zone transfer, and happens through the AXFR and IXFR pseudo record types.

To debug this issue, visit a DNS lookup tool, and check the following:

• Do the authoritative servers reply with the correct records?
• What is the negative cache TTL in the SOA record?

As for why some recursive DNS servers immediately reply with the correct response, they might have made different trade-offs in how aggressively they cache records. TTLs are not always followed by DNS resolvers. Or the caches of some resolvers might happen not to have this record yet, causing them to ask the authoritative DNS server immediately.