North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
Paul, > now as to who's responsible, ... I hate to say it, but "Microsoft". This is the default for w2k and the like. The interesting thing is that it's got a very short timer for retries and hence why your logs are so big. I found this... http://www.isc.org/ml-archives/bind-users/2001/02/msg01806.html http://www.domainregistry.ie/tech/dynamic-dns.html > Windows 2000 > The option can be found from: > Click Start -> Settings -> Network and Dialup > View the Properties of Local Area > Select Adapter -> Protocols -> TCP/IP -> Advanced -> DNS > The "Register this name" option box should be clear. ...the later would have to be done on millions of boxes around the world. I wanted to add a flag to bind to "silently ignore" these requests, but alas this is not a good solution for reverse-dns private space. I also thought that w2k and the like should not do a dynamic dns update if it's on private IP space, but that's not a valid test either, as the "enterprise" may well only exist in private IP space. (Yes... they should run their own zone for the reverse dns). Martin --------------- At 04:57 PM 4/18/2002 -0700, you wrote: >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.
|