We need to move our Primary DNS server from legacy IP space provided by our upstreams to our ARIN Assigned IP space. I am looking for advice and any gotchas. I couldn’t find any white papers to this affect or archived articles or postings. If someone does have a resource for this or find this could be valuable, I can certainly gather all the info and document it. Most of the Registrars I have seen now use the Authoritative DNS Server Host names for the domain name registrations vs the IP Address. For most of our customers, we register and host the DNS. I have confirmed almost all the customers have either Network Solutions, Tucows, Go Daddy and Register.com.
Can I simply change the IP address of our DNS server and update the DNS Host Record with our registrar with the new IP and any A / NS records we have ? As long as other customers domains have our DNS Server FQDN as the Host, they should not need to make any changes, correct ? I would love to think its that simple, but there is always a gotcha. Does anyone know of any main registries using just the IP Address where the customer might need to go in and make those changes for each and every domain ? Any input, advice or ideas is appreciated.
I would think you would want to drop your DNS record TTLs for all
domains being moved to something very low several days before the
switch-over period.
More precisely, you want to change the TTL on the NS records, which are
in the parent zone. If you're keeping the name but changing the
address, worry about the A records, too.
You also want to check all the registries which are superordinate to zones your server is authoritative for, and check that any IP addresses stored in those registries for your nameserver are updated, otherwise you will experience either immediate or future glue madness.
A conservative approach to this kind of transition is to arrange for your nameserver (or different nameservers hosting the same data) to respond on both the old and new addresses, and to continue in that mode until you see no queries directed at the old address for some safe-seeming interval (bearing in mind TTLs and cached records, alluded to by Steven and Sam).
You also want to check all the registries which are superordinate to zones your server is authoritative for, and check that any IP addresses stored in those registries for your nameserver are updated, otherwise you will experience either immediate or future glue madness.
I thought that would be only ONE registrar, hosting the ONE zone that contains the nameserver A record.
Unless you are in the habit of having domains registered with their own nameserver glue and pointing it at the same IP address.
If you have access customers (Dial/Broadband/etc) make sure they know the IP for your DNS server is changing incase they hardcode IP of your DNS server into their PCs.
There are registries that store A records for nameservers that aren't subordinate to the zones they publish. While it'd be probably reasonable to assume that such registries wouldn't ever be able to publish glue records which would cause operational problems (since they'd be out-of-zone), in reality there's a substantial amount of hokey DNS software in use out there and you can never quite predict what will happen with absolute accuracy.
For my money, I'd err on the side of paranoia, and ensure that any registry that had the old address stored in its database got the new data, even if the old address isn't published in that registry's zone today.
You're absolutely correct, however, that in an ideal world you'd only have to worry about the registry which is superordinate to the name of the authority server in question. It's quite possible that assuming the world is ideal in this case will not cause substantial problems; however, see paranoia, above.
>>
>>I would think you would want to drop your DNS record TTLs for all
>>domains being moved to something very low several days before the
>>switch-over period.
>
>More precisely, you want to change the TTL on the NS records, which
>are
>in the parent zone. If you're keeping the name but changing the
>address, worry about the A records, too.
You also want to check all the registries which are superordinate to
zones your server is authoritative for, and check that any IP
addresses stored in those registries for your nameserver are updated,
otherwise you will experience either immediate or future glue madness.
A conservative approach to this kind of transition is to arrange for
your nameserver (or different nameservers hosting the same data) to
respond on both the old and new addresses, and to continue in that
mode until you see no queries directed at the old address for some
safe-seeming interval (bearing in mind TTLs and cached records,
alluded to by Steven and Sam).
currently in the middle of such a safe, conservative
transition leads me to believe that there will -NEVER-
be a point w/ there are no queries to the old address.
(he says, 24 months into a transition...) The right
tactic is to make the change, based on 2x the TTL of the SOA.
currently in the middle of such a safe, conservative
transition leads me to believe that there will -NEVER-
be a point w/ there are no queries to the old address.
(he says, 24 months into a transition...)
It's probably reasonable to say that there are more historical instances of B's address being hard-coded than there are for Eric's authority server, though (and I'm guessing that he also doesn't have to answer priming queries
The right
tactic is to make the change, based on 2x the TTL of the SOA.
There are registries that store A records for nameservers that aren't
subordinate to the zones they publish. While it'd be probably
And for those that don't...some administrators (your predecessor
hostmaster? the admin of zones you slave?) work around the problems
of lack of cross-zone glue by giving one nameserver's single IP address
multiple names, and therefore glue in multiple registries.
So it's still wise to look either way.
problems; however, see paranoia, above.
It's not paranoia. They really are out to get you.
assuming you've got the old box and the new one running
concurrently, you could run tcpdump on the old box with a
filter to only catch dns requests to the old ip. Let it run
for 24-48 hours and you could see who/what was still
querying the old ip.
Behalf Of Eric Kagan
Sent: Tuesday, December 13, 2005 2:45 PM
To: nanog@merit.edu
Subject: Gothcas of changing the IP Address of an
Authoritative DNS Server
We need to move our Primary DNS server from legacy IP
space
provided by our upstreams to our ARIN Assigned IP space.
I
am looking for advice and any gotchas. I couldn't find
any
white papers to this affect or archived articles or
postings.
If someone does have a resource for this or find this
could
be valuable, I can certainly gather all the info and
document
it. Most of the Registrars I have seen now use the
Authoritative DNS Server Host names for the domain name
registrations vs the IP Address. For most of our
customers,
we register and host the DNS. I have confirmed almost all
the customers have either Network Solutions, Tucows, Go
Daddy
and Register.com.
Can I simply change the IP address of our DNS server and
update the DNS Host Record with our registrar with the new
IP
and any A / NS records we have ? As long as other
customers
domains have our DNS Server FQDN as the Host, they should
not
need to make any changes, correct ? I would love to
think
its that simple, but there is always a gotcha. Does
anyone
know of any main registries using just the IP Address
where
the customer might need to go in and make those changes
for
each and every domain ? Any input, advice or ideas is
