On May 25, 2009, at 8:59 AM, der Mouse wrote:
Suggesting the use of DNSSEC is not reasonable justification for
ignoring this problem.
Why not?
I see nothing wrong with the stance of "if you stubbornly refuse to
deploy known solutions to the problem, you will have to live with
continued exposure to the problem". For example, nobody sheds a
tear over the insecurities in rsh, because we have ssh; why do you
feel the analogy to unsecured DNS and DNSSEC is invalid?
Selecting which shell access method to use does not depend upon prior
adoption by the rest of the Internet. A requisite massive adoption of
DNSSEC before a reasonable level of protection is obtained is where
this analogy fails.
The major proponent of Sender-ID still does not offer DNSSEC, and has
only recently announced DNSSEC in their future OS versions. Even when
DNSSEC becomes available, validating resolvers will need to be
configured with “trust anchors” for zones where validation is
possible. DNSSEC had expected resolvers would be configured with a
trust anchor at the root zone, however, the root zone is not signed at
this time, nor are most of the TLDs.
Until that time, multiple trust anchors are required for DNSSEC, where
servers will need to be configured to accept some unsigned
information. Secondly, use of DNSSEC also requires EDNS0, which
actually makes the SPF macro feature, in conjunction with with the
inordinate number of transactions created by recipients processing
SPF, even more dangerous from an DDoS perspective.
The safest method for deploying DNSSEC could be by using SCTP as a
preferred transport for DNS. Even this type of conclusion is likely
another decade away. Until then, not being abusive and remaining
cautious about DNS use remains the best current advice.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg