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.
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 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
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...)
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.
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.
> 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.