[ http://lwn.net/Articles/395934/ ]
[
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_13-1/131_dnssec.html
]
Something to look out for when you roll-out DNSSEC. Watch out when
you update the crypto keys.
=====
An interesting DNSSEC amplification
By Jake Edge
July 14, 2010
A recent report clearly demonstrates that computer security is not
exempt from the "law of unintended consequences". As DNSSEC (Domain
Name System Security Extensions) is rolled out, we will likely see
various kinds of unanticipated problems in that system which is meant
to secure the internet name resolution process. One of the concerns
about DNSSEC has always been the amount of additional traffic it would
generate, as well as the processing burden on DNS servers—both of
those came into play here.
The report from Cisco reads a bit like a detective story. A particular
DNS server saw a sudden 2-3x increase in its traffic, which at first
glance appeared to be some kind of denial of service (DoS) attack.
Further investigation showed that the query rate jumped from tens of
queries per second (qps) to around 3000 qps. Because it was a DNSSEC
signed zone, each query required two responses—a key resource record
(DNSKEY RR) and a signature RR (RRSIG RR)—totaling more than 1K in
size. That led to response traffic of 35 megabits per second (3000+
queries x 1K+ bytes).
[...]
It is interesting that perfectly reasonable behavior by clients who
have ended up with outdated information can lead to such a huge
increase in the traffic that DNS servers, especially the root servers,
may have to handle. The conclusion from the Cisco report is certainly
eye-opening:
It is an inherent quality of the DNSSEC deployment that in
seeking to prevent lies, an aspect of the stability of the DNS has
been weakened. When a client falls out of synchronization with the
current key state of DNSSEC, it will mistake the current truth for an
attempt to insert a lie. The subsequent efforts of the client to
perform a rapid search for what it believes to be a truthful response
could reasonably be construed as a legitimate response, if indeed this
instance was an attack on that particular client. Indeed, to do
otherwise would be to permit the DNS to remain an untrustable source
of information. However, in this situation of slippage of synchronized
key state between client and server, the effect is both local failure
and the generation of excess load on external servers-and if this
situation is allowed to become a common state, it has the potential to
broaden the failure state to a more general DNS service failure
through load saturation of critical DNS servers.
This aspect of a qualitative change of the DNS is unavoidable,
and it places a strong imperative on DNS operations and the community
of the 5 million current and uncountable future DNS resolvers to
understand that "set and forget" is not the intended mode of operation
of DNSSEC-equipped clients.
[...]
=====
--
Soh Kam Yung
my Google Reader Shared links:
(http://www.google.com/reader/shared/16851815156817689753)
my Google Reader Shared SFAS links:
(http://www.google.com/reader/shared/user/16851815156817689753/label/sfas)
_______________________________________________
LUGS Mailing list - [email protected]
List FAQ: http://wiki.lugs.org.sg/LugsMailingListFaq
Info page: http://www.lugs.org.sg/mailman/listinfo/slugnet
To unsubscribe send an empty email to: [email protected]
