Removing an NS server

[John Miller]

On Wed, Aug 8, 2018 at 9:10 AM, Bob Harold <rharolde at umich.edu> wrote:
>
> 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
>

Oh wow - I hadn't thought about that one, Bob: I was assuming that the
upstream records wouldn't be cached, but if they are, you're
absolutely right - zero fun trying to troubleshoot a problem like
that.

John