April 2002 - Test - lists.nanog.org

Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
by Paul A Vixie 20 Apr '02

20 Apr '02

this was sent personally, but i'm answering to the list. > It might help the A Root, at least, if the SOA record listed > bogus.root-servers.net instead of A.root-servers.net, and then a record > mapped bogus.root-servers.net to 127.0.0.1. That should keep Win2K and > follow-ons from sending dynamic updates to the root zone. now that we have separate servers for the rfc1918 ptr zones, these updates are not going to the root servers and indeed cannot affect the root servers. since ddos attack backscatter shows up in these log files, it's darn useful to centralize the logging for it. any AS owner who wants to localize these updates can do so by simply anycasting the 192.175.48/24 netblock and serving dns on .1, .6, and .42.

6 6

is your host or dhcp server sending dns dynamic updates for rfc1918?
by Paul Vixie 20 Apr '02

20 Apr '02

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.

16 16

Re: is your host or dhcp server sending dns dynamic updatesfor rfc1918?
by Doug Barton 19 Apr '02

19 Apr '02

"Martin J. Levy" wrote: > 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 have a very simple patch to BIND 8.3.1 to create a category just for these requests so that they can easily be sent to the null channel. Happy to send it on if anyone is interested. Also, since I operate authoritative DNS servers for our *mumble*BIGNUM*mumble* customers, we used to get besieged by these update requests from our eager new customers who named their home (or office, whatever) computers in their shiny new domain name. At one point, the server listed in the MNAME field of the SOA got more update requests than queries! My solution for this was to change the MNAME field to no-dyn-updates.san.yahoo.com, which resolves to the loopback address. (After overcoming tremendous temptation to make it resolve to 207.46.138.20.) W2k's behavior here is truly horrible... it sends 5 requests at startup, then keeps sending requests, apparently forever, till it gets an answer it thinks it likes. Before taking this step, I tested it fairly thoroughly, and got the advice of some windows experts on whether this would break things. It's been in place for about 6 months now, and so far we haven't heard a single complaint. The only problem this ever causes is when registering domains through certain ccTLD registries that require MNAME to be one of the servers listed in the NS set. <Insert typical legal disclaimer here about if you try this, you're on your own, etc.> -- Doug Barton, Yahoo! DNS Administration and Development If you're never wrong, you're not trying hard enough. Do YOU Yahoo!?

2 1

Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
by Paul Vixie 19 Apr '02

19 Apr '02

> > 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 > > are you sure? i suspect they are windows 2000 systems behind NATs. so > the dynamic update is for the 1918 address, but the packet source address > has been natted into real space. according to our border flow stats, not all of them get nat'd on the way here.

3 2

Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
by Paul Vixie 19 Apr '02

19 Apr '02

(received privately, answering publically) > > any AS owner who wants to localize these updates can do so by simply > > anycasting the 192.175.48/24 netblock and serving dns on .1,=20 > > .6, and .42. > > Will it be a _bad_ thing if I just null-route those addresses in a > controlled/documented/restorable manner in the ASes and other sub-AS > networks that I administer? not at all. > Will it break anything valuable to you or to end-users inside those ASes? nope. > Is there is a certain reason I should run a real DNS server on 1, 6 and > 42 (besides, of course, collecting statistics and chasing ab|users) ? nope. > Is there a centralised place with information on the blackhole-X anycast > addresses and AS112 or a document with the proposal and implementation > besides www.root-servers.org ? um, nope. if you think it should say more than it does, let us know and we'll plump it up.

1 0

RE: is your host or dhcp server sending dns dynamic updates for rfc1918?
by Ukyo Kuonji 19 Apr '02

19 Apr '02

>From: Eric Germann <ekgermann(a)CCTEC.COM> > >If people set up their Win2K networks right, it wouldn't be a problem. >Simply install the MS DNS server, point their clients at that, then all the >updates go there. And if that DNS server has connectivity to the 'Net at >large, it will resolve all their other requests too by chasing the chain >from the root down. Great, just what Microsoft would like to see happen. In order to do this, EVERY DNS server that answers queries from end users (or servers) would have to be a MS DNS server. Might as well just replace the Internet with MSN, no offence to those that drive the deathstar. What I AM trying to figure out is why some win2K systems do this, and some don't. Did MS fix/break something with SP2? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

2 1

Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
by Paul Vixie 19 Apr '02

19 Apr '02

here's another one that was sent personally but that i'm answering to the list: > > i apologize for indicating that an AS owner ought to have been capturing > > DNS updates for rfc1918 PTR's, since up until we put the servers into an > > anycast block, this wasn't possible. now that it's possible, you should > > all start doing it. > > Wasn't it possible before the anycast trick was instituted as well? > The only reason I see for it not being possible is if the servers > weren't dedicated, but they needn't be on anycast addresses for that. the old server addresses were not intended by their registrants to be anycast by third parties. capturing traffic to such addresses would have been either a configuration error or electronic fraud, depending on whether the person trying to fix it was a sysadmin, or a lawyer. > Maybe I'm misreading your wording, but it seems to me that in order to > capture traffic one doesn't need anycast addressing for the target, the > servers just need to not have any other purpose besides DNS for RFC1918 > space... that's an alternative, sure. but anycast isn't just a global routing activity. any AS owner could advertise this /24 within their own border and collect all this "spurious" traffic from their own downstreams without also collecting it from anybody else's downstreams. that seems easier than installing null routes on every host in your AS. > I've added the following to /etc/rc.conf on the FreeBSD machine acting > as router at the office: > > --- > # Blackholed servers - these are configured here to capture RFC1918 > # dynamic DNS update requests instead of burdening IANA with them. > ifconfig_fxp0_alias3="192.175.48.6 netmask 255.255.255.255" > ifconfig_fxp0_alias4="192.175.48.42 netmask 255.255.255.255" > --- you really want .1, since that's where microsoft's products send the updates. and by the way, it's not exactly a burden, from IANA's point of view, but it is indeed traffic that's kind of silly, from my own point of view.

1 0

Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
by Paul Vixie 19 Apr '02

19 Apr '02

> > according to http://root-servers.org/, dns transactions concerning rfc1918 > > address space are now being served by an anycast device near you ... > > And right you are. However, pray tell, why doesn't bind feature a simple way > to not log these spurious updates? As far as I can tell lots of people want > to just ignore these messages but can only do so by turning off all security > logging. that question belongs on bind-users(a)isc.org, i suspect. but i'll answer: if you redirect the "update" and "security" categories to channel "null" then it works like you want. if there was demand, ISC would make a specific category called "failed-updates" so that other security related events wouldn't have to be nulled at the same time. > Please note that PowerDNS is just as silly in this respect up to 1.99.9. The > next version features --log-failed-updates which defaults to off. not all failed updates are spurious. i recommend against this as a default.

1 0

Re: is your host or dhcp server sending dns dynamic updates for rfc1918?
by Paul A Vixie 19 Apr '02

19 Apr '02

this was sent personally, but i'm responding to the list: > I noticed ~550 addresses from several /16's the I manage on the list. The > majority of the addresses were commercial broadband customers that have > static IP address assignments and appear to be running linksys/netgear/smc > broadband routers doing NAT (likely running internal DHCP servers). a common enough configuration. > I believe I understand what's happening, but how can I go about fixing > this? Is this Win2k/XP's fault, Linksys' fault, my fault....? Real > question: How do I go about preventing customer Windows machines behind > customer nat boxes from DDoSing root servers with Windoze "Dynamic Updates"? > You mentioned capturing this request, but I'm (perhaps blindly) missing the > "how" part of that concept. if rfc1918 addressing is in use inside your AS (a foregone conclusion), then it's your responsibility to install "covering routes" at the IP layer so that any traffic with that destination will die at your border. if you can also run URPF on your border routers so that packets with that _source_ will die at your border, so much the better. (i mention this not because it answers your question but because our flow stats here tell me that most other AS's don't handle their own rfc1918 traffic at their own border.) since rfc1918 addressing is in use inside your AS, i recommend that you install a route for 192.175.48.0/24, put some kind of dns servers on the .1, .6, and .42 addresses in that block, and watch the syslog file, and have your customer service (or abuse desk) folks work on educating your customers. i apologize for indicating that an AS owner ought to have been capturing DNS updates for rfc1918 PTR's, since up until we put the servers into an anycast block, this wasn't possible. now that it's possible, you should all start doing it. > BTW, what was the time frame on that list? Hours, days, weeks? four hours.

1 0

anyone using teleglobe?
by matthew zeier 19 Apr '02

19 Apr '02

I have a gigE from teleglobe due in any day. Is anyone using them for connectivity? Any comments? What's their routing look like? What should I expect if I'm dumping ~300Mbps at them? I'm trying to pre-determine if I'll run into any problems from my more "sensitive" customers. Thanks. -- matthew zeier - "In mathematics you don't understand things. You just get used to them." - John von Newmann

4 3