On Sep 10, 2008, at 9:17 PM, Ron Bonica wrote: > Folks, > > Based on the response that we have seen from the WG so far, I don't > see > any reason to amend the draft. BCP 38 is already published.
In defense of publishing draft-ietf-dnsop-reflectors-are-evil I'd like to put forward the following article that was part of a paper I co- authored in 2005. I do this to show that the publication of this draft is long overdue, and that I rather have it published sooner than later. Furthermore, to defend against abuse that includes open- resolvers I would welcome an RFC as soon as possible, to have a boilerplate that I can show folks, who unknowingly run open resolvers, but need a pointer to defend the cost of configuration change to their management. The article: About Open Relays and Open Resolvers In the early days of the Internet it was common to offer services to everyone, either intentionally or as a side effect. The rise of spam taught us that this approach was not well suited for the real world, so over time most open relays were closed. Spam did not cease but just one abuse mechanism disappeared. In the DNS there is a service similar to open relays: resolvers offering recursive service to anyone. While large ISPs or organisations need one or more recursive name servers (resolvers) to serve their own clients, there is no need to serve the world. Even worse, due to the existence of cache poisoning, this kind of munificence may expose the system to certain attacks. While this has been known for quite some time, we will show how third parties can communicate through open resolvers, using nothing else but DNS protocol conformant packets. Cache poisoning is done in several ways, each part of a different class of attacks. There is the intrusive attack, where a picaro can sit on the wire and alters host addresses in response packets, which will subsequently be cached for a certain time by a resolver. Another class is the trial and error attack, where a resolver is hosed with a bulk of identical responses, while the identifiers are different. To increase the success of such an attack, the expiry time of the current cached data for a chosen candidate can easily be measured. An open resolver will promptly respond to probes for the expiry time of the current cached data. Another type of attack is a simple Denial of Service attack against a resolver. The BIND 8 nameserver does not implement a memory-usage maximum. It is trivial to burst a set of qualified queries to a resolver, where the responses will contain records with high TTL values, in order to increase the memory footprint of a cache. Once the size will near physical limitations of some form, the server will stall or worse, stop processing queries. Using open resolvers as a DoS amplifier is another attack vector. It is trivial to send a single query to a resolver. It is trivial to send a bulk of identical queries to a bulk of open resolvers. Acquiring a set of IP addresses which host open resolvers is trivial as well. Since DNS is UDP based, a scan of a single /16 (’class B’) network takes only minutes. Using a large enough bulk of resolvers to query root or TLD servers for a single name can cause the respective domain to experience a significant performance degradation. A new set of abusiveness is currently being developed that involves using a bulk of open resolvers and their cache as a way to store and transfer data, disguised as DNS data. The data can take any form, from streaming media to bit-torrent seeds [Kami04]. Note that these open resolvers do not have to be recruited to be victimised. They are there for the taking, they simply need to be found. All this can be done within the boundaries of the DNS-protocol. The packets on the wire are solely DNS messages. [Kami04] D. Kaminsky Black Ops of DNS Toorcon 2004, http://www.doxpara.com/dns_tc/Black_Ops_DNS_TC_files/v3_document.htm 2004 Roy (paper) http://www.dfn-cert.de/veranstaltungen/workshop/vortrage-vergangener-workshops/12.-workshop-2005/dfncert-ws2005-f7paper.pdf (slides) http://www.dfn-cert.de/veranstaltungen/workshop/vortrage-vergangener-workshops/12.-workshop-2005/dfncert-ws2005-f7.pdf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
