Subject: Re: [dnsop] I-D ACTION:draft-ietf-dnsop-respsize-03.txt

From: Suresh Krishnaswamy <[email-masked]>
Date: Tue, 4 Jul 2006 12:16:35 -0400

I've reviewed draft-ietf-dnsop-respsize-03 and I found it to be a  
useful document. I support it moving forward in its current form  
although clarifications on a couple of points would be helpful.

i) There is still a slight disconnect between the text in 2.2/2.3 and  
RFC2181 (referenced in the document) with respect to the re-querying  
behavior of "possibly damaged" data. If respsize-03 actually   
indicates true behavior, a note to this effect would help.

ii) Section 2.6 says "Some queries to non-existing names can be  
large, however, this is not a problem because the responses include a  
SOA record in the authority section". It would be useful to explain  
why the "possibly damaged" condition is not a problem here.

iii) Is there anything to say about AAAA records in section 2.8? (I  
felt there should be, since there didn't seem to be anything  
currently in this draft that ties up with the conclusion in 4.3).

iv) In section 4.1 is there anything we lose by having all our name  
servers reside under the same parent as opposed to having some of  
them within a different zone?

v) Section 4.3: Why "two to five IPv6 nameserver address records" and  
not "up to five" (or even "up to seven")? Relates to comment iii) above

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mohsen Souissi <[email-masked]>
Date: Wed, 5 Jul 2006 11:50:49 +0200

On 27 Jun, [email-masked] wrote:
 | A New Internet-Draft is available from the on-line Internet-Drafts directories.
 | This draft is a work item of the Domain Name System Operations Working Group of the IETF.
 | 
 | 	Title		: DNS Response Size Issues
 | 	Author(s)	: P. Vixie, . Kato
 | 	Filename	: draft-ietf-dnsop-respsize-03.txt
 | 	Pages		: 10
 | 	Date		: 2006-6-27

==> I have read this version as I did for the previous ones. I keep
supporting this draft and I believe we should make it move forward.

This draft may be very useful for DNS operators managing zones with a
relatively large number of NS's and supporting IPv6 transport, such as
TLD operators.

Apart from sections numbering which is missing after section 5 (Perl
source code), I have one comment and one question (inline) on section 2.8:

>   2.8. The minimum useful number of address records is two, since giving
>   only one address undermines the redundancy requirement.  Implicit
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

==> When IPv6 transport is supported (presence of AAAA RRs), the
redundancy requirement is not necessarily fulfilled with 2 IP
addresses in the additional section. If both IP addresses are
associated with the same NS (for example one in v4 and the other in
v6) then there is a high probability that both of the become
unreachable if the NS encounters trouble (electricity outage, hardware
crash, DNS server stopped, ...). But in the same time, I presume that
the probability of getting in the additional section 2 IP addresses
associated with the same NS is quite low (assuming of course that the
total NS number is relatively large). So should we keep considering
that the "redundancy requirement" is fulfilled when/if the additional
section contains at least 2 IP addresses?

>   truncation (truncation without setting TC bit) which occurs after two
>   address records have been added to the additional data section is
>   therefore less operationally significant than truncation which occurs
>   earlier.

Regards,

Mohsen.

.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 31 Jul 2006 08:35:38 +0000

(i tried to send this out before, but it didn't come through the dnsop
mailman for some reason.  just as well, since much more editing was needed.)

replies to two folks here who graciously reviewed the respsize i-d.  i've
just sent the revised respsize-04 to internet-drafts@, and it's a doozy.
i strongly recommend that it be re-read from scratch since it has been very
nearly re-written from scratch.  (yo, johani! you were right all along!)

--------

> From: [email-masked] (Suresh Krishnaswamy)
> Date: Tue, 4 Jul 2006 12:16:35 -0400
> 

see below.

> behavior of "possibly damaged" data.  If respsize-03 actually indicates
> true behavior, a note to this effect would help.

i've just reread [respsize-03 2.2, 2.3] and [rfc2181 9] and i do not see
any disconnect.  both imply that if TC is set, the final rrset present in
the message might be incomplete.  (rfc2181 is less direct in its implication
but the implication is still quite clear.)  both of these documents are
descriptions of the same "true behaviour" as far as i can tell.  i will
split [respsize-03 2.3] into two paragraphs, though, since it presently
addresses two topics and it's possible to mis-read it as addressing one.

> why the "possibly damaged" condition is not a problem here.

i will split that paragraph into two and expand the second one.

> currently in this draft that ties up with the conclusion in 4.3).

we deliberately said "address records" in 2.8 to include both A and AAAA.
i'll see what i can do in section 4 to better justify 4.3.

> them within a different zone?

i've added a new paragraph after 4.1 to explain this issue.

> not "up to five" (or even "up to seven")? Relates to comment iii) above

"up to five" is better.

--------

> From: [email-masked] (Mohsen Souissi)
> Date: Wed, 5 Jul 2006 11:50:49 +0200
> 
> Apart from sections numbering which is missing after section 5 ...

i've restored these.  often i decide not to number the mandatory sections.

> ... I have one comment and one question (inline) on section 2.8:
> 

upon re-reading [RFC1034 4.1], i see that the redundancy requirement is for
two servers, not two address records.  i will institute that change now.

--------
.