- Test - lists.nanog.org

netsol whois working again
by Michael Klosterman 22 Apr '02

22 Apr '02

Thanks everyone. They must've been wokring on it over the weekend. Couldn't get to it since Sat. morning... It's back now. traceroute whois.networksolutions.com traceroute to whois.networksolutions.com (216.168.229.1), 64 hops max, 40 byte packets 1 R1-Fa-0-0-Internet (208.164.248.1) 1.300 ms 1.005 ms 1.123 ms 2 bar3-serial4-0-0-11-0.Minneapolis.cw.net (208.175.56.129) 14.517 ms bar3-serial4-0-0-10-0.Minneapolis.cw.net (208.175.56.125) 14.353 ms 9.264 ms 3 acr1.Minneapolis.cw.net (208.174.2.61) 13.029 ms 13.111 ms 13.393 ms 4 acr1-loopback.Restonrst.cw.net (206.24.178.61) 42.270 ms 44.253 ms 53.383 ms 5 bar1-loopback.Restonrst.cw.net (206.24.178.3) 40.937 ms 45.782 ms 44.232 ms 6 network-solutions-inc.Restonrst.cw.net (206.24.181.134) 46.794 ms 47.360 ms 57.257 ms 7 * whois.networksolutions.com (216.168.229.1) 47.705 ms 54.705 ms

1 0

netsol whois down
by Michael Klosterman 22 Apr '02

22 Apr '02

I missed the announcement on this. Any idea when the network solutions whois will be back up? It's been down all weekend.... bash-2.05a$ traceroute whois.networksolutions.com traceroute to whois.networksolutions.com (216.168.229.1), 64 hops max, 40 byte packets 1 R1-Fa-0-0-Internet (208.164.248.1) 1.116 ms * 1.485 ms 2 bar3-serial4-0-0-8-0.Minneapolis.cw.net (208.175.56.117) 15.070 ms bar3-serial4-0-0-7-0.Minneapolis.cw.net (208.175.56.113) 12.731 ms 10.086 ms 3 acr1.Minneapolis.cw.net (208.174.2.61) 19.769 ms 14.112 ms 19.321 ms 4 acr1-loopback.Restonrst.cw.net (206.24.178.61) 48.940 ms 43.259 ms 44.385 ms 5 bar1-loopback.Restonrst.cw.net (206.24.178.3) 41.228 ms 44.428 ms 47.349 ms 6 network-solutions-inc.Restonrst.cw.net (206.24.181.134) 217.002 ms 44.750 ms 45.792 ms 7 216.168.224.3 (216.168.224.3) 49.386 ms 47.508 ms 46.253 ms 8 216.168.224.6 (216.168.224.6) 54.537 ms 49.731 ms 51.593 ms 9 216.168.224.3 (216.168.224.3) 42.160 ms 43.621 ms 55.701 ms 10 216.168.224.6 (216.168.224.6) 51.765 ms 52.268 ms 43.768 ms etc., etc. Thank you. - michael -- Michael Klosterman Swiftel

2 1

Re: bulk email
by Steven M. Bellovin 22 Apr '02

22 Apr '02

In message <4738cuobuatfc6l3hn98n41u2b4fbqflr1(a)4ax.com>, Lionel writes: > >On Mon, 22 Apr 2002 11:53:58 +0100, James Cronin <james(a)unfortu.net> >wrote: > >[opt-in bulk email] >>Has anyone ever actually come across such a contract in real life >>or are they just urban myths? > >Urban myth. >If you make damn sure that you clearly mark your bulk mail with the >website/organisation at which your user subscibed, & you record the >*way* they subscribed[0], you should be fine. It's also vitally >important that you respond promptly to email that arrives at your >domain's 'abuse@' address. > >[0] Eg: IP address & time stamp from when they hit the 'subscribe me' >button on a web form, copy of the signed paper form they sent in, etc. See http://www.cctec.com/maillists/nanog/historical/0104/msg00718.html for a NANOG post -- and a link -- on the subject. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

1 0

First stable version (0.1-final) of DoS detection software
by Constantinos A. Kotsokalis 22 Apr '02

22 Apr '02

Hello all, the Panoptis software to detect DoS/DDoS attacks with input from Cisco Netflow has reached version 0.1 final. This is the first stable version! You can download it at: http://prdownloads.sourceforge.net/panoptis/panoptis-0.1.tar.gz Best, Costas -- Constantinos A. Kotsokalis || ckotso(a)grnet.gr Greek Research and Technology Network Tel: +30 10 7474243 || Fax: +30 10 7474490

1 0

[OT]Microsoft makes networked software 'illegal' on XP unless you pay them...
by Bruce Williams 21 Apr '02

21 Apr '02

From http://www.infoworld.com/articles/op/xml/02/03/18/020318oplivingston.xml Microsoft's XP license agreement says, "Except as otherwise permitted by the NetMeeting, Remote Assistance, and Remote Desktop features described below, you may not use the Product to permit any Device to use, access, display, or run other executable software residing on the Workstation Computer, nor may you permit any Device to use, access, display, or run the Product or Product's user interface, unless the Device has a separate license for the Product." I guess this improves security.... bye, Bruce Williams "Asking the wrong questions is the leading cause of wrong answers"

7 8

NANOG 25 and Diamond Aircraft (warning! non-operational content)
by Joe Abley 21 Apr '02

21 Apr '02

For those private pilots planning to attend the meeting in Richmond Hill, Diamond Aircraft are located about two hours (drive) away at CYXU. The popular DA20-C1 two-seat trainer is manufactured on the field, as is the new four-place DA40-180 which has received some glowing reviews recently (see http://www.diamondair.com/ for pretty pictures). If there's any interest in a tour of the facilities, I can give them a call and try to set something up. Note that I have no connection to Diamond other than the fact that I fly from CYXU and think that their planes are cool. Joe

1 0

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