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 - h...@utk.edu<mailto:h...@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 <rharo...@umich.edu> Date: Wednesday, August 8, 2018 at 09:10 To: John Miller <johnm...@brandeis.edu>, Hal King <h...@utk.edu> Cc: Bind Users <bind-users@lists.isc.org> Subject: Re: Removing an NS server On Tue, Aug 7, 2018 at 5:01 PM John Miller <johnm...@brandeis.edu<mailto:johnm...@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) <h...@utk.edu<mailto:h...@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 - h...@utk.edu<mailto:h...@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
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users