Removing an NS server

Bob Harold rharolde at umich.edu
Wed Aug 8 13:10:27 UTC 2018


On Tue, Aug 7, 2018 at 5:01 PM John Miller <johnmill at brandeis.edu> wrote:

> Hal, we've done this before - it's not particularly hard, just takes a
> bit for everyone to pick up the new set of NS records.  You just make
> the change upstream and also remove the NS records that reference the
> system.  It's kind of weird: during the interim, you'll have a running
> nameserver that doesn't return itself in its NS records.  If the same
> set of servers also serves your reverse zones, don't forget to update
> ARIN as well as Educause.
>
> Educause sets their upstream TTLs to two days (ARIN's 1 day), but
> people shouldn't be caching the referral, only your actual NS records.
> If you're at all concerned, you can always set a low TTL ahead of time
> on your NS records, so everyone will pull the updated records
> relatively quickly once you make your changes.
>
> John
>
> On Tue, Aug 7, 2018 at 4:46 PM, King, Harold Clyde (Hal) <hck at utk.edu>
> wrote:
> > I don't think I made my point. I need to pull/remove a DNS nameserver
> from my set of nameservers.
> > My plan was to put the reference to it from our domain name provider.
> Then pull it from the list of NS records. I am not changing my SOA record.
> Just the nameserver. Did I make a mistake? Did you mean pull the NS reord
> for that server, then pull it from the name provider. I'll still have 4
> servers running the SOA, and I don't plan to stop the old nameserver until
> well after a week of running.
> >
> >
> > --
> > Hal King  - hck at utk.edu
> > Systems Administrator
> > Office of Information Technology
> > Shared Systems Services
>

If I remember correctly, setting my NS ttl lower than my parent caused a
problem when one of my servers failed and I took it out of the NS record
set.  I think it went something like this:

resolver asks tld (before the change) and gets:
example.com 2d NS dns1.example.com
example.com 2d NS dns2.example.com
example.com 2d NS dns3.example.com

dns3 fails and I remove it from the NS records, both locally and at the
parent TLD.

Resolver talks to my servers (a few hours later, after the change) and gets:
example.com 1h NS dns1.example.com
example.com 1h NS dns2.example.com

Resolver cache now has:
example.com 1h NS dns1.example.com
example.com 1h NS dns2.example.com
example.com 2d NS dns3.example.com

An hour later the two shorter NS records expire and the resolver is left
with:
example.com 2d NS dns3.example.com

If dns3.example.com is down, the resolver will fail to reach my zone, and
will not ask the TLD until that record expires.

So I think the TTL on NS records needs to match the parent zone, whether I
like that ttl or not.

In your case, removing the NS records from both your zone and the parent
zone, two days (or whatever the ttl) before you turn off the server, should
be fine.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180808/1d8153fb/attachment.html>


More information about the bind-users mailing list