Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-respsize-14.txt

From: Gilles Massen <[email-masked]>
Date: Tue, 05 Jun 2012 17:28:16 +0200

Coming back to this unanswered question: from my point of view the color
matching seems a bit harsh with regard to operational reality. I
certainly won't get any nightmares for non exhaustive additional
sections in response to extremely large queries.

This said, while looking at this I noticed something that leaves an
uneasy feeling: for an extremely large query, I get 2 types of responses
from the root servers.

One set of root servers fills the additional section with 2 names, and
their v4 and v6 addresses. But it's always the same two servers,
indepently of the server asked. The other set answers with a bit more
servers, but only v4 adresses, and here again, always the same list.

I was expecting (perhaps naively) that the additional section would be
filled randomly until no space is left. The current setup seems to
restrict some of the inherent redundancy of the DNS.

Any thoughts?

Gilles

On 22/5/12 17:00 , Edward Lewis wrote:
> I looked back at this and noticed I should have said "the right matrix"
> is more important.
> 
> Still, I'm a little surprised there's been no response from a comparison
> of a DNS Operations WG document to real-world measurements.
> 
> Are we okay with a document that issues criteria that only 70% of TLDs
> fall into "green?"  Are the grades overly harsh?  Should the TLDs be
> urged to work on getting to green?
> 
> At 13:55 -0400 5/10/12, Edward Lewis wrote:
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-14.txt
>>
>> For kicks I ran the included perl code against the 313 delegations
>> from the root zone (313 does not include "root" and does include the
>> 11 test TLDs).
>>
>> ...I'll leave it to the draft to explain the headings and rankings
>> below.  I did this just to measure the draft's assessments against the
>> TLD settings.  Not that the TLDs are the only audience of this draft,
>> but it's a convenient data set.
>>
>> Measured in %'ages of 313:
>>
>>            Max length domain name     ||    Average length domain name
>> Color     A-only  A+AAAA A-preferred  ||    A-only  A+AAAA A-preferred
>>                                       ||
>> Green       59%     19%    19%        ||       99%    69%    69%
>> Yellow      35%     41%    18%        ||        1%    31%    28%
>> Orange       4%     21%     9%        ||                      1%
>> Red          2%     11%    53%        ||                      2%
>>
>> The left matrix is more important (operationally).   That's about the
>> only commentary I'll add, just to head off the concern of "red"s in
>> the right matrix.
>>
>> To Paul and Akira, here's more or less what I did with the results of
>> the pl:
>>
>> looping through the names in the root zone:
>>    server_set=`dig @127.0.0.1 +short $name ns`
>>    size_estimate=`perl respsize.pl $server_set`
>>    results=`echo $size_estimate | sed "getting '()'s#$name \2 \3 \4 \6
>> \7 \8#"`
>>    echo "$results"
>> and then used a spreadsheet to do the percentages.  (Shown in case I
>> messed up something.)
>> -- 
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>
>> Edward Lewis
>> NeuStar                    You can leave a voice message at
>> +1-571-434-5468
>>
>> 2012...time to reuse those 1984 calendars!
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
> 

-- 
Fondation RESTENA
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Jun 2012 10:23:47 -0700

> servers, but only v4 adresses, and here again, always the same list.

It might be instructive to spell out what query you tried, and what your results were (per letter).

Some root servers are not shy about telling the world what software they are running, but others prefer to obfuscate:

[krill:~]% for n in $(jot -c 13 a)     
for> do echo "${n}: $(dig @${n}.root-servers.net version.bind ch txt +short)"
for> done
a: "This space intentionally left blank"
b: "4.8.1"
c: "c-root"
d: "9.8.1-P1"
e: 
f: "9.7.4"
g: ""
h: "NSD 3.2.10"
i: "contact [email-masked]"
j: "This space intentionally left blank"
k: "NSD 3.2.8"
l: "NSD 3.2.8"
m: "9.7.3-P3"
[krill:~]% 

I can confirm the version string for L is accurate. The versions shown above for D, F, H, K and M look plausible to me, although I can't speak authoritatively about what they are doing.

If you wanted to nail down the different behaviour to particular versions of software, the rootops are all here and will no doubt crawl out of the woodwork if there are questions to answer.

Joe

---

From: Gilles Massen <[email-masked]>
Date: Wed, 06 Jun 2012 11:56:10 +0200

Agreed, here are the queries:

q=`jot -s . -b 123456789 25`.lu
for n in $(jot -c 13 a); do dig @${n}.root-servers.net $q +norec
+noquestion +noanswer +noauth +nocomment +nostat; done

There are 2 groups of additional sections:
A, C, E, I, J: 2 names, with their v4+v6 addresses
B, D, E, G, H, K, L, M: 4 names, only v4 addresses

What stroke me was 2 things:
- both groups do not change the answers on subsequent queries. So for
the first group, if the 2 servers are down, your done.
- the second group doesn't provide any v6 addresses at all.

Now I don't want to pick on any implementation, rather get an idea of
the reasoning behind the behaviour... (I do agree that the query is a
bit extreme). And if operators think that this might lead to problems.

Gilles

On 5/6/12 19:23 , Joe Abley wrote:
> Joe=

---

From: Anand Buddhdev <[email-masked]>
Date: Wed, 06 Jun 2012 12:19:17 +0200

> bit extreme). And if operators think that this might lead to problems.

Hi Gilles,

We operate K-root with NSD, which prefers A glue over AAAA glue. If the
client is not ENDS0-capable, then NSD will first fill the additional
section with as much A glue as it can. This can sometimes result in the
client not getting any AAAA glue.

I believe the reasoning for this decision is that if a client isn't
ENDS0-capable, then it's a reasonable assumption that it is also not
IPv6-capable, so it's better to give it as much A glue as possible.

Regards,

Anand Buddhdev
RIPE NCC

---

From: Akira Kato <[email-masked]>
Date: Wed, 06 Jun 2012 19:32:57 +0900 (JST)

Dear Gilles,

I lost the point related to the draft, however, what I assumed was
the following:
    DNS clients (or client side of recursive servers) which are
    able to use IPv6 glue records effectively likely support EDNS0.
So in M-Root, I gave priority IPv4 glue records over IPv6 glue records.
Please add "+bufsize=1280" to your dig commend to get a different result.

-- Akira Kato

From: Gilles Massen <[email-masked]>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-respsize-14.txt
Date: Wed, 06 Jun 2012 11:56:10 +0200

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Jun 2012 22:48:47 +1000

> bit extreme). And if operators think that this might lead to problems.

A properly functioning resolver will request the missing glue from
the root servers and named at least will return it in the additional
section or set TC=1.  Glue isn't supposed to be truncated according
to RFC 103[45] as it is not additional data.  It is part of the
referral and should cause TC=1 to be set if it won't fit.

> > I can confirm the version string for L is accurate. The versions shown above for D, F, H, K and M look plausible to me, altho
> ugh I can't speak authoritatively about what they are doing.
> > 
> > If you wanted to nail down the different behaviour to particular versions of software, the rootops are all here and will no d
> oubt crawl out of the woodwork if there are questions to answer.
> > 
> > 
> > Joe=
> 
> 
> -- 
> Fondation RESTENA
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: paul vixie <[email-masked]>
Date: Wed, 06 Jun 2012 12:53:55 +0000

On 6/6/2012 12:48 PM, Mark Andrews wrote:
> ...

terminologically we've diluted the term "dns glue" so that at this point
in history that term could be used by some speakers to refer to the
A/AAAA RR's that are auto-added in the additional data section for
things like MX or SRV.

in respsize we try to distinguish this with phrases like "soft
truncation" and "hard truncation". so while i agree with marka's
characterization, his wording above requires that the word "glue" be
considered to refer only to the A/AAAA RR's added to the additional data
section when the response is a referral. since that use of this term is
now non-universal, i think it's necessary to describe it using less
ambiguous terminology.

paul