Hi I'm forwarding this from the (DJB-) DNS mailing list, since one of the more knowledgeable guys there disagrees with CERT, saying that the problem doesn't lie in the DNS packets, but in the resolver library alone and that inserting a DNS cache won't necessarily help. But read itfor yourself (and sorry about Lookout's crappy quoting):

-----Original Message----- From: Jonathan de Boyne Pollard [mailto:J.deBoynePollard@tesco.net] Sent: Thursday, June 27, 2002 23:39 To: DJBDNS Mailing List Subject: Re: Packet reconstructioni

DP> The point is, of course, that if the packet is reconstructed DP> the padding bytes will be different from the original reply, DP> and this may help to spoil attacks; [...]

DNS datagrams do not contain "padding bytes", nor do they have alignment requirements. The only padding and alignment that is involved here is that in the in-memory data structures passed between the BIND DNS Client library, that is shipped with the C library, and applications.

The idea of interposition of a proxy DNS server as a local fix is, if my understanding of the problem is correct, somewhat a red herring, by the way. From what scant detail is available, the problem _appears_ to be an error in how the BIND DNS Client library uncompresses into in-memory data structures the compressed DNS datagrams that it has received. Assuming this to be the case:

Even if the proxy DNS server has constructed the DNS datagram that it sends to the DNS client from scratch, as long as that datagram contains the same sequence of resource record sets in the same order as the original "malicious" DNS datagram received from the "attacking" content DNS server did, the uncompression bug in the BIND DNS Client library will be triggered. The notion of "reconstructed datagrams" somehow saving the day is therefore an entirely misleading one. One can reconstruct the datagrams as much as one likes. As long as the reconstructed datagrams still contain the exact same data, they will be exactly the same, and they will still trigger the BIND uncompression bug in the same way. The thing that _actually_ saves the day (inasmuch as it does at all) in practical terms is that "dnscache" does _not_ send the same sequence of resource record sets in the same order to DNS clients as it received from content DNS servers in answers to its back end queries. "dnscache" does not send along "NS" records in the "authority" section and "A" records in the "additional" section (because as far as DNS clients are concerned, they are so much extraneous chaff). "dnscache" sends just the resource record sets that answer the question that was asked by the client. This saves the day to the extent that the DNS data produced by an "attacking" content DNS server, in order to exploit the BIND DNS Client library uncompression bug, must contain the exploit trigger entirely within the resource records that form the actual answer to a query, which might turn out to be quite difficult for an attacker to achieve.

Cheers Tobias