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

From: Paul Wouters <[email-masked]>
Date: Mon, 7 Aug 2006 23:12:50 +0200 (CEST)

My comments on draft-ietf-dnsop-respsize-05.txt

2.1.3

"unless TC bit set" -> "unless the TC bit is set"

2.3.1

One might consider the case where there is not enough space
for all common transports. Perhaps the advise should then be
to prefer the common transport on which the query came in,
since that transport is likely to be more useful to the
requester?

2.3.4

Why is such a distinction needed? In other words, what is the
advise given in this section for use of this distinction.

3

I think I am also missing the correlation between authority and
additional section with respect to truncating. As per example in
section 3, image that C.GTLD-SERVERS.NET would be silently
truncated, then its corresponding record in the additional section
should be truncated as well, and not another A record which did
make it into the authority section.

Paul
.
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, 8 Aug 2006 15:00:25 +0300 (EEST)

> since that transport is likely to be more useful to the

The issue is not necessarily that simple, so I'm not sure if it's 
possible to give one-size-fits-all advice.  See Appendix B of RFC 4472 
for more.

-- 
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: 08 Aug 2006 18:03:24 +0000

> My comments on draft-ietf-dnsop-respsize-05.txt

note that -06 is also in the pipeline, containing some the things i missed.

> "unless TC bit set" -> "unless the TC bit is set"

fixed for -07 (which won't be submitted until i hear more -05/-06 comments.)

> since that transport is likely to be more useful to the

as pekka said, the situation is more fluid than that.  consider the
possibility that the referring (parent) zone's name servers are not
reachable by more than one protocol but the referred (child) zone's
are, and suddenly "the transport on which the query came in" is no
longer useful information.  rather than attempt to document every
permutation, i think we should keep the advice as general as possible.

> advise given in this section for use of this distinction.

so that we can refer to the distinction in 2.3.6.

> make it into the authority section.

not at all.  if any part of an rrset will not fit, then the rrset is
damaged.  if the rrset is required (for example, to help a requester
determine that this is a referral rather than an empty answer) then
the TC bit would have to be set.  once you're in TC-bit territory,
it doesn't matter what glue you put in or leave out.
-- 
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: Paul Wouters <[email-masked]>
Date: Tue, 8 Aug 2006 22:10:22 +0200 (CEST)

> as pekka said, the situation is more fluid than that.

Understood.

> so that we can refer to the distinction in 2.3.6.

I guess I am somewhat confused here.

2.3.4 tells us when to set and when not to set the TC bit.
2.3.6 tells us:

   If any "necessary content" is silently truncated, then it is
   advisable that the TC bit be set

I guess the confusing parts are the overlaps between "necessary content"
and "additional section", eg when glue is vital for a zone to function.
Because "necessary content" can be either just the authority section,
or the authority section plus the additional section.

But "2.1.4" says we should always treat the additional section as
"possibly incomplete" if it contains glue, implying this can happen with
the TC bit not being set.

Shouldn't it just state that "necessary content" should not be silently
truncated?

Or if we add glue, why not just always set the TC bit, if we recommend
that practise later on for nameservers anyway, instead of creating the
state of "silent truncation"?

Let me think of some extreme example, say example.com with 16 NS records
ns[1..16].example.com, so lots of glue, with the cut somewhere in the
additional section.

Does the draft now advise to set the TC bit or not? And should nameservers
always assume this is possibly incomplete and always do a TCP retry?

> it doesn't matter what glue you put in or leave out.

What is "required". Are 16 NS records and their glue "required". I believe
you mean that to be the case (if the zoneadmin is silly enough to create it),
while if I look from a resolving point of view, having less then 16 records
is all I would "require", as long as there are a number of matching NS records
with A* record glue. In which case, I think (but i am uncertain grounds here)
that the TC bit should be set, but the nameserver might decide to try these
records first, before doing a TCP retry to obtain the full records in case
the original records all failed?

Maybe the word "required" is a bit ambiguous here. (at least in my brain)

Paul
.