forwarding to a child zone is different!!

[Kevin Darcy]

Kevin Darcy wrote:

> Brad Knowles wrote:
>
> > At 5:41 PM -0400 4/25/01, Kevin Darcy wrote:
> >
> > >  Huh? I don't follow. You seem to be implying that being
> > >authoritative makes cache
> > >  pollution more likely. Seems like it should be the other way
> > >around, i.e. if you're
> > >  authoritative for a zone, then all of that data is of high
> > >"credibility" and thus
> > >  less subject to poisoning.
> >
> >         Unfortunately, that's not the way it works.  The reality is that
> > it is possible to successfully lie to any caching nameserver, and get
> > it to believe that the answer is correct.
> >
> >         If the server in question is caching-only (i.e., not
> > authoritative for any zones), while this "lie" may be propagated to
> > other servers, at the very least it shouldn't be handed out as an
> > authoritative answer, so they can choose to believe it or not.  The
> > cache may be polluted, but it doesn't get propagated.
> >
> >         If the server in question is authoritative, and the successful
> > lie is for an answer within the authoritative zone (yes, it will be
> > cached), then when this answer is handed out to other servers, it
> > will be handed out and marked as authoritative, and other servers are
> > largely forced to actually believe it.    The cache is now polluted,
> > and because the server is authoritative for the zone in question, it
> > is also getting propagated.
>
> Any server which overlays authoritative data, i.e. data it loaded from a zone
> file (other than glue), with data learned from a response is in blatant
> violation of RFC 2181, Section 5.4.1. BIND 8 has not had this problem for a
> number of years, and I'm sure BIND 9 does not have it either. Cache
> pollution, as the name suggests, results from bad *cache* data, not from
> authoritative data.
>
> Moreover, even if a modern nameserver could be tricked into responding
> authoritatively with spoofed data, the AA bit should not be used by clients
> for *authenticating* DNS responses. Its purpose is primarily to provide
> lame-server detection, not security. Any software that trusts authoritative
> responses more than non-authoritative ones has a flawed security architecture
> anyway. The lack of a decent way to authenticate DNS transactions was, after
> all, one of the major driving forces for TSIG and DNSSEC; the AA bit is in no
> way a substitute for such methodologies. I've recently fought out this point
> with a major security-software vendor (their mail gateway product was only
> accepting authoritative DNS responses, for "security reasons") and they
> ultimately agreed with me that that made zero sense and changed the behavior
> of their product. Can you cite any software that actually cares about the
> AA bit from a security standpoint?

By way of a partial retraction, I'll answer my own question here. Since RFC 2181
ranks data from authoritative responses higher than data from non-authoritative
responses, any RFC-conforming DNS implementation arguably treats that data as
"more secure". But as I pointed out, any DNS implementation which conforms to
these ranking rules isn't subject to the kind of cache poisoning you described
in the first place, so it's a moot point...


- Kevin