Removing an NS server

King, Harold Clyde (Hal) hck at utk.edu
Wed Aug 8 13:37:59 UTC 2018


I want to thank you all for the recommendations. I’m having a bit of mail list troubles so I don’t know Alberto’s email but thanks to you all!


--
Hal King  - hck at utk.edu<mailto:hck at utk.edu>
Systems Administrator
Office of Information Technology
Shared Systems Services

The University of Tennessee
103C5 Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone : 974-1599
Helpdesk 24/7 : 974-9900

From: Bob Harold <rharolde at umich.edu>
Date: Wednesday, August 8, 2018 at 09:10
To: John Miller <johnmill at brandeis.edu>, Hal King <hck at utk.edu>
Cc: Bind Users <bind-users at lists.isc.org>
Subject: Re: Removing an NS server


On Tue, Aug 7, 2018 at 5:01 PM John Miller <johnmill at brandeis.edu<mailto: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<mailto: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<mailto: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<http://example.com> 2d NS dns1.example.com<http://dns1.example.com>
example.com<http://example.com> 2d NS dns2.example.com<http://dns2.example.com>
example.com<http://example.com> 2d NS dns3.example.com<http://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<http://example.com> 1h NS dns1.example.com<http://dns1.example.com>
example.com<http://example.com> 1h NS dns2.example.com<http://dns2.example.com>

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

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

If dns3.example.com<http://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/3ba0885f/attachment-0001.html>


More information about the bind-users mailing list