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