odd behavior in bind-8.2.2_P3 (fwd) - "illegitimate COM server" - more

[Paul A Vixie]

> > 8.2.2-P5 caches the response, overwriting the cached servers already
> > there.  Interestingly, 8.2.2-P3 logs the following:
> >     Sep  6 08:02:20 zz named[5365]: bad referral (com !< EROSROUGE.com)
> > So this would seem to have become broken between 8.2.2-P3 and 8.2.2-P5.
> 
> Boy is my face red.  In all of my test cases, the "broken" nameserver
> was configured to forward-first...
> 
> The forwarder logs the bad referral, and passes the answer back with
> the bad authority section in tact.  The requestor then updates the
> cache, trashing his understanding of com.'s nameservers.  The good
> news for my configs is that since I'm forward first, I never query
> the .com servers directly, but only through the forwarder, so
> everything works _except_ for ns queries against com.
> 
> Which really just changes the defect to be that when sending a received
> reply to a query, it should be after we prune the crap from it, and
> when receiving a reply from a forwarder, we should still prune crap
> from it.

i am surprised to hear that any version of bind4 or bind8 ever modified
responses during forwarding.  we can't really modify a response in transit,
but we could regenerate it from the cache.  the problem is, if it's a 0-ttl
rr then it won't really go into the cache and so won't be visible during
regeneration.  "query restart" is what we do when we encounter a dangling
cname, and there's an argument to be made for doing it when we receive a
nonsensical delegation or missing NS glue.  but we don't do it now, and i
don't think we ever did it.  responses learned through a forwarder have
always been harder to verify - see below for an example.  and responses
which are being forwarded have always been forwarded without modification.
but even if a response is received through a forwarder we should be able
to avoid caching "same or higher up" delegations.