Subject: [dnsop] draft-ietf-dnsop-respsize-02.txt comments

From: Pekka Savola <[email-masked]>
Date: Mon, 1 Aug 2005 09:09:20 +0300 (EEST)

As a generic observation: the document seems to include some of much the
same material as draft-ietf-dnsop-ipv6-issues-11.txt (specifically, its
appendix B).

If folks think it would be a good idea, some or most of the
stuff in that draft's appendix could be moved here -- as it has a lot of
already IESG-reviewed material on additional section processing.

Notes below show some issues which also came up (in one form or another)
during dnsop-ipv6-issues.  This leads me to think the text needs significant
edits and/or merging/copying form dnsop-ipv6-issues appendix B.

    2.2. If the total response size would exceed 512 octets, and if the data
    that would not fit belonged in the question, answer, or authority
    section, then the TC bit will be set (indicating truncation) which may
    cause the requestor to retry using TCP, depending on what information
    was desired and what information was omitted.  If a retry using TCP is
    needed, the total cost of the transaction is much higher.  (See [RFC1123
    6.1.3.2] for details on the protocol requirement that UDP be attempted
    before falling back to TCP.)

==> "which _may_ cause the requestor..." is incompliant with RFC2181, which
requires that if TC is set, the whole response must be discarded, and then
you retry with TCP.  (Whether or not that's efficient or robust is a
different argument, I guess, but that's what the specs mandate.)

    2.3. RRsets are never sent partially unless truncation occurs, in which
    case the final apparent RRset in the final nonempty section must be
    considered "possibly damaged".  [...]

==> this may require a bit of rewording, as above, as the spec says to
discard the response if TC was set no matter what.

   2.6. Average and maximum question section sizes can be predicted by the
    zone owner, since they will know what names actually exist, and can
    measure which ones are queried for most often.  For cost and performance
    reasons, the majority of requests should be satisfied without truncation
    or TCP retry.

==> as above, "truncation or TCP retry" should maybe be "truncation and
TCP retry"

    2.9. The best case is no truncation.  This is because many requestors
    will retry using TCP by reflex, or will automatically re-query for
    RRsets that are "possibly truncated", without considering whether the
    omitted data was actually necessary.

==> as above, not having such "reflexes" would be against RFC2181

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Paul Vixie <[email-masked]>
Date: 02 Aug 2005 04:37:27 +0000

> edits and/or merging/copying form dnsop-ipv6-issues appendix B.

the draft name is draft-ietf-dnsop-ipv6-dns-issues-11.txt for those who,
like me, try to use google to find its text.

i don't nec'ily consider the iesg an expert on this, so their approval
may or may not matter much.  the current -respsize- draft describes what
a large part of the installed base of dns query initiators actually does.

the best thing would be to shorten -respsize- by removing anything it
does not absolutely HAVE to say.

> different argument, I guess, but that's what the specs mandate.)

forgive my ignorance.  i was describing behaviour i'm aware of.  if rfc2181
says that, it's boneheaded, but we should follow it here (or at least remove
any text in -respsize- that conflicts with it) rather than argue about it.

> ==> as above, not having such "reflexes" would be against RFC2181

and yet, since the installed base actually works the way this -respsize-
draft describes, the issues that will affect choices of NS RRsets are
exactly as written, and rfc2181 is possibly-irrelevant.  perhaps adding
a small editorial indicating this schism is the best fix overall?
-- 
Paul Vixie
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Aug 2005 09:44:05 +0300 (EEST)

> like me, try to use google to find its text.

sorry for mistyping from the memory.

> does not absolutely HAVE to say.

That's certainly one option, though then it would give less 
information to the readers.  Personally, documents like this exist to 
educate the community, and clarifying how the TC / additional data 
processing works should help (as obviously different folks have 
different notions of it).  It doesn't necessarily have to be in this 
document, though as topic being discussed is related, this could be at 
least one logical place.

[...]
> any text in -respsize- that conflicts with it) rather than argue about it.
[...]
> a small editorial indicating this schism is the best fix overall?

Note that I sent a query about this on namedroppers a while ago, 
asking for the implementors to report what they're doing.  Below is 
what Jinmei reported on recent versions of BIND, at least.  (There 
haven't been other reports.) Not sure if you were familiar with 
earlier (4.x, more broken?) versions..

=========
>   3. if your implementation (or the implemenations you're familiar
>      with) receives a response with TC bit set and an additional
>      section, what does it do?

>      a) ignore everything in the response, and re-query using TCP.
>      b) keep some or all of the data in the response, re-query using
>         TCP (additional details would be welcome).
>      c) something else, what?

ISC BIND 9.3.1 a)

ISC BIND 8.4.6 a) (there seem to be some exceptional cases, but I
think we can ignore such cases in this discussion).
===============