Based on a recent presentation done by KC (Caida) here is a URL to the " 20 AS's case more than 50 percent of the RFC1918 PTR updates" http://www.caida.org/outreach/presentations/dns0209/mgp00025.html It would seem that folks like 4134 3352 7132 5673 5676 (top five) could mitigate this traffic with ease.
It seems to me that some folks may not realize who owns John Brown's 5 AS villains. 4134 is Chinanet 3352 is Ibernet 7132 is Southwestern Bell and 5673 ) 5676 ) are both SBC As Southwestern Bell is a part of SBC, it looks like SBC is a major villain where RFC-1918 DNS traffic is concerned. Peter
Not my villains. :) More the Internet's villains :) or AS 112's Villians I left out the AS string lables as a excersise for the reader. SBC could solve this with some simple changes on their network DNS system. On Sat, Sep 14, 2002 at 04:53:30PM -0500, Peter Salus wrote:
It seems to me that some folks may not realize who owns John Brown's 5 AS villains.
4134 is Chinanet 3352 is Ibernet 7132 is Southwestern Bell
and
5673 ) 5676 ) are both SBC
As Southwestern Bell is a part of SBC, it looks like SBC is a major villain where RFC-1918 DNS traffic is concerned.
Peter
On Sat, 14 Sep 2002, Peter Salus wrote:
It seems to me that some folks may not realize who owns John Brown's 5 AS villains.
More information is available than just the previous chart. http://www.caida.org/~broido/dns/rfc1918.html "We see that more half of the updates come from 20 ASes, which is only 0.6% of the total number of autonomous systems. On that aggregation level, RFC1918 update traffic is clearly dominated by elephants. The largest numbers come from incumbent telecom carriers for respective regions, and from cable companies. Backbone ISPs produce fewer updates. This is not surprising since these ISPs cater mostly to medium and large business customers who often have fewer, but larger networks and use globally unique addesses. Even when these corporations use RFC1918 space, they are more likely be properly configured. The cable and DSL companies charge for globally unique addresses which encourages customers to use RFC1918 addresses internally, thus creating more potential for leakage. Countries, such as China, that are relatively late in joining the Internet have trouble getting enough global address space allocated from the registries." My analysis the same data might vary a bit. I tend to assume the clue-level (or lack of clue) is more or less uniformly distributed. I'm a bit suspicious of the theory that large corporations are more likely to properly configured RFC1918. My suspicion is the half of the updates are transiting through providers serving individuals and small busineses without their own ASN so the updates appear to come from the provider's ASN. The other half of the updates are transiting through providers serving medium and large businesses with separate ASNs. NSPs (i.e. backbone ISPs) probably have fewer updates from their backbone ASN because more of their customers have a separate ASN.
It seems to me that some folks may not realize who owns John Brown's 5 AS villains.
More information is available than just the previous chart.
note that we do not yet have unified statistics amongst all AS112 speakers. therefore caida's measurements are of ISC's AS112 speaker, and will show a tilt in the direction of ISC's anycast clients -- those initiators whose routers think that ISC is the closest path to AS112. -- Paul Vixie
It would not surprise me that pacbell/swbell aka SBC and Time Warner/Roadrunner are among the biggest offenders here. A significant portion of their customers are DSL/cable mode subscribers. Since Win2k and I assume XP both attempt to perform dynamic dns updates, hosts behind NAT, windows will happily send the update requests up the dns tree as far as it can. When @Home was around, the primary name servers for home.com used to see update attempts constantly. Paul Vixie has posted in here statistics about the root levels getting hammered by such update attempts in the past. Any technical solution performed at the network level would be a bubble gum and duct tape attempt to fix what was poorly engineered at the software level. Since it's unlikely Microsoft will issue some sort of fix to the problem. Perhaps IANA should set the name servers to an address within each particular block, that would at least keep the traffic local to the organization, and not hammer larger internet infrastructure name servers. Sameer
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Peter Salus Sent: Saturday, September 14, 2002 2:54 PM To: John M. Brown Cc: nanog@merit.edu; peter@matrix.net Subject: Re: Top AS Offenders causing RFC-1918 DNS traffic
It seems to me that some folks may not realize who owns John Brown's 5 AS villains.
4134 is Chinanet 3352 is Ibernet 7132 is Southwestern Bell
and
5673 ) 5676 ) are both SBC
As Southwestern Bell is a part of SBC, it looks like SBC is a major villain where RFC-1918 DNS traffic is concerned.
Peter
On Sat, Sep 14, 2002 at 05:09:02AM -0700, Sameer R. Manek wrote:
Since Win2k and I assume XP both attempt to perform dynamic dns updates, hosts behind NAT, windows will happily send the update requests up the dns tree as far as it can. When @Home was around, the primary name servers for home.com used to see update attempts constantly.
Paul Vixie has posted in here statistics about the root levels getting hammered by such update attempts in the past.
Any technical solution performed at the network level would be a bubble gum and duct tape attempt to fix what was poorly engineered at the software level. Since it's unlikely Microsoft will issue some sort of fix to the problem.
at URL: http://www.caida.org/outreach/presentations/dns0209/mgp00021.txt malformed A queries were 14% of the load at F.root asking for the IP address of an IP address example: "A 206.168.0.4" - should not happen guilty: Microsoft Win2k resolver, viruses (win95/98/nt), macOSX resolver --> (good news: with our help, Microsoft found and fixed --> this bug in Win2k (although the way to turn off a bad default configuration is 6 or so menus deep...) -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
MS has issued fixes for 2K and XP. Roots aren't hammered as much any more, now that AS112 is up and running. At one point I helped run the servers for blackhole.iana.org, the volume of traffic was very high at times. At times over 100Mb/s worth of PTR requests. One of the interesting things I saw was a corilation between some enterprise sites getting DDOS'd with RFC1918 source packets and their IDS/Firewall tools attempting to do PTR look ups. Thus blackhole-1 and blackhole-2 .iana.org got slammed. I would call these orgs, speak to their net people and we would mitigate by having them become authoratative for RFC1918.in-addr.arpa. Once they did that, we never saw their traffic again. This lead to anycasting RFC-1918 services and the AS112 project. AS112 and to anycast was Pauls idea. It saved the two servers and the transit those to servers had at IANA. And it localizes the impact on the net. The amount of DynDNS updates was much less. Become AUTH for RFC-1918.in-addr.arpa and I suspect you will see that traffic sink inside your network and not leave to hammer others. Setting the RFC-1918's to resolve to a server in 1918 isn't a good idea. john brown speaking as a geek and for no org. On Sat, Sep 14, 2002 at 05:09:02PM -0700, Sameer R. Manek wrote:
It would not surprise me that pacbell/swbell aka SBC and Time Warner/Roadrunner are among the biggest offenders here. A significant portion of their customers are DSL/cable mode subscribers.
Since Win2k and I assume XP both attempt to perform dynamic dns updates, hosts behind NAT, windows will happily send the update requests up the dns tree as far as it can. When @Home was around, the primary name servers for home.com used to see update attempts constantly.
Paul Vixie has posted in here statistics about the root levels getting hammered by such update attempts in the past.
Any technical solution performed at the network level would be a bubble gum and duct tape attempt to fix what was poorly engineered at the software level. Since it's unlikely Microsoft will issue some sort of fix to the problem.
Perhaps IANA should set the name servers to an address within each particular block, that would at least keep the traffic local to the organization, and not hammer larger internet infrastructure name servers.
Sameer
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Peter Salus Sent: Saturday, September 14, 2002 2:54 PM To: John M. Brown Cc: nanog@merit.edu; peter@matrix.net Subject: Re: Top AS Offenders causing RFC-1918 DNS traffic
It seems to me that some folks may not realize who owns John Brown's 5 AS villains.
4134 is Chinanet 3352 is Ibernet 7132 is Southwestern Bell
and
5673 ) 5676 ) are both SBC
As Southwestern Bell is a part of SBC, it looks like SBC is a major villain where RFC-1918 DNS traffic is concerned.
Peter
On Sat, 14 Sep 2002, John M. Brown wrote:
I would call these orgs, speak to their net people and we would mitigate by having them become authoratative for RFC1918.in-addr.arpa.
Is it time to update RFC 1912? The original author has noted several additional errors, including the ommission of 1918 addresses. Although I guess since 1918 was published after 1912, that isn't surprising. http://www.visi.com/~barr/rfc1912-errors.html A published RFC is easier to reference when trying to get people to change their behavior than a personal web site. I remember configuring my DNS servers many, many years ago to sink 0, 127, 255 and RFC1918 addresses. But I can't remember what authority I used to justify it. Most DNS servers sink 127.in-addr.arpa, probably because the default configuration and just about every DNS book published shows it in the configuration file. Sinking the other "well-known" bogons seems to rely on word of mouth.
participants (6)
-
Henry Yen -
John M. Brown -
Paul Vixie -
Peter Salus -
Sameer R. Manek -
Sean Donelan