> From: sth...@nethelp.no > I have several gigabytes of pcap from *my* DNS clients indicating that > for the majority of clients this is *not* the case. Source port is > generally >= 1024 and seems pretty randomized (without having done any > deeper analysis of this). A small minority of clients are sending DNS > queries with a source port of 53.
(quoted without comment for emphasis) > What *could* make sense for my clients would be blocking inbound UDP > port 53 traffic to the clients caught doing ANY queries for ripe.net > or isc.org (blocking inbound UDP port 53 to the CPE WAN side that is), > and at the same time running a portal where those clients who needed it > could easily remove such a block. And then remove the limitations when DNSSEC becomes too common to list all of the sources of DNS jumbograms? (DNSSEC for .com gives respectable amplification now.) That end result would be a standard block-with-exceptions-for-some-users. I think one implementation of that is a complete block on UDP 53 from the Internet to CPE and an intercepting DNS proxy (ordinary DNS resolver with easy modification to forge source addresses) for CPE to Internet and with the portal for needful clients informing an RPZ zone for the proxy. Blocking inbound UDP port 53 *to* the CPE WAN side answers the big problem with port 53 blocks that no one mentioned. It protects an ISP from outside attackers without the ISP paying the costs of dealing with attacks on the outside from within the ISP. ISPs in general have always refused to do anything about abuse unless the abuse costs them. They worried about incoming spam because it angers users, but generally didn't care about outgoing abuse. That's why they can't be bothered to deploy BCP 38, they couldn't find their own spamers without Spamhaus' occassionally blocking their corporate mail systems, and modern content provider "feedback loops" are ignored unless enforced with wholesale blocking. I keep asking about current port 25 blocking because I don't know. I do know that many ISPs effectively blocked port 25 by requiring the targets of their spam to do almost all of the work by using Spamhaus' PBL. ... } From: Edward Lewis <ed.le...@neustar.biz> } 1 - DNS providers are paid to answer questions, not drop traffic. Many of the expected users of the BIND rate limiting patch are not paid to answer questions by the questioners. Besides, rate limiting identical answers for a single question from a single questioner is a standard part of good protocol design. It's why many UDP based protocols include transaction IDs or XIDs. Sometimes XIDs are necessary because requests are not idempotent, but it's always wise to include defenses against stuck clients in your protocol. } The suggestion to limit EDNS0 to "a smaller size" might be the first } step to decent (but still suboptimal) improvement. Guessing that the } malicious data seeks two things - a large, valid and reputable chunk } of data to throw at a victim and an reputable and capable address } from which to throw it, perhaps at least limiting the data size in a } way that does not cause choking to legitimate uses is a good thing. That seems to be based on the notion that a DoS attack needs large chunks. 4,000 128 byte DNS/UDP packets per second would be a bigger attack than 125 4K byte DNS/UDP packets per second for bandwidth and processing reasons, although they are the same number of DNS/UDP/IP bits. Even if first stream were only 125 responses in 4,000 IP fragments it would still be the bigger attack because IP fragment (and TCP segment) reassembly is a major cost in hosts. There are additional reasons why informed people ask first about packets/sec instead of bits/second rates for both routers and hosts. } Rate limiting is one technique, not a cure-all. If it was, } we'd not be talking about it in 2012. So, use it with caution. of course } PS - One possibility, instead of simply not responding, send back } rcode=REFUSED. The BIND rate-limiting patch limits error responses because a flood of 25 byte REFUSED DNS/UDP packets per second could be a DoS attack. The default SLIP rate is not 1 because a flood of TC=1 packets could also be an attack. Vernon Schryver v...@rhyolite.com _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
