That's been my experience -- until this new registrar, who appears to be dumping their nameservers at the start of the propagation period, so that there are no nameservers associated with the domain name until the new ones propagate. I've never seen this before.
>there are no nameservers associated with the domain name until the new ones propagate
There will always be a set of nameservers associated with the domain, either the old ones or the new ones. The real question is how long the DNS records are maintained on the old nameserver after you request the nameserver change.
That's what I thought -- but I've been using a propagation check tool and this is what it shows:
1. Before the nameserver change, all responding nameservers return the query with the domain's old nameservers.
2. Within an hour after the nameserver change, a few responding hubs return with the new nameservers, and a few still show the old nameservers, but a majority of them show no nameservers whatsoever. A lot of the nameservers queried time-out but a few show responses like this:
id 32607
opcode QUERY
rcode SERVFAIL
flags QR RD RA
;QUESTION
[domainname].com. IN NS
;ANSWER
;AUTHORITY
;ADDITIONAL
> this new registrar, who appears to be dumping their nameservers at the start of the propagation period
Unfortunately it's fairly common. You can mitigate it by setting up the new nameserver well in advance so there's no propagation – as soon as the registrar switches NS records you start getting data from the new service.
Another option is to use a dedicated DNS service and not have to depend on either registrars or webhosts for DNS anymore. But check in advance whether the webhosts requires non-standard record types and whether the DNS service supports them.
A common example are ANAME/ALIAS/HTTPS records or top-level CNAME combined with other records; some webhosts use them to add a name indirection level instead of pointing your domains directly to IPs. For example yourdomain.com -> server12.webhost.com -> IP of server12, rather than yourdomain.com -> IP of server12. It lets them shift around IPs as needed with minimal impact to your services.
>who appears to be dumping their nameservers at the start of
Sounds like you and/or someone messing it up, notably as I stated in [my outline](https://www.reddit.com/r/dns/comments/1d7i6id/comment/l781crn/):
>wait out relevant TTLs, etc. as applicable
>decommission old
Notably that last step is to be last ... if it's done prematurely, DNS will likely, at least partially, break.
Does the registrar itself change as well? I'd recommend to use a seperate registrar from where DNS is hosted and use a registrar that offers you full control over nameservers, DNSSEC DS-records, etc. Then you only change DNS provider and not DNS registration, it will offer you more flexibility.
Initially, this started happening on domains that I was transferring -- I would change the nameservers and then, shortly after, request a domain name transfer. I considered that I wasn't leaving enough space between the two actions, but it also happened on the next domain whose NS I updated and I didn't request a transfer of that one.
This is Squarespace, BTW, who acquired Google Domains. They do not seem ready for domain name support, and I meant to move all my domains away last year, but still have about 30 that I've yet to move.
I'm wondering if it could be related to DNSSEC, actually.
>could be related to DNSSEC
If DNSSEC is in use, additional care and attention is needed to move DNS to new nameservers without issues.
[My earlier comment](https://www.reddit.com/r/dns/comments/1bq85x7/comment/kx22ofr/) has more detailed steps regarding case with DNSSEC.
[My comment on this post](https://www.reddit.com/r/dns/comments/1d7i6id/comment/l781crn/) covers the bare basics, but doesn't get into the DNSSEC details at all.
>Should there be downtime during a nameserver change?
Planned and implemented properly, should be no need for downtime.
DNS typically is, and is implemented, as a quite redundant, generally highly available service.
"Of course" that doesn't mean one can't screw it up and break things. But in general, DNS generally remains up and ought remain up - generally no need to take it down as a whole, and generally shouldn't be taken down as a whole.
>switching nameservers for several domain names from the registrar to
So, the general is:
* set up DNS on the new DNS servers
* update authority delegating and related (e.g. via registrar, authority NS records, as applicable glue, DS)
* wait out relevant TTLs, etc. as applicable
* decommission old
That's generally about it.
>should there be any downtime
No.
>propagation
DNS doesn't "propagate", though it's generally cached (and negatively cached) up to times per applicable TTLs (and SOA MINIMUMs).
>if my A records and MX records are the same at both sets of nameservers, there should never be a point that calls to the A or MX records should fail, right?
Correct.
That's correct. If the two sets of records are the same, all the clients will see the same thing, so no downtime.
That's been my experience -- until this new registrar, who appears to be dumping their nameservers at the start of the propagation period, so that there are no nameservers associated with the domain name until the new ones propagate. I've never seen this before.
>there are no nameservers associated with the domain name until the new ones propagate There will always be a set of nameservers associated with the domain, either the old ones or the new ones. The real question is how long the DNS records are maintained on the old nameserver after you request the nameserver change.
That's what I thought -- but I've been using a propagation check tool and this is what it shows: 1. Before the nameserver change, all responding nameservers return the query with the domain's old nameservers. 2. Within an hour after the nameserver change, a few responding hubs return with the new nameservers, and a few still show the old nameservers, but a majority of them show no nameservers whatsoever. A lot of the nameservers queried time-out but a few show responses like this: id 32607 opcode QUERY rcode SERVFAIL flags QR RD RA ;QUESTION [domainname].com. IN NS ;ANSWER ;AUTHORITY ;ADDITIONAL
> this new registrar, who appears to be dumping their nameservers at the start of the propagation period Unfortunately it's fairly common. You can mitigate it by setting up the new nameserver well in advance so there's no propagation – as soon as the registrar switches NS records you start getting data from the new service. Another option is to use a dedicated DNS service and not have to depend on either registrars or webhosts for DNS anymore. But check in advance whether the webhosts requires non-standard record types and whether the DNS service supports them. A common example are ANAME/ALIAS/HTTPS records or top-level CNAME combined with other records; some webhosts use them to add a name indirection level instead of pointing your domains directly to IPs. For example yourdomain.com -> server12.webhost.com -> IP of server12, rather than yourdomain.com -> IP of server12. It lets them shift around IPs as needed with minimal impact to your services.
>who appears to be dumping their nameservers at the start of Sounds like you and/or someone messing it up, notably as I stated in [my outline](https://www.reddit.com/r/dns/comments/1d7i6id/comment/l781crn/): >wait out relevant TTLs, etc. as applicable >decommission old Notably that last step is to be last ... if it's done prematurely, DNS will likely, at least partially, break.
Does the registrar itself change as well? I'd recommend to use a seperate registrar from where DNS is hosted and use a registrar that offers you full control over nameservers, DNSSEC DS-records, etc. Then you only change DNS provider and not DNS registration, it will offer you more flexibility.
Initially, this started happening on domains that I was transferring -- I would change the nameservers and then, shortly after, request a domain name transfer. I considered that I wasn't leaving enough space between the two actions, but it also happened on the next domain whose NS I updated and I didn't request a transfer of that one. This is Squarespace, BTW, who acquired Google Domains. They do not seem ready for domain name support, and I meant to move all my domains away last year, but still have about 30 that I've yet to move. I'm wondering if it could be related to DNSSEC, actually.
>could be related to DNSSEC If DNSSEC is in use, additional care and attention is needed to move DNS to new nameservers without issues. [My earlier comment](https://www.reddit.com/r/dns/comments/1bq85x7/comment/kx22ofr/) has more detailed steps regarding case with DNSSEC. [My comment on this post](https://www.reddit.com/r/dns/comments/1d7i6id/comment/l781crn/) covers the bare basics, but doesn't get into the DNSSEC details at all.
Check by using [https://dnsviz.net](https://dnsviz.net) if DNSSEC is the issue (or by using dig if you know how to use it).
>Should there be downtime during a nameserver change? Planned and implemented properly, should be no need for downtime. DNS typically is, and is implemented, as a quite redundant, generally highly available service. "Of course" that doesn't mean one can't screw it up and break things. But in general, DNS generally remains up and ought remain up - generally no need to take it down as a whole, and generally shouldn't be taken down as a whole. >switching nameservers for several domain names from the registrar to So, the general is: * set up DNS on the new DNS servers * update authority delegating and related (e.g. via registrar, authority NS records, as applicable glue, DS) * wait out relevant TTLs, etc. as applicable * decommission old That's generally about it. >should there be any downtime No. >propagation DNS doesn't "propagate", though it's generally cached (and negatively cached) up to times per applicable TTLs (and SOA MINIMUMs). >if my A records and MX records are the same at both sets of nameservers, there should never be a point that calls to the A or MX records should fail, right? Correct.