On 11/09/2014 13:38, Peter Andreev wrote: > Hello, > > We run a public resolver and a few days ago I noticed a lot of very > weird queries, like the following: > > 16:11:41.450794 IP 217.195.66.253.37426 > 62.76.76.62.53: 42580+ A? > swfjwvtkhqx.www.feile8888.com. (47) > 16:11:41.450796 IP 91.209.124.75.50584 > 62.76.76.62.53: 37269+ [1au] > A? izhsccxedub.www.feile666.com. (57) > > For the total amount of SLDs of 11, the only common in those queries > are random labels on the left side. One of those SLDs is an > online-shop, another is online-casino, so I concluded that our > resolver is being used to bombard NSes of corresponding SLDs with > queries. > I'd like to ask the respected community, how do you detect and protect > against such activity? Will RRL help me if all suspected queries come > with random qname? > > Thank you in advance. >
There's a lot of this about. We did awhile back wonder if it was botnet-related, but I've not (yet) seen any persuasive evidence that it is. Our current thinking (based on evidence from some of our customers, and also from Nominum's analysis presented at the Warsaw DNS-OARC workship earlier this year) that the majority of these recent query spates are intended as an attack on the domain (e.g. feile8888.com) or the nameserver hosting it. Once overwhelmed with query traffic, the DNS servers cease responding, or only respond sporadically. These authoritative server admins may also be deploying RRL to protect themselves too - but from your perspective, they're non-responding either way (with one exception - which is if they respond with the TC bit set to encourage a TCP-based query instead). The attackers appear to be making use of open resolvers (lists of which are readily available) presumably in order to ensure that the queries come from a whole range of clients, and possibly to provide another level of obscurity for the actual source. If you're running a public recursive server, you may be seeing the queries both directly and indirectly. The indirect queries are likely being forwarded to you by other servers or by insecure CPE devices that proxy queries to port 53 on their WAN interface by forwarding them to the ISP provider's DNS servers. There are quite a few things you can do to alleviate the problem, including limiting access to your open resolvers, identifying and blocking traffic that is coming to you via broken CPE devices, and identifying and communicating with admins of open resolvers that are forwarding to you. Other techniques include making yourself authoritative for the domains that are under attack (you can usually identify them from the traffic - some admins have scripted solutions), and/or using a DNS RPZ domain to block the queries - although you need a version of DNS RPZ that includes the qname-wait-recurse option that you'll want to set to 'yes' to make the rewriting occur prior to iteration. If you're running BIND, we're working on some new recursive rate limiting techniques that we're quite keen to get more exposure to - they involve rate-limiting queries to servers that are becoming non-responsive. I presented on the most recent evolution of those earlier this week at UKNOF29 in Belfast (they were earlier aired at IETF90 in Toronto and some useful suggestions taken on-board). https://indico.uknof.org.uk/conferenceOtherViews.py?view=standard&confId=31 See Nominum's session at 9:40 with further analysis of the traffic, and mine at 10:00 on various mitigation techniques. Hope this helps? (And also, I'm very keen to hear/see evidence of other causes and sources of this type of query traffic) Cathy _______________________________________________ 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
