I strongly oppose this draft. I've read the draft. It still asserts that __somehow__ the amplification potential of authoritative servers is greatly reduced in comparison with recursive servers. There is no rational to support this assertion and facts have been given that repudiate it. (e.g. large DNS records such as SPF, In-addr; private recursors and authoritative servers can produce the same size records and same amplification). Indeed, private recursors and authoritative servers are prefereable for DDOS attacks.
The claims that public recursive nameservers are somehow worse has been refuted: e.g. ==================== > An attack which uses EDNS0-capable public recursive nameservers has > the potential to achieve 60-to-80-fold amplification. An attack which uses EDNS0-capable private recursive nameservers also has the potential to achieve 60-to-80-fold amplification. An attack which uses EDNS0-capable authoritative nameservers also has the potential to achieve 60-to-80-fold amplification. ==================== Note that one cannot block internal private recursors, nor authoritative servers. So, if damage were the actual goal, one would not use public recursors, but the select servers that can't be blocked or mitigated. One would also sensibly select servers for which scanning in preparation of an attack would not reveal the attacker. One doesn't need an open recursor to mount the attack at all. Private recursors or authoritative are preferable, in fact, because they can't be blocked or mitigated, while in contrast, public recursors require searching/scanning or a distribution of a centralized database which reveals the perpetrator, and can be mitigated. Indeed, the issues raised in these four messages are still unresolved and unaddressed: http://darkwing.uoregon.edu/~llynch/dnsop/msg03702.html http://darkwing.uoregon.edu/~llynch/dnsop/msg03703.html http://darkwing.uoregon.edu/~llynch/dnsop/msg03707.html http://darkwing.uoregon.edu/~llynch/dnsop/msg03708.html > Since the majority of documented examples of reflection attacks (if > not all of them) do involve open recursive nameservers, I note also the comparison with open relay attacks. For almost 10 years, open relay attacks have been exclusively performed by non-commercial attackers. No genuine bulk commercial emailer ever abused an open relay of ours in almost 10 years of open relay operations. I tracked solitications of abuse of open relays back to anti-spammers (see http://www.iadl.org/cn/cn-story.html, particularly Joshua and the Cleveland Gang). I found that ORBS.ORG and Osirusoft.org were instrumental in the abuse of open relays. (see www.iadl.org) Indeed, since the closure of these sites in 2003, open relay abuse has dropped to nearly nothing. There are still occasional abuse activities but nothing substantial. In retrospect, its clear that the abusers of open relays were mis-guided anti-spammers trying to 'prove' the harms of open relays. I think that open-recursor attacks are performed by a similarly misguided group, because one can more easily find authoritative servers and private recursors to mount such an attack, and then there is no mitigation. These types of DNS servers are easier to find than open recursors, yet for some reason, the "abusers" choose open recursors. That fact suggests an agenda similar to the open relay abusers: Actual harm isn't the goal, rather attemption to prove the possibility of a specific kind of harm is the goal. This draft similarly doesn't address a real problem, but a contrived problem, for which there is no actual harm but for the actions of those trying to 'prove' the harm. Therefore, I don't think this draft should be advanced. --Dean On Tue, 19 Sep 2006 [EMAIL PROTECTED] wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations Working Group > of the IETF. > > Title : Preventing Use of Recursive Nameservers in Reflector > Attacks > Author(s) : J. Damas, F. Neves > Filename : draft-ietf-dnsop-reflectors-are-evil-02.txt > Pages : 8 > Date : 2006-9-19 > > This document describes the use of default configured recursive > nameservers as reflectors on DOS attacks. Recommended configuration > as measures to mitigate the attack are given. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are-evil-02.txt > > To remove yourself from the I-D Announcement list, send a message to > [EMAIL PROTECTED] with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-dnsop-reflectors-are-evil-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > [EMAIL PROTECTED] > In the body type: > "FILE /internet-drafts/draft-ietf-dnsop-reflectors-are-evil-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
