1

I'm trying to move DNS from GD to route 53 and it seems impossible to avoid downtime, even with identical zone files in both location. From my experiments, as soon as I change to 'custom' nameservers in GoDaddy they stop answering DNS requests, and route 53 doesn't answer either (are they waiting to confirm they are authoritative before answering?) I've tested w/dig and this is what I've seen. If you use the internal test tool in AWS it's all good, but if you try using dig with the @ of one of your route 53 nameservers it does not return a result.

My thought is to set a low ttl on the nameserver records, but long ttl's on everything else. Does anyone have experience if that helps with the issue?

I understand this will only have an effect if a particular resolving nameserver queried for a record somewhat recently but that actually seems better than low ttl's on everything which will cause a resolving nameserver to have a greater chance of needing the authoritative nameserver during the propagation window.

Lance Magnum
  • 11
  • 1
  • What result do you get when you query your assigned Route53 nameservers (see NS records in the created zone)? My experience is that they start responding very shortly after creating the zone (with or without any delegation in place). – Håkan Lindqvist Mar 25 '18 at 20:15
  • I get REFUSED. I'll do some more experiments, maybe try a new zone for a new test domain – Lance Magnum Mar 25 '18 at 21:48
  • Looks like the REFUSED response was a Route53 issue, I deleted and re-created the zone (giving it a few minutes to process the delete) and now dig responds properly to the non-authoritative zone. – Lance Magnum Mar 26 '18 at 00:53

2 Answers2

1

Ensure your new nameservers are serving your records before switching. It is permissable to configure DNS on servers that are not yet, authoritative. Once you are happy that they are serving the correct data, add them to the list of nameservers in the domain configuration. Then you can remove the original nameservers.

You should already have long TTLs for all hosts. This will reduce the risk if their are issues with the nameserver change. You may want to reduce the negative TTL for the domain, so that lookup failures don't get cached long term. Reducing the TTL on the NS records will make the change simpler. If the original nameservers stop serving records before the NS records pointing to them have expired, they may start serving negative responses.

From my experience with GD, you may not be able to avoid an appearent outage from their side. Having a short TTL on the NS records in the domain configuration will reduce the impact.

BillThor
  • 27,737
  • 3
  • 37
  • 69
0

I understand this will only have an effect if a particular resolving nameserver queried for a record somewhat recently but that actually seems better than low ttl's on everything which will cause a resolving nameserver to have a greater chance of needing the authoritative nameserver during the propagation window.

If a DNS resolver (whether a DNS server or a client of said DNS server) has previously looked up your DNS records then those records will be cached per the TTL in effect at that time. Increasing or decreasing the TTL's after the fact isn't going to do anything for you in that scenario. The new TTL's will be in effect for new lookups.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172