Poison in a zone

[gson@nominum.com (Andreas Gustafsson)]

D. J. Bernstein writes:
> Fact: Slaves _must_ discard records in some situations.

This claim has no basis in the standards.

> A detailed example appears in http://cr.yp.to/djbdns/axfr-notes.html#poison.

This is an interesting example and worth discussing in its own right;
I have changed the subject line in the hope that this discussion can
be kept somewhat separate from the usual flamage.  Quoting your
example:

> Suppose that an ISP is simultaneously a third-party DNS server for
> .edu and a third-party DNS server for princeton.edu.
> 
> Suppose the ISP pulls the princeton.edu zone from a Princeton AXFR
> server, and receives the data
> 
>      haven.princeton.edu NS serv1.net.yale.edu
>      serv1.net.yale.edu A 128.112.128.15
> 
> from the AXFR server. The point of the following analysis is that the
> ISP must discard the yale.edu information.
> 
> An innocent user's cache has the legitimate record
> 
>      yale.edu NS serv1.net.yale.edu
> 
> saved. The user asks for the address of www.haven.princeton.edu. The
> cache contacts the root server, learns that the ISP is a .edu server,
> contacts the ISP, and receives the same information
> 
>      haven.princeton.edu NS serv1.net.yale.edu
>      serv1.net.yale.edu A 128.112.128.15
> 
> that the ISP obtained from the Princeton server. Because the ISP is a
> .edu server, the cache trusts and saves the serv1.net.yale.edu
> information. The user now asks for the address of www.yale.edu. The
> cache knows yale.edu NS serv1.net.yale.edu and serv1.net.yale.edu A
> 128.112.128.15, so it contacts 128.112.128.15 to obtain the address of
> www.yale.edu. In short, Princeton has been given control over the Yale
> web server.

I agree that this is a real problem that ought to be solved.  However,
there are several ways of solving it, and I do not think your solution
(making slaves discard certain records in zone transfers) is the best
solution.  For one thing, it does not solve the case where the ISP is
the *master* for the domains in case.

It is an unfortunate fact that the existing DNS standards do not
adequately address the issue of cache poisoning.  They do not even
address the simpler cases that can arise even when all domains are
hosted on distinct servers, much less the more subtle case you
describe above.  They do not even recommend, much less mandate, the
simple but effective resolver-side anti-spoofing measures that BIND 8,
BIND 9, and dnscache all currently employ and that you are taking for
granted in your example above when you say "because the ISP is a .edu
server, the cache trusts and saves the serv1.net.yale.edu information.

My own preference would be for solving this problem on the resolver
side, by using more discriminate anti-spoofing rules than the ones
BIND 8/9 and djbdns currently use.  Another possibility is to make the
servers refrain from giving out the glue in responses in situations
like the above even though it is stored and preserved for purposes of
outgoing zone transfers.  In any case, none of the possible solutions
are standardized at this time, and until they are, no one is required
to use any particular solution, and that includes your solution of
"discarding records".

> When I first mentioned this type of attack, the BIND 9 implementors
> claimed that it was safe for the ISP to provide the serv1.net.yale.edu
> information as glue for haven.princeton.edu.

There was a discussion where I said it was safe to provide cross-zone
glue, but in that discussion no mention was made of the server also
being authoritative for "edu", which makes a subtle but important
difference.
-- 
Andreas Gustafsson, gson@nominum.com