[arin-ppml] IPv6 in the Economist

[Leo Bicknell]

In a message written on Tue, Jun 10, 2008 at 06:25:53PM -0400, Dean Anderson wrote:
> In fact, http://www.ripe.net/docs/ripe-352.html reports some (2005) 
> statistic on EDNSO. Particularly, table 2 shows statistics for k root, 
> and shows that about 34.5% of the queries contain the EDNSO option.  I 
> think this probably represents the percentage of EDNSO-capable recursive 
> nameservers.

I suspect there are several problems with this data point.

Production quality EDNS0 capable servers were not widely available
until around 2001 or so, and with no direct driver to "have to have
EDNS0" most upgrades came as a result of natural software upgrades
for other reasons (e.g. new platforms).  As such, I would suspect
2005 was still in the uptake window.

Also, it's well known that root servers query loads are "special",
in that a large percentage (70-90%, depending on how measured) are
"trash".  Queries for non-existent TLD's due to typos and the like.
Many of these are the result of particularly badly broken software,
often repeating the same broken query thousands of times per hour.

That said, the good folks at RIPE have provided more recent data.
From earlier in the year when AAAA glue was added:
http://www.ripe.net/news/k-root-service-IPv6-glue.html

So in not quite 3 years we've gone from 34.5% to 60%, at the root,
with the caveats listed above.

Also interesting is they study TCP queries, to see if rather than
doing EDNS0 the clients fell back to TCP.  The answer is no, there
was no change.  Also, TCP queries come in at 0.5 qps, while queries
peak at ~14,000qps.

> It is interesting that ns-pri.ripe.net reports 70% queries with EDNSO
> option. This server responds to the people going to RIPE's web pages,
> and is probably more heavily weighted to the comparative 'DNS
> cognoscenti' who frequent the pages and services of RIPE-NCC.  Even the 
> DNS elites don't support EDNSO very well. Hmm.

I would love to see updated statistics for ns-pri, as I believe it
is a much more representative case than a root server.  Given the
change seen at K-Root I would hope ns-pri is above 90% by this time,
hopefully well above.

I also point out that while ns-pri is an order of magnitude less
"unusual" than k.root in terms of the type of queries it receives
it is still special in another way worth noting.  I believe it
almost exclusively hosts in-addr.arpa reverse domains.  I'm not
sure if I think that may cause it's numbers to be skewed in any
particular direction; but it does say to me that we're missing the
data point of a large, authortative, forward only nameserver for
comparison.

> This paper by ICANN (2007) reports ICANNs view:
> http://www.icann.org/committees/security/sac018.pdf 

Appendix E of that paper is quite informative.  There are 9 servers
that don't support EDNS0 listed.  Of those 9, at least two are so
obsolete as to be funny (BIND 4.x servers), JDNSS is self documented
as a "leaf" (their word not mine) server at
http://sourceforge.net/projects/jdnss/ and per the README does not
do iterative or recursive lookups, and QuickDNS seems to actually
be DNS management software, and not a DNS server.  So to me, those four
aren't even important.

So that leaves 5 servers, of which only two seem to me likely for
most of the unsupported problem, BIND 8.2.2, and Microsoft Server
2000.  Both of those should be ending their life cycles in most
organizations.

So I simply draw a different conclusion than you do from the same
data.  It appears to me we have pretty widespread deployment that
has occurred mostly under conditions where the feature was not needed
(natural upgrades for other reasons).  It appears all major packages
likely to be deployed at this time support EDNS0, which means both
if people upgrade for any reason they will get the feature; but
also that if the feature were "required" the small percentage of
the people who didn't have it would have a wide array of choices
for an upgrade path.

While there is a lot of room for improving DNS, and I might even
agree some of the solutions are far from the best that could be
done I see nothing in the data that suggests there is a problem
that should hinder the roll out of IPv6.  To that end, I also see
nothing here that should have a significant bearing on ARIN IPv6
policy regarding IPv6.

That's just my opinion though.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080610/1dfe7926/attachment.sig>