- Test - lists.nanog.org

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

New DoS attack affecting small NAT devices?
by Donn Lasher 19 Apr '02

19 Apr '02

I don't have more specific information yet, however, just wanted to poll the crowd. Is anyone seeing any recent Denial of Service / Probes affecting NAT devices started in the last couple days / weeks? Starting Tuesday night, we started getting complaints from customers in a specific net block of our network, all of whom were running small "personal" firewalls (Netgear, linksys etc) about: 1. able to send, but not get email 2. able to browse 1% of web pages 3. able to ping / traceroute just fine. pages would load a tiny bit then stall. when they step out from behind the firewall, even using the same IP address the firewall used, they are fine, IE all services. Of the probably 150 customers in that netblock, only 8 of them called with these symptoms, the rest are working fine. I'll have sniffer logs later today, but just wanted to see if anyone else had run into this recently. Feel free to reply offline. -donn

2 1

CAR
by Ken Yeo 19 Apr '02

19 Apr '02

Hi Nanog, Scenario: Transits -----(router A)Backbone(router B)----- Customers We applied Cisco CAR at the edge routers (B) in the Backbone to rate limit inbound and outbound traffics to/from Customers. If transmission rate is higher than the rate limit threshold, IP packets are being dropped by router B. How do we prevent the excess IP packets to consume the transit links and the Backbone? Here is my understanding: -For TCP traffics (HTTP, FTP), TCP senders will stop sending packets when the TCP windows threshold is reached. -For UDP based audio/video trafffics, if the applications use RTSP and H.323, RTCP/H.245 will signal the sender to slowdown the transmission if the receiver lost packets. Did I miss anything? How about UDP traffics that are not using RTSP/H.323? Thanks. Suan "Ken" Yeo Network Engineer Aurum Technology ken.yeo(a)aurumtechnology.com

3 6

Links between cabinets at commercial datacentre
by Andy Rabagliati 18 Apr '02

18 Apr '02

Folks, Wishing to set up an alternative peering point in our fair city, we have run into a problem with the data center administration. The data center prohibits direct cabling between clients cabinets, even if the clients agree. Our peering point is not in the data center, but is in the same building, and will necessitate data center clients separately running fibre to our room, and paying not only for installation but also monthly fees proportional to bandwidth carried. We are in South Africa, the monthly fees are related to wireline costs, even though the monopoly wireline provider, Telkom, is not involved. Without this rule, we would run one fibre between the datacenter and the peering point, and have peers in the datacenter hop on that fibre. While acknowledging that a data center may make any rules it likes, I am asking nanog how common this practice is. If people mail me offlist, I would be willing to summarise if there is enough interest. Cheers, Andy!

9 12

XO problems?
by Joe Blanchard 18 Apr '02

18 Apr '02

Anyone seeing issues with XO routing? /root# traceroute www.cisco.com traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets 1 132.237.9.3 (132.237.9.3) 3.510 ms 0.448 ms 0.443 ms 2 132.237.245.1 (132.237.245.1) 0.739 ms 0.791 ms 0.790 ms 3 67.104.110.113 (67.104.110.113) 1.826 ms 2.091 ms 1.860 ms 4 p4-3-0.MAR1.Fremont-CA.us.xo.net (207.88.80.9) 2.044 ms 2.088 ms 2.112 ms 5 p5-1-0-0.RAR1.SanJose-CA.us.xo.net (65.106.5.141) 2.438 ms 2.371 ms 2.368 ms 6 p1-0-0.RAR1.Washington-DC.us.xo.net (65.106.0.37) 82.448 ms 87.242 ms 82. 110 ms 7 p6-0-0.RAR2.NYC-NY.us.xo.net (65.106.0.1) 86.110 ms 86.055 ms 86.090 ms 8 ge5-0.dist1.hud-ny.us.xo.net (64.220.3.65) 86.688 ms 86.560 ms 86.586 ms 9 ge6-0.edge1.hud-ny.us.xo.net (64.220.3.83) 86.734 ms 86.715 ms 86.835 ms 10 * * * 11 * * agr1-loopback.NewYork.cw.net (206.24.194.101) 3100.552 ms 12 * * *

6 5