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

From: [email-masked]
Date: Mon, 31 Jul 2006 15:50:01 -0400

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-04.txt
	Pages		: 12
	Date		: 2006-7-31
	
With a mandated default minimum maximum 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-04.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-04.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-04.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.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Aug 2006 11:31:11 +1000

Section 2.  Delegation Details

	The answer section may contain a optional CNAME/DNAME chain.

	2.2

	TC is set if the answer and authority sections exceed the
	message size less the reserved space for TSIG and / or EDNS 
	responses. 

	2.6.

	The presentation length can be up to 1004 (250*4+4) characters
	as there are minimum of 5 labels in a maximum length domain
	name. This leaves 250 non label start octets which each can
	take 4 presentation character (\DDD), 3 inter-label periods
	and a optional final period to distingish between relative
	and absolute names.

	The network length maximum is 255 not 256.

	The worst case question section is 259 octets.

	2.11

	A NS RR adds at 12 octets (name(2), type, class, ttl, rdlen)
	+ NSDNAME (minimum 2, max 255).  Assuming in zone nameservers
	the that do not match the zone's name you get 16 for [a-z].<zone>.

	2.14

	First should be all glue which matches the <QNAME,QTYPE>.
	TC should be signaled if this can't be added.

	This allows a resolver to query for missing glue from a 
	previous referral and get it by forcing a TCP query.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
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: Wed, 2 Aug 2006 08:34:57 +0300 (EEST)

> 	previous referral and get it by forcing a TCP query.

In this context, it might be good to take a reminder look at Appendix 
B of RFC 4472, which discusses additional data, what should be 
included and what not, and what actually happens with implementations 
in some length.

-- 
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: Mark Andrews <[email-masked]>
Date: Wed, 02 Aug 2006 16:30:37 +1000

> included and what not, and what actually happens with implementations 

	The fallacy there is the assumption that you can work out
	what is curtesy glue.  The is a lot of glue that would be
	described as curtesy glue is in reality critical glue.

---

From: Kenji Rikitake <[email-masked]>
Date: Wed, 2 Aug 2006 22:52:52 +0900

> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-04.txt

Section 2 is named as "Delegation Details".  After reading the
subsections, I was confused what the entire section actually describes
what kind of details.  Does it describe a set of conclusions from an
operational experience, or suggest a set of actions for an implementer?
I think the purpose of this section should be explicitly written before
the subsections begin as an introductory subsection.

On Subsection 2.10, I find an idiomatic expression "by reflex."  I
didn't immediately understand what this meant; this could be rewritten
as "many requestors(sic) will retry using TCP immediately."

// Kenji Rikitake
.