On Wed, Aug 8, 2018 at 9:10 AM, Bob Harold <rharo...@umich.edu> wrote: > > On Tue, Aug 7, 2018 at 5:01 PM John Miller <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> >> 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 >> > 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 _______________________________________________ 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
