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

[LaMont Jones]

> i am surprised to hear that any version of bind4 or bind8 ever modified
> responses during forwarding.
I can't say that it ever did...

> 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.

Ouch.  Good points.

> "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.

OK.  Hard to do, and we haven't done it before, and it can be fixed
downstream, which must be done anyway.  Sounds like a good reason to not
muck with the response on its way through.

> but even if a response is received through a forwarder we should be able
> to avoid caching "same or higher up" delegations.

At a minimum, that should be done, since it would fix this case.  (Which
I think is just a really lazy admin who didn't want to create a lot of
single entry zones...)  That alone, deployed widely, fixes the problem.

lamont