Problems with bind9 caching too long

[John Wobus]

I have no direct knowledge of what the RFCs imply or say outright, or 
whether BIND9 complies, but I agree with Phil that there is a need for 
the DNS to "discover" updated chains of delegation without regard to 
anything servers no longer authoritative in that chain have to say.  
There are practical situations where the owner of a domain loses their 
influence on the configuration of a nameserver previously legitimately 
serving his/her domain.  The problems may be ascribed to incompetence, 
but the incompetence is not always correctable by those suffering the 
consequences.

I think this point is vital enough that a DNS RFC should explicitly 
comment on it, whatever is considered to be or is adopted as correct.  
I am amazed the issue hasn't caused more trouble already.

Short of a clear RFC statement, it hardly seems to be BIND9's fault, 
though it would be great if BIND9 went beyond compliance to help defend 
against such situations.  But I'm not sure what form such a defense 
would take, with or without an RFC blessing.  In certain situations, a 
caching server would have to ignore its NS record, chop the domain down 
a level, and do the necessary lookups again.  Surely there is an 
interval of time that is not so small as to be burdensome yet not so 
large as to leave domain owners at someone's mercy forever.  But what 
exactly would trigger this logic, I don't know.

John Wobus

On Mar 15, 2005, at 4:01 PM, Phil Dibowitz wrote:

> On Tue, Mar 15, 2005 at 12:40:25AM -0500, Barry Margolin wrote:
>> In article <d15jf6$1ab7$1 at sf1.isc.org>,
>>  Brad Knowles <brad at stop.mail-abuse.org> wrote:
>>
>>> 	Either way, once the delegation is pointed somewhere else, it
>>> shouldn't matter what the old server operators do.
>>
>> That's what the previous poster was saying.  The problem is that this
>> doesn't always work right, because of caching.  If someone has the old
>> delegation cached, and the old server operator doesn't remove the
>> domain, it will persist as long as they keep querying the old server
>> before the TTL of the NS records run out.
> No - that's my point... the TTL of the NS records isn't being obeyed! 
> (OK,
> well with the new patch in BIND it is).
>
> Once again:
>
> parent.tld has:
>    child.parent.tld 27000 IN NS ns.child.parent.tld
>
> once BIND has seen that (BIND pre-patch), it will keep that delgation
> *indefinitely* as long as requests keep requesting information on
> child.parent.tld AND ns.child.parent.tld continues to answer for
> child.parent.tld. It won't expire that NS record from parent.tld until
> ns.child.parent.tld stops talking about child or no requests come into 
> the
> caching bind for 2 weeks.
>
> I agrue that the right thing to do (and in fact what current BIND 
> does) is go
> "oh, 27000 seconds as passed, I'll go check with the parent again" - 
> previous
> BIND did *not* do that, so there was no way to forcefully pull your
> delegation because of the cacheing of that NS being essentially 
> indefinite.
>
> But as Mark and I have stated several times since the patch is there, 
> and is
> not going anywhere, and it now acts the way I want/expect it to - the 
> value of
> the "ideal world" is simply a theoretical discussion between Mark and 
> I since
> we have slightly different views...
>
>
> -- 
> Phil Dibowitz
> Systems Architect and Administrator
> Enterprise Infrastructure / ISD / USC
> UCC 174 - 213-821-5427
>
>
> -- Attached file included as plaintext by Ecartis --
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
>
> iD8DBQFCN00O7lkZ1Iyv898RAtrhAJwMcOG6mt3cPLQseJtYWUSmQ1+/bwCeLPYB
> UcDr1Zr+5WJ9ZkVQZA7lj2M=
> =1LnG
> -----END PGP SIGNATURE-----
>
>
>