I’m well aware of the standard “please wait 72 hours” position when making DNS changes. However, unless I’m misinterpreting the caveat, that’s a generic timeframe for allowing changes to the authoritative server to populate the myriad caching servers on the 'net.
My problem is this:
I recently became a dreamhost customer, and when I set up my account, it asked me for one domain I was going to host with them (I’m my own registrar, so I don’t need them to do registration, nor do I need them to manage my domains for me).
So, I gave them that domain (for argument’s sake, let’s say it’s example.com).
Example.com shows up in a dig against the authoritative dreamhost servers, no problem.
So, I begin adding my other zones (say, for example, example.org) via the panel.
Thing is, whenever I dig against any of the three authoritative dreamhost nameservers, none of my other zones are appearing. I’m just seeing a SERVFAIL, indicating that the zones aren’t present on the authoritative servers.
This is NOT an issue with “you have to wait 72 hours for all the caching nameservers to get these changes”. A change to an authoritative server should be visible on the authoritative server as soon as that change is made.
So, my question is this:
When a customer edits RRsets for a zone on the authoritative servers via the panel, do those changes get committed to one or more of the authoritative servers immediately (for values of “immediately” that include the 10-15 minute delay they warn of)?
Or, are these changes either queued up for processing several hours or days later, or subject to human review prior to being committed to the auth servers?
It’s crucial that I find the answer to this, as it’s blocking my ability to move forward with my migration. I’m not worried about the entire cache-propagation issue, just the speed with which the changes I submit to the auth nameservers get committed.
[from a slightly more technical stance: If I add a new zone to dreamhost’s nameservers, “dig @ns1.dreamhost.com example.com ANY” (or MX, or A, or SOA) should return NOERROR and the default RRset dreamhost supplies for that zone. It should not be returning SERVFAIL.
And I specify ns1 there because, based on my observation of change propagation among ns[1…3], it would appear that ns1 is the master, and ns2 and ns3 are slaved to it. Changes to the domain that does show up on ns1 haven’t made it to ns2 or ns3 yet. They probably haven’t IXFR’d the changes yet.]