[dns-operations] CERT VU#800113 Multiple DNS implementations vulnerable to cache poisoning
vixie at isc.org
Sun Jul 27 15:39:23 UTC 2008
> From: Peter van Dijk <peter at dataloss.nl>
> Adding enough QID entropy mitigates the effects of lack of BCP38
> deployment sufficiently - and it is much simpler than deploying
> DNSSEC. It logically follows that we should put in the (smaller!)
> effort of making one of the QID extension proposals happen; as you
> said yourself, if BCP38 is implemented (or something to the same
> effect!) we don't need all the other complex stuff.
i also said "there's no way to prove that universal BCP38 deployment has
happened, and therefore there will never be any reason for confidence in
the IP source address of any packet, throughout the lifetime of the
> On Fri, Jul 11, 2008 at 05:11:14PM +0000, Paul Vixie wrote:
> > there just is no responsible way forward using extended QID.
> Then why is draft-vixie-dnsext-dns0x20 still alive? Note also that the
> fallback method in dns0x20 (doing the same query a couple of times)
> has scale issues similar to any TCP fallback scenario.
i think that's factually wrong. DNS-0x20 is not a QID extender in the
sense that -cookies- and other "add a blob via EDNS" are. EDNS has a
specific fallback strategy designed to encourage gradual universal adoption
with no flag days and which is totally subject to downgrade attacks.
DNS-0x20 has a noisy and painful fallback strategy which hurts everybody
when used but since we're starting from near-universal compatibility with
it, it's operationally practical.
(noting that dave presotto told me he has changed "l.google.com" to stop
stripping the 0x20 bits, which was the only truly scary outlier for 0x20.)
also, the scale issues in TCP fallback are completely different from those
in DNS-0x20 (which amounts to "try all the zone's nameservers at least
twice and make sure they solve your QID and UDP port puzzle each time").
foremost because many authority servers, or the load balancers in front of
those authority servers, do not implement TCP at all. they know they're
never going to send a truncated response and so they consider TCP to be
optional. second, each TCP transaction requires a protocol control block
in each side's kernel and a socket descriptor in each side's server, which
are comparitively scarce resources. the DNS-0x20 fallback is all UDP and
does not rely on any new kernel or descriptor resources.
(as you read all this, remember that i hate the cost:benefit profile of
UDP port randomization, but i'm going along with it because it works and
we had nothing else ready to roll out that would also work.)
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the dns-operations