Feature request - disable internal recursion cache

Kevin Darcy kcd at chrysler.com
Mon Nov 2 20:57:58 UTC 2009


Barry Margolin wrote:
> In article <mailman.834.1256928257.14796.bind-users at lists.isc.org>,
>  Kevin Darcy <kcd at chrysler.com> wrote:
>
>   
>> Chris Thompson wrote:
>>     
>>> On Oct 30 2009, Michael Hare wrote:
>>>
>>>       
>>>> For those of us that are still running auth and recursive on the same 
>>>> IP, I believe the benefit would be to deploy a best practices 
>>>> recursive only nameserver on a different machine/IP address without 
>>>> getting, in my case, possibly hundreds of thousands of clients to 
>>>> change their DNS resolver IP address.
>>>>         
>>> Put the authoritative-only nameservers at the new IP addresses, keeping
>>> the recursive ones at the original IP addresses.
>>>
>>> Been there, done that!
>>>
>>>       
>> Well, except then you need to update all of your delegations. That can 
>> not only be an administrative hassle, but can also get very expensive, 
>> especially if you have hundreds of them in ccTLDs, where you have to pay 
>> your "in-country agent" a fee for every registry change. It's quite a 
>> racket.
>>     
>
> You don't have to change all the domain registrations.  You just have to 
> change the A records of the nameserver names.  Hopefully you haven't 
> done something silly like use different nameserver names for each domain.
>   
Unfortunately, the reality of the situation is that many folks have taken
http://cr.yp.to/djbdns/notes.html#gluelessness to heart, despite its 
obsolescence, and consider all delegations which *don't* point to names 
in the specific domain which is being delegated, to be "glueless" and in 
some way inferior to "in-bailiwick" delegations.

So the practice of delegating to domain-unique nameserver names, is 
rather rampant, and it means many folks would have to update a *lot* of 
records, if they changed the address(es) of their authoritative 
nameserver(s). It's not a trivial change at all.

- Kevin




More information about the bind-users mailing list