ICANN/GNSO GNSO Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] Re: Root server traffic

  • To: ga@xxxxxxxxxxxxxx
  • Subject: Re: [ga] Re: Root server traffic
  • From: Peter Dambier <peter@xxxxxxxxxxxxxxxx>
  • Date: Fri, 23 Nov 2007 15:30:12 +0100

Seen from my own little network:

; <<>> DiG 9.4.0b4 <<>> -p 5353 -t any cagyas.local @cagyas.lomiheim
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1444
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;cagyas.local.                  IN      ANY

cagyas.local.           10      IN      A
cagyas.local.           10      IN      HINFO   "I686" "LINUX"

;; Query time: 43 msec
;; WHEN: Fri Nov 23 14:34:52 2007
;; MSG SIZE  rcvd: 69

Port 5353 is avahi or zeroconfig or rendezvous or bonjour and
you can find it on linux, OS-X or windows.

When I introduce a zone ".local" on my dns-server then cagyas
bites and wont start avahi when booting.

So cagyas obviously did query dns and if it would have been my
dump router who answered it would have forwarded the query for
".local" to the root. Every windows vista will do. Every mac
will do. Many linuxes and some BSDs will do.

Aha, even when I switch on my PC to work locally it will
query the root for ".local". No wonder ".local" gets more
traffic than ".com".

You can teach your own personal dns root-server a lot of things.
You can be asured it will never query the root-servers at all.

But the poor bastards who dont know what a root-servers is will
continue to query their SoHo NAT-router and that dump little
box will happily forward every nonsense to any dns-servers it
sees including the root-servers.

As long as you dont answer, as long as you answer NXDOMAIN,
the box will merryly continue nagging.

I remember there used to be a "ping of death", alas DSL wont
let those seemingly big packets through. No chance to kill
the box. Introducing ".local" into the root is an idea.

The users will learn to unplug the internet when they are
working local only.

Maybe even microsoft will learn how to write rfc compliant
software if enough endusers complain.

Or whe can run the root-servers for money and charge for
every query. Then the root operators will happily run and
buy machines 50 times as big, be to be able to answer every

As a compromise we might teach the root how to bite back.

Yes, answering authoritatively for domains you are not
authoritative for is bad. But risking the root-servers to
break is worse.

AS112 is a means to protect the root.


The inclusive domains are known and documented. Just as
easyly as AS112 can catch all those internal queries the
root could forward the inclusive domains where they belong.

I have seen a server from microsoft who claims to be
authoritative for ".local".


Kind regards
Peter and Karin Dambier

Roberto Gaetano wrote:
Joe Baptista wrote:

Well how do you explain .elvis? or .corp? Neither are mistypes.

Correct. However, they are still bogus, because they are quesries sent to
the wrong service.
This is sort of what I call the "Cacao Meravigliao" effect (one of this days
I will send an off-topic message to describe the phenomenon to folks who,
due to age or geographical location, were not exposed to it): the request is
formally compliant with what you have heard about, but addressed the wrong

What is happening here is people sharing URLs outside their local root are causing a good deal of the heavy traffic at IANA roots. China is one excellent example of this. The chinese TLDss Öйú (which means ¡°China"), ¹«Ë¾ (which means ¡°company"), and ÍøÂç (which means ¡°net") are used by over 50 million people daily. When those people communicate with others who do not use the china root and send them china root URLs then anytime those IANA users click on these URLs the net result is the root servers get queried. That means the logs at the IANA roots show traffic for these TLDs, or more specifically their IDN equivalents.

I am far from being a technical guru, therefore I might stand corrected, but
AFAIK the Chinese use a translation of an url of the type
<domain_name>.<IDN_TLD> into <domain_name>.<IDN_TLD>.cn. This translation is
done by the ISP, without the user knowing. So, when users outside China try
to refer to an url of that type, they get what is fairly logical to get: an
error. This affects users resident outside China, as well as Chinese
travelling abroad. The equivalent example in terms of telephone, is somebody
calling a chinese number without dialling the +86, and expecting it to work:
it does while you are in China, while it does not from outside China.

Think about it folks - that 50 million users accessing TLDs outside the IANA deprecated root. Anytime those users communicate with other using those URLs - bingo the roots get a request for something they don't know. And I suspect 50 millions users associated with those TLDs are causing alot of error traffic at the IANA roots.

True, that it generates a lot of bogus traffic.
False, that they are trying to access sites not reachable via the standard
The so-called "Chinese root" is only a [set of] branch[es] under the .cn
TLD. These IDN TLDs are, in fact, IDN SLDs under .cn. Something that exists
under many TLDs in the standard root, and something that can be easily
accessed if you use the "real" url, not relying on a translation by an
intermediate element of the chain.
As a matter of fact, the argumentation used based on the observation of the
high error rate is the most powerful argument I have seen so far for a
unique interoperable system: if you do not use the standard, you get lots of


Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter@xxxxxxxxxxxxxxxx
mail: peter@xxxxxxxxxxxx.pirates

<<< Chronological Index >>>    <<< Thread Index >>>