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

From: [email-masked]
Date: Mon, 17 Dec 2007 21:10:02 -0500

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 Referral Response Size Issues
	Author(s)       : P. Vixie, A. Kato
	Filename        : draft-ietf-dnsop-respsize-09.txt
	Pages           : 13
	Date            : 2007-12-17

With a mandated default minimum maximum UDP message size of 512
octets, the DNS protocol presents some special problems for zones
wishing to expose a moderate or high number of authority servers (NS
RRs).  This document explains the operational issues caused by, or
related to this response size limit, and suggests ways to optimize
the use of this limited space.  Guidance is offered to DNS server
implementors and to DNS zone operators.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-09.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-dnsop-respsize-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsop-respsize-09.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 18 Dec 2007 11:56:16 +0100

On Mon, Dec 17, 2007 at 09:10:02PM -0500,
 [email-masked] <[email-masked]> wrote 

> 	Filename        : draft-ietf-dnsop-respsize-09.txt

[Quite good, IMHO and clearly improved.]

I'm still uneased about the notion of "silent truncation" (section
2.3). To me, what is described here (not sending part of the glue) is
not truncation at all (a word which has a very specific meaning in the
DNS). What is the opinion of the WG? Am I the only one complaining
here?

The abstract still mentions "zones wishing to expose a moderate or
high number of authority servers (NS RRs)" probably because they are
politically important (ICANN issues for the root and root-servers.net)
and because they raise specific problems, such as glue management. But
do we really want to limit this document to NS RRs? It seems to me
that a part of the document is still worthy for other records, such as
TXT. (Section 1 mentions the issue and refers to RFC 3226.) I would
like to be sure that this "limitation" is indeed a deliberate
decision.

Editorial issues:

Section 4, "one address records" should be "one address record"

Section 8, "programing" should be "programming"

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 18 Dec 2007 11:56:16 +0100

Editorial issues:

---

From: Akira Kato <[email-masked]>
Date: Fri, 21 Dec 2007 17:02:56 +0900 (JST)

Dear Stephane,

Thanks for your comments and apologize some delay of my
response. 

First of all, the editorial issues have been fixed.

> DNS). What is the opinion of the WG? Am I the only one complaining

Are you just saying that a phrase "silent truncation" is inadequate?
If it is, we need may try to replace it with another represtation.

> It seems to me that a part of the document is still worthy for other
> records, such as TXT. (Section 1 mentions the issue and refers to
> RFC 3226.) I would like to be sure that this "limitation" is indeed
> a deliberate decision.

TXT records are usually included in the answer section only. Is there
any exceptional case? If a TXT RRset is bigger than the available
space, the TC bit set. So the situation is different from the referral
case.

-- Akira Kato

---

From: Akira Kato <[email-masked]>
Date: Fri, 21 Dec 2007 17:02:56 +0900 (JST)

Dear Stephane,

-- Akira Kato

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 21 Dec 2007 09:41:05 +0100

On Fri, Dec 21, 2007 at 05:02:56PM +0900,
 Akira Kato <[email-masked]> wrote 

> Are you just saying that a phrase "silent truncation" is inadequate?

IMHO, yes, it is inadequate.

> TXT records are usually included in the answer section only. Is
> there any exceptional case? If a TXT RRset is bigger than the
> available space, the TC bit set. So the situation is different from
> the referral case.

OK, I understand, thanks for the explanation. This may be worth of a
note in the RFC.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 21 Dec 2007 09:41:05 +0100

---

From: Florian Weimer <[email-masked]>
Date: Fri, 21 Dec 2007 16:20:10 +0100

> DNS). What is the opinion of the WG? Am I the only one complaining

I'm not concerned so much by the choice of name, but I'm not sure if
those delicate rules actually buy us anything.  I'm not sure if this
applies to name servers and their use of glue records, but I've helped
to track down one bug in an MTA which assumed that once there were A or
AAAA records in the additional section, the additional section contained
complete RRSETs.  As a result, it did not issue another round of queries
for A or AAAA RRSETs at those names.  This turned out to be a mistake
because AAAA and A RRSETs can have different TTLs, and expire at a
different time.  The bug was that the MTA saw the AAAA records, didn't
issue an A query, couldn't deliver mail to the IPv6 addresses, and
bounced messages as a result.  The lesson I took from this is that the
shape of the additional section doesn't tell you much about what records
and record sets are actually available.

Perhaps the situation with glue records and referrals is different.  But
I also expect that caching resolvers will gradually shift to agressive
validation of glue records against more authoritative data, to get more
consistent behavior (independent of what queries have previously been
processed by a particular resolver).  This would make efforts to reduce
query load by carefully populating referral responses rather pointless.

---

From: Florian Weimer <[email-masked]>
Date: Fri, 21 Dec 2007 16:20:10 +0100