[dns-operations] CERT VU#800113 Multiple DNS implementations vulnerable to cache poisoning
briand at ca.afilias.info
Thu Jul 10 17:51:26 UTC 2008
Sean Donelan wrote:
> Even assuming DNS registries have any better security for checking DNS
> changes before they sign the data (click here to e-mail the password
> you forgot, or send a request on company letterhead), and assuming DNS
> users understand/don't ignore/don't disable DNSSEC warnings (some
> people turnoff UDP checksums for better performance), and so on....
Technically, it is the registRARs, not the registrIEs, with woeful
security practices. Registrants don't deal directly with the registries.
Registries have pretty strict controls and pretty strict oversight
governing what they can and can't do.
However, the model for DNSSEC changes that somewhat. Details are a bit
hand-wavy, but in general, the registrant would send (and need to send)
updates that are signed, if they have a signed zone.
DNSSEC is opt-out. The TLDs don't require registrants to use DNSSEC.
But, those that do, get their data delivered to end-user validating
resolvers in a crypto-secured manner, preventing cache poisoning.
For those zones who opt-out, nothing changes, and no new warning
appears. Poisoning is still possible.
For those zones who deploy DNSSEC, there is no warning.
Either the zone data is securely delivered to clients (if valid
non-expired keys are in use), or NOTHING is delivered (if all keys have
That is an explicit design choice for DNSSEC. There is no ability for
the end-user to defeat the security protections provided.
(There would still be the ability for the validating resolver to deliver
unsecure, untrusted results, but that isn't something under Joe End-User
control, just Joe ISP's control - where Joe ISP has to worry about
things like $$$ liability.)
More information about the dns-operations