Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] free SSL certs from the EFF



Richard,

Richard Pieri <richard.pieri at gmail.com> writes:

> Derek,
>
> According to the DNSSEC specs, if there is no RRSIG record in the
> lookup answer then a properly behaved resolver will treat it as
> unsigned. Backwards compatibility with so-called insecure DNS is an
> explicit requirement of DNSSEC. So, what happens when a malicious
> actor inserts filters at an intermediary resolver or router that strip
> RRSIG records from DNS answers?

Which RFC states this?  I'm quite familiar with 4033 et al, (and even
moreso with their predecessors, 2535 et al).  Granted, I did stop
following the specs somewhere around the NSEC3 discussions, but it was
certainly the case that a DNSSEC-aware resolver would always know
whether to expect signed data.  I.e., if there is no DS record for the
zone then a DNSSEC-aware resolver knows it's not a signed zone.  If
there IS a DS record for the zone and then a query does not return an
RRSIG or NSEC then there's a problem (verification failure).

Obviously a non-DNSSEC-aware resolver doesn't care.

> DNSSEC was never intended to protect you against that. It was designed
> to protect high-level caches -- root zones, ISP's, big data players,
> private networks, and the like -- from cache poisoning. That's it. Any
> benefits that might trickle down to you are incidental.

Actually, it was designed to protect against that.  I sat in the
IETF meetings where that was explicitly discussed.  If an intermediary
strips the DNSSEC records out then a resolver expecting DNSSEC will
force a validation error.

> Never mind that DNSSEC has no means of rolling over the root KSKs. If
> a root is compromised then the whole domain hierarchy is compromised
> and there currently is no way to fix that other than disabling DNSSEC
> for the hierarchy or accepting loss of service for everything under
> that root.

Well, it sort of does, but it's not easy.  But this is why they use
ZSKs.  The Root Zone KSK is mightily protected.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org