I'm checking just with a mix of tcpdump/pcap, bind logs and p0f. A bit overboard, but logging is fun. I haven't checked any dark hosts to see whether the attack repeatedly sends queries to IPs which have never given an answer or indication of any kind of life. Your monitoring will probably determine this so let us know what behavior you find. DZ -----Original Message----- From: Steve Bertrand [mailto:steve@ibctech.ca] Sent: Wednesday, 28 January 2009 2:47 PM To: David Zielezna Cc: John Martinez; nanog@nanog.org Subject: Re: Tightened DNS security question re: DNS amplification attacks. [SEC=UNCLASSIFIED] Good work! How are you checking for this by hand? Would it be safe to assume that running tcpdump on a box in the following manner on a monitor port for a sizable portion of the network be ok (as opposed to the DNS servers themselves, as I don't have control over them all)? sniffer# tcpdump -n -i em5 dst port 53 | grep "NS? . (17)" 22:38:31.150114 IP 64.57.246.146.43581 > 208.70.106.58.53: 23685+ NS? . (17) We have a mix of DNS servers, some BIND and some DJBDNS, a BIND ACL won't work here. We also have single-homed clients that run accessible DNS servers that appear to be Windows based. ACL's outside of the BIND scope would be fantastic. For now, I'm following the above list, and blocking everything ingress that is not source port 53 from the IP to my network 53. Steve If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.