Subject: I-D Action:draft-ietf-dnsext-dns-protocol-profile-00.txt

From: [email-masked]
Date: Thu, 10 Jan 2008 23:00:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : The Modern DNS Implementation Guide
	Author(s)       : G. Michaelson
	Filename        : draft-ietf-dnsext-dns-protocol-profile-00.txt
	Pages           : 24
	Date            : 2008-01-10

A structured catalogue of relevant DNS RFCs is presented with
references to the specific normative sections which should be
followed in a modern DNS implementation.  This document is to be used
as guide for DNS implementors, for testing and compliance of DNS-
functioning software, and to help guide DNS standards advancement.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-protocol-profile-00.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-dnsext-dns-protocol-profile-00.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-dnsext-dns-protocol-profile-00.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: Fri, 11 Jan 2008 16:20:22 +1100

{new normative language, maybe.. } The server MAY accept TCP
   connections. {? what is the correct wording and reference?}

	This was written prior to UPDATE.  UPDATE works much better
	with TCP.

   6.  There MUST be no data below CNAME, and only DNSSEC records with
       CNAME.  [RFC 4034] [RFC 4035]

	Normally "above" and "below" apply to namespace.

   When processing the additional section priority is as specified in
   [RFC 2874 (4)]
   o  A
   o  AAAA

	If any additional data matches the QUERY it should be first.
	Queries for glue at the parent result in referrals so to
	ensure the client gets the glue it needs to be sorted first.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Florian Weimer <[email-masked]>
Date: Fri, 11 Jan 2008 12:04:50 +0100

> 	This was written prior to UPDATE.  UPDATE works much better

UPDATE is usually not performed across the Internet, so I'm not sure how
relevant it is for interoperability on the grand scale of things.

The current TCP behavior is specified by RFC 1123, section 6.1.3.2.
(This also means that section 4.2.1 in the draft is slightly incorrect.)

---

From: Chris Thompson <[email-masked]>
Date: Fri, 11 Jan 2008 11:35:55 +0000 (GMT)

[email-masked] (Florian Weimer) writes:

> UPDATE is usually not performed across the Internet,

Maybe you are using some particular notion of "across the Internet" here
(as in "from topologically distant hosts"), but otherwise it seems a rather
strange remark.

All our zone changes (well, OK, *nearly* all if you insist on 100%
accuracy) are made via UPDATE, and not from the host on which the
master nameserver runs. And we aren't even using DHCP (in that context)...

>                                                      so I'm not sure how

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Jan 2008 23:26:19 +1100

> relevant it is for interoperability on the grand scale of things.

	UPDATE clients are written by different vendors to those
	that write nameservers.  The clients and servers need to
	interoperate.  It doesn't matter if its just across the
	LAN or across the world.

	UPDATE was actually written with the idea that roaming
	machines would update their address whenever they reconnected
	to the net.  We hadn't worked out how to authenticate that
	update but that didn't stop us designing for that senario.

> (This also means that section 4.2.1 in the draft is slightly incorrect.)

	Remember when RFC 1123 there were lots of nameservers that
	didn't use non-blocking connects, etc.  nameserver listened
	on 0.0.0.0:53.

	We have much improved IP stacks since RFC 1123 was written.
	We have also learned to use the features of those stacks.

	Mark