according to http://root-servers.org/, dns transactions concerning rfc1918 address space are now being served by an anycast device near you (no matter who you might be, or where.) there will eventually be official statistics, but i thought i'd give everybody a chance to clean up their houses first. on the instance ISC runs, i noticed that the log files were turning over really fast. that is to say, really, really, really fast. see below. -rw-r--r-- 1 root sys 10485795 Apr 18 12:11 update-1.log.33 -rw-r--r-- 1 root sys 10485850 Apr 18 12:19 update-1.log.32 -rw-r--r-- 1 root sys 10485794 Apr 18 12:26 update-1.log.31 -rw-r--r-- 1 root sys 10485846 Apr 18 12:33 update-1.log.30 -rw-r--r-- 1 root sys 10485787 Apr 18 12:41 update-1.log.29 -rw-r--r-- 1 root sys 10485830 Apr 18 12:48 update-1.log.28 -rw-r--r-- 1 root sys 10485776 Apr 18 12:55 update-1.log.27 -rw-r--r-- 1 root sys 10485873 Apr 18 13:02 update-1.log.26 -rw-r--r-- 1 root sys 10485847 Apr 18 13:09 update-1.log.25 -rw-r--r-- 1 root sys 10485830 Apr 18 13:17 update-1.log.24 -rw-r--r-- 1 root sys 10485783 Apr 18 13:24 update-1.log.23 -rw-r--r-- 1 root sys 10485871 Apr 18 13:31 update-1.log.22 -rw-r--r-- 1 root sys 10485794 Apr 18 13:39 update-1.log.21 -rw-r--r-- 1 root sys 10485866 Apr 18 13:46 update-1.log.20 -rw-r--r-- 1 root sys 10485821 Apr 18 13:54 update-1.log.19 -rw-r--r-- 1 root sys 10485843 Apr 18 14:01 update-1.log.18 -rw-r--r-- 1 root sys 10485831 Apr 18 14:08 update-1.log.17 -rw-r--r-- 1 root sys 10485809 Apr 18 14:16 update-1.log.16 -rw-r--r-- 1 root sys 10485765 Apr 18 14:23 update-1.log.15 -rw-r--r-- 1 root sys 10485802 Apr 18 14:31 update-1.log.14 -rw-r--r-- 1 root sys 10485853 Apr 18 14:39 update-1.log.13 -rw-r--r-- 1 root sys 10485779 Apr 18 14:46 update-1.log.12 -rw-r--r-- 1 root sys 10485822 Apr 18 14:54 update-1.log.11 -rw-r--r-- 1 root sys 10485864 Apr 18 14:59 update-1.log.10 -rw-r--r-- 1 root sys 10485770 Apr 18 15:03 update-1.log.9 -rw-r--r-- 1 root sys 10485801 Apr 18 15:07 update-1.log.8 -rw-r--r-- 1 root sys 10485795 Apr 18 15:14 update-1.log.7 -rw-r--r-- 1 root sys 10485810 Apr 18 15:22 update-1.log.6 -rw-r--r-- 1 root sys 10485762 Apr 18 15:29 update-1.log.5 -rw-r--r-- 1 root sys 10485844 Apr 18 15:37 update-1.log.4 -rw-r--r-- 1 root sys 10485813 Apr 18 15:45 update-1.log.3 -rw-r--r-- 1 root sys 10485806 Apr 18 15:53 update-1.log.2 -rw-r--r-- 1 root sys 10485769 Apr 18 16:00 update-1.log.1 -rw-r--r-- 1 root sys 10485853 Apr 18 16:07 update-1.log.0 -rw-r--r-- 1 root sys 8108342 Apr 18 16:13 update-1.log what these files are is a whole lot of lines that look like (broken by me): 18-Apr-2002 16:16:05.491 security: notice: \ denied update from [63.198.141.30].2323 for "168.192.in-addr.arpa" IN by "a whole lot" i mean we've logged 3.3M of these in the last four hours. so who are these people and why are they sending dynamic updates for rfc1918 address space PTR's? second answer first: it's probably Windows' fault. after a successful DHCP transaction, the corresponding A RR and PTR RR have to be updated. if rfc1918 is in use, dns transactions about these PTR's ought to be caught and directed toward some local server, who can do something useful with them. this local capture often does not occur, and so these dns transactions end up coming to us. now as to who's responsible, first off you have to understand that we block rfc1918-sourced packets at our AS boundary. (otherwise these numbers would be Much Higher, but tracking them back to their source is Too Hard.) the list of broken hosts (or hosts inside broken firewalls, depending on how you look at it and depending on how DHCP is configured), can be seen here. if histogrammed as /32's, the more-than-5000-times club has the following members: /32 31049 65.185.183.173 /32 21293 66.36.29.99 /32 16498 206.13.58.232 /32 11983 67.80.208.88 /32 11679 210.76.208.42 /32 11188 64.131.161.29 /32 10878 212.247.56.33 /32 10650 194.209.225.5 /32 9455 24.153.174.135 /32 8140 64.94.107.2 /32 8110 64.180.126.207 /32 7992 65.66.33.249 /32 7959 211.74.245.10 /32 7864 64.221.109.114 /32 7740 214.1.35.254 /32 6842 156.1.60.60 /32 6593 202.103.200.224 /32 6232 212.219.116.67 /32 5901 66.105.121.2 /32 5113 130.67.113.72 viewing the results through a /24 shaped lense, the winners are: /24 32180 65.185.183 /24 22018 66.36.29 /24 16986 206.13.58 /24 12361 67.80.208 /24 12065 210.76.208 /24 11641 64.131.161 /24 11319 212.247.56 /24 11057 194.209.225 /24 10056 24.153.174 /24 8661 64.180.126 /24 8365 64.94.107 /24 8262 64.221.109 /24 8254 211.74.245 /24 8124 65.66.33 /24 7975 214.1.35 /24 6957 156.1.60 /24 6657 202.103.200 /24 6473 212.219.116 /24 6107 66.105.121 /24 5850 65.69.149 /24 5595 151.196.98 /24 5299 130.67.113 /24 5101 218.5.65 /24 5034 139.130.213 these aren't cidr blocks, just a cheesy perl script. better detail will come later, when the statistics are officialized and centralized amongst the various anycasted instances of these "servers". anyone who'd like to think about ways to not appear in those later stats should check out the full list of /32's at: ftp://ftp.isc.org/isc/slash32.txt these are just the addresses who route toward ISC's servers; if your nets are "closer to" (in routing terms) VeriSign, WIDE, or Autonomica, you won't be in this list, so, your public ridicule can come later on instead of today.