Re: Removing an NS server

2018-08-08 Thread John Miller
On Wed, Aug 8, 2018 at 9:10 AM, Bob Harold  wrote:
>
> On Tue, Aug 7, 2018 at 5:01 PM John Miller  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) 
>> 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


Re: Removing an NS server

2018-08-08 Thread Matus UHLAR - fantomas

On 07.08.18 20:46, King, Harold Clyde (Hal) 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.


Yes, to be more precise, you must pull the name out of all domains delegated
to the server.


Then pull it from the list of NS records.


correct - in all zones that contain NS records pointing to the server.

I am not changing my SOA record. 


you must increase the serial number in SOA, so all slaves will fetch new
versions without NS for proper server.


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.


you should keep the server running at leasr for "expire" seconds in those zones.
the expire is (or should be) usually a week or two.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I drive way too fast to worry about cholesterol. 
___

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


Re: Removing an NS server

2018-08-08 Thread King, Harold Clyde (Hal)
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 
Date: Wednesday, August 8, 2018 at 09:10
To: John Miller , Hal King 
Cc: Bind Users 
Subject: Re: Removing an NS server


On Tue, Aug 7, 2018 at 5:01 PM John Miller 
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) 
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


Re: Removing an NS server

2018-08-08 Thread Bob Harold
On Tue, Aug 7, 2018 at 5:01 PM John Miller  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) 
> 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
___
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


Re: Removing an NS server

2018-08-07 Thread John Miller
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)  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
___
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