CircleID

The packet log which is reported by Kosin is of the exact same type that I have been seeing since July 14, more than a week before the publication of full details of the DNS vulnerability. I have seen 227 packets of this type (denied cache queries) in the last 5 days on one DNS server and 839 in the same 5x24 hours another DNS server. I have been logging all port 53 packets with a packet sniffer (tcpdump), and these supposed attacks are never followed up by anything else, such as a suspicious barrage of spoofed DNS responses.

When you look at the IP addresses of the DNS clients for these denied cache requests, they turn out to be in the networks of some fairly respectable organizations. The majority of the packets (including those in the Kosin report) have reverse DNS translation somewhere within the control of ns1.gatech.edu. This has been so since 14 July when I first noticed these packets. Some of the reverse DNS translations are complete (down to the last nibble), like drudgeon4.cc.gt.atl.ga.us (143.215.129.25).

For example: client 143.215.129.25#10053 query (cache) 'rB6CIo_XgRk6BkFBOLqNSAAAAAAnzwUAAAAAANDECgA=.ports.dns-integrity-scan.com/A/IN' denied.

Other IP source addresses in my logs include:
149.20.54.35 dns-surveyor.measurement-factory.com
216.235.12.1 ricky.afilias-nst.info
132.239.1.115 portscan.ucsd.edu
38.229.0.10 bahamut.iad01.cymru.com

Shortly after I installed the patched BIND from source, I was getting almost identical scans from Dan's own servers every 6 hours. He confirmed to me in e-mail that he was doing this.

A large number of these denied cache requests also come from within the reverse DNS zone of stargate.com, like 208.78.169.236. Even though these come in sets of three in less than a second, once again there is no follow-up with spoofed DNS responses.

So far, I've seen nothing that looks like a barrage of spoofed responses. That would be a strong indication of a serious attack.

Now it could be that the 1000 denied recursive DNS requests I have seen in the last 5 days are programmed to only follow up with DNS responses if they don't get a denial. And they could be spoofed IP source addresses. However, they just don't look suspicious to me. They look just like researchers collecting survey data. If you use on of the various DNS resolver tests on the web, you're likely to attract these surveybots.

On the other hand, it is quite possible that some bad guys are probing all the DNS servers which allow recursion from any client IP address for future attacks. That's all that these probes discover, after all. So this would be useful to bad guys who want to launch a DNS poisoning attack where the initial DNS request comes from the wide open Internet, not from, say, some javascript code in a user's browser. But this would be picking only the very low-lying fruit. Surely no self-respecting bad guy would stoop so low!

I stated above that cache queries from the outside Internet would only be a danger for a DNS server which allows recursion from the outside Internet. In BIND configuration files, the set of subnets which are permitted to request such recursion is specified in the allow-recursion block.

In theory, if the allow-recursion block of subnets includes only hosts on the customer premises, the bad guy would need to run code (such as javascript or java or even just html) from an application (such as a browser) inside the customer premises to launch the "race" to satisfy a DNS request, thereby poisoning the cache.

However, since then it has occurred to me that if the CP's firewall/router does not prevent the arrival of UDP packets which spoof IP source addresses which are within the CP's local subnets, the DNS request "race" could be initiated from outside the customer premises, e.g. from hosts controlled by the bad guys. In this case, the bad guy could launch DNS "races" all day long, thereby very greatly increasing the chances of success. A fairly good guess for a CP's local subnet would be the /28 subnet including the IP address of the good guy's DNS server.

My observation (about the need to block spoofed UDP packets) is surely common knowledge, but if Dan Kaminsky's new cache poisoning exploit is combined with an incorrectly firewalled DNS server, whatever protection is given by DNS request UDP source packet randomization would be seriously weakened by the opportunity given to the bad guy to launch "DNS races" 24 hours a day, every day.

Conclusion:
If the IP source addresses in those "query (cache) denied" messages start to look like your local subnets, I would start to get very worried.
Solution:
Check that the firewall/router is blocking UDP packets which spoof IP source addresses in your local subnets.