Subject: [DNSOP] Review of draft-ietf-dnsop-respsize-15

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 6 Apr 2014 16:06:06 +0200

[This is about draft-ietf-dnsop-respsize-15]

IMHO, the draft is not ready to be published. Details:

I believe it is important to have such a document on the consequences
of the DNS response size. I congratulate the initial authors and the
recent resurrector. The document is a thorough analysis of the
intricacies of DNS responses.  However, in its current form, there are
two issues, an inconsistent terminology, and a pessimistic tone which
do not seem fully backed by the facts.

The biggest issue comes from the many misuses of the word
"truncation". Unlike many DNS concepts, where there is no standard
vocabulary and huge variation between RFCs, "truncation" is well
defined (RFC 2181, section 9, since RFC 1035 was much more
sloppy). Truncation == TC bit set == an incomplete RRset was included.

But the draft often uses truncation in a much broader meaning,
something like "I would have wanted to include more data", meaning
which is explicitely excluded by RFC 2181. OMISSION OF DATA IS NOT
TRUNCATION and this draft keeps forgetting that. Examples:

Section 3.1 "Note that truncation of the additional data section might
not be signaled via the TC bit since additional data is often
optional" which is false (if the TC bit is not set, there is no
truncation, per definition; if there is an incomplete RRset even in
the additional section, TC bit MUST be set).

Section 3.2 "The best case is no truncation at all.  This is because
many requesters will retry using TCP immediately, or will
automatically requery for RRSets that are possibly truncated, without
considering whether the omitted data was actually necessary." It is
not false but it seems to imply that omission of some data is the same
thing as truncation.

Section 3.3 "If any "necessary" content cannot be fit in the response,
then it is advisable that the TC bit be set" This directly contradicts
RFC 2181, section 9.

Note also that "required" and "necessary" are used in the draft but
never defined. In a referral, the only RRset (for non-DNSSEC answers)
which is really required is the NS set. Glue records are not required
(you can always make a specific request for them: it means one more
RTT but it will work). Section 3.3 is very ambiguous here, in its
second paragraph.

My suggestions for fixing this would be:

1) A clear reminder of the definition of truncation, stating that
truncation == TC bit set, and truncation /= omission of data.

2) A definition of "required". Something like: "data is required if
its absence would stop the name resolution process". For instance,
including the IP addresses of name servers is an optimization, it is
not required, even if the name servers are in-zone.

3) Modify the draft to use "truncation" only when it fits. Use
"omission of data" for the rest.

Second issue, the pessimistic tone. The draft could be read as a
warning that horrible things will happen if the size of the answer is
not kept well below 512 bytes. But, since the version -00 has been
published, typical response sizes have increased and nothing
happened. The respsize.pl tool flags .com as always red, for maximum
size queries. But we observe daily that .com works. 

Technical:

I've reviewed the tool respsize.pl, both by checking its source code
and by running it against many different zones and it seems
flawless. The actual quantitative analysis of DNS sizes (this tool,
and section 3) is the best part of the draft and a good reason to
continue the work on it.

Editorial:

Abstract: "With a mandated default minimum maximum UDP message size of 512
octets" The concept of minimum maximum is not clear.

Section 3.2 : "Anycast [RFC3258] [RFC4786] is a useful technique for
improving performance and below the zone cut being described by a
delegation is responses." My parser crashed here.

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 6 Apr 2014 07:38:14 -0700

> size queries. But we observe daily that .com works. 

To add to this: The horribles when they do occur occur not at 512b but at ~1400B, when things start fragmenting, as far too many devices (and its worse on IPv6) have decreed that fragments don't work.  

This also means that the recursive resolver, unless its doing raw packet reception, does not know that this is the problem source.

Yet even in this case, its only a few (single-digit-percent) of recursive resolvers affected (its more when you include the path to the clients).  

My belief is that EDNS0 fallback (like what BIND does) should be to use an MTU of 1400B and then 1200B first (which guarantees no fragmentation on IPv6, even in the face of tunnels, and a practical guarantee of no fragments on IPv4), rather than skipping directly down to EDNS with an MTU of 512B, and if multiple authority servers require this fallback, the recursive resolver should use this MTU for all authorities, and just accept the minor latency hit incurred in having to shift to TCP more in the very rare case

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Apr 2014 15:49:02 +0100

Sorry for the delayed reply...

Stephane Bortzmeyer <[email-masked]> wrote:

Your comments on the draft are very good and I agree with them. Minor
quibble, though:

> RTT but it will work).

I don't think this is right: if you ask a parent zone name server for a
glue record, you will get a referral to the child just as if you asked for
any other record in the child zone. So glue records have to be present in
referrals.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Biscay: Variable 4 becoming cyclonic then mainly westerly 5 or 6. Slight
or moderate. Occasional rain or showers. Moderate or good, occasionally poor.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Apr 2014 10:34:38 +1000

> any other record in the child zone. So glue records have to be present in

Correct.  Glue is not optional.  Failure to fit glue should result
in TC=1.  It is a mis-reading of RFC 1034 that all additional records
are optional.  Only data added at Section 4.3.2, step 6 is optional.
Note the word "attempt".  All other data is required including that
added at Section 4.3.2, step 3b.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

There are secure referrals where the authority section leaves no
space for additional records with EDNS@512.  Named sets TC=1 for
these when the <QNAME,QTYPE> matches a glue.  Without TC=1 being
set resolution failures occur.  It would be much simpler to do it
whenever glue does not fit independent of QNAME or QTYPE however
this would result in every COM and NET referral from the root setting
TC=1 for plain DNS.

Mark
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 27 Apr 2014 16:47:38 +0200

On Wed, Apr 23, 2014 at 10:34:38AM +1000,
 Mark Andrews <[email-masked]> wrote 
 a message of 46 lines which said:

> Correct.  Glue is not optional. 

OK, sorry for my mistake and thanks to Tony and you for noticing it.

This error, IMHO, reinforces my remark that we need a definition of
what is "required" data. I suggested "data is required if its absence
would stop the name resolution process" and it seems to fit well here.