[dns-operations] CERT VU#800113 Multiple DNS implementations vulnerable to cache poisoning
Paul Vixie
vixie at isc.org
Fri Jul 11 17:11:14 UTC 2008
> > any form of always-use-tcp is undeployable for reasons of both scale
> > and reach. there would be too much state and through-delay in such a
> > system, and, there are too many unreachable name servers seen by
> > tcp/53.
>
> I'm not sure if this is actually true. However, I'm convinced that
> switching to TCP would require significant software changes on the
> authoritative server side. And once such changes are needed on both
> recursors and authoriative servers, a protocol change and a UDP-based
> solution is preferable (and DNSSEC is that's already out there, at least
> to some extent).
>
> IOW, I agree with your conclusion, but for different reasons.
when you say "switching to TCP would require significant software changes
on the authoritative server side" you're restating my "reasons of scale"
constraint. similarly with "a UDP-based solution is preferrable". also,
in the part of what i wrote that you didn't quote, are the words
"... Secure DNS, ... still the right solution to the general class of
problem being noted here" which is equivilent to your "DNSSEC is ...
already out there ..." statement. so, i think that we have non-differing
reasons.
but let me add that DNSSEC also protects against non-spoofing non-poisoning
attacks, including corrupted authority servers, man in the middle, ARP and
ICMP level attacks. Secure DNS is strong enough to compete against X.509
for PKI and e-commerce data exchanges, whereas "forgery resilience" is not.
so we could consider a 100% installed base overhaul to add extended QID, or
we could consider a 100% installed base overhaul to add Secure DNS. and in
the second case, nobody has to either answer every query via TCP or answer
every query twice during the long years of the complete installed base
overhaul.
there just is no responsible way forward using extended QID.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
More information about the dns-operations
mailing list