Score:-1

Changes to do to old zone after migrating DNS provider

gd flag

We have migrated from a DNS zone provider (AWS Route 53) to another one (CloudFlare). We have changed the nameservers at our registrar (Gandi) on July the 20th 2021. We have not changed the SOA and NS records declared in the zone of our former DNS provider (AWS Route 53), deeming it not needed (and anyway not possible with some providers; but this one seems to allow this).

Today we discovered that at least one Internet service provider has DNS servers which are intermittently still resolving on our former provider, which we have not yet decommissioned. We have not found any other ISP exhibiting such a behavior.

The behavior is very strange from my viewpoint: querying one of their nameserver (not public facing, only accessible from a subscription to their service) yields sometime a response from our current provider, sometimes from the previous provider. And this switches from good to bad or conversely at random and at a fast pace, even with a shorter delay than the TTL indicated in the answer.
I have ascertained the bad answers were actually coming from our previous DNS zone provider by doing some changes there: the DNS server from that ISP has then reflected the changes when answering bad records.

Even though according to these answers 1, 2 and 3, we should not have to change anything in the records of our old DNS zone provider, is there still actually something we should change?

Or is it that this one ISP has some trouble they have to fix on their side?

You can see the domain for which I have the trouble in my current Stack Exchange profile, last line "Work at ...". The former DNS zone provider (AWS Route 53) resolves the www of the domain to a cname for an AWS CloudFront distribution that we keep enabled for now. The current DNS zone provider (CloudFlare) directly resolves it to IP addresses of its CDN edge nodes.

NS record for the zone at the current DNS zone provider, CloudFlare (with our actual domain name replaced by ourdomain):

ourdomain.com.  1   IN  NS  margaret.ns.cloudflare.com.
ourdomain.com.  1   IN  NS  bowen.ns.cloudflare.com.

NS records from the delegation (Gandi registrar):

ourdomain.com.  86400   IN  NS  bowen.ns.cloudflare.com.
ourdomain.com.  86400   IN  NS  margaret.ns.cloudflare.com.

NS records for the zone at the former DNS zone provider provider (AWS Route 53):

ourdomain.com.  172800  IN  NS  ns-1139.awsdns-14.org.
ourdomain.com.  172800  IN  NS  ns-776.awsdns-33.net.
ourdomain.com.  172800  IN  NS  ns-452.awsdns-56.com.
ourdomain.com.  172800  IN  NS  ns-1763.awsdns-28.co.uk.
cn flag
Could you, just for clarity, show the `NS` records both from the delegation and the zone itself? If these are all correct, it would have to be a problem on the side of the specific ISP.
Patrick Mevzek avatar
cn flag
If you provided real names instead of bad obfuscation you could get far better replies...
Patrick Mevzek avatar
cn flag
"We have changed the nameservers at our registrar on July the 20th 2021. We have not changed the SOA and NS record from our old provider" This makes no sense. If you change the nameservers at your registrar it means the parent will publish a new NS set, and hence the child (you) has to publish the same new NS set otherwise you are in a lame delegation case, and will get all sort of troubles. Again, with the proper names, it would be far easier to troubleshoot your problem. Your only recourse is asking our DNS providers or use online tools such as DNSViz or Zonemaster.
Patrick Mevzek avatar
cn flag
"You can see the domain for which I have the trouble in my current Stack Exchange profile, last line "Work at ...". " So why exactly not putting it here? Why putting the onus on people reading your question to go through multiple hoops just to get all data needed to even begin to understand your problem? Plus your profile can change anytime and then the question becomes impossible to understand. Please put all relevant data for your question in the question itself.
Patrick Mevzek avatar
cn flag
Your question is not clear to me (with the bottom examples kind of contradicting your first sentence) but "The behavior is very strange from my viewpoint: querying one of their nameserver (not public facing, only accessible from a subscription to their service) yields sometime a response from our current provider, sometimes from the previous provider. " sounds like you are running into the child-centric vs parent-centric issue, when data differs between both sides of the cut, and some resolvers believe the parent (Google for example) and other the child.
Frédéric avatar
gd flag
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/129175/discussion-between-frederic-and-patrick-mevzek).
Score:0
gd flag

The trouble was on that one ISP side. So, as far as I know, no, no other changes has to be done in our DNS settings.

We were able to reach them out and get their support team to look at the trouble. It took some time, but at some point they answered they have done an intervention on their DNS servers, and since then we are no more seeing the trouble.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.