is your host or dhcp server sending dns dynamic updates for rfc1918?
Martin J. Levy
mahtin at mahtin.com
Fri Apr 19 01:09:06 UTC 2002
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.
More information about the NANOG
mailing list