Subject: draft-ietf-dnsext-dns-protocol-profile-00

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 16 Jan 2008 11:00:51 +0100

Hi,

Some comments on the draft.

~   Therefore, this document should be actively maintained, and updated
~   to reflect changes in DNS standardization.
Suggest
this document should be updated when a significant body of new DNS
developments have occurred.

~   {new normative language} This document catalogs the compliance issues
~   for an implementation of any component of the DNS.  Implementors MUST
~   adhere to the collected state of these directives to be considered
~   fully compliant to DNS RFCs and STDs.
I suggest the text
Implementors MUST adhere to the collected state of these directives to
be considered standards compliant to DNS RFCs and STDs as listed in
RFC####(this RFC).
especially the last words, conforming to this RFC makes you, well,
this-RFC### conformant.

~   {new normative language. the -bis document needs its reference
~   confirmed.} EDNS0 MUST be implemented by all DNS systems.  Its use is
~   an operational decision.  This is is line with [RFC 1996] and its
~   -bis document.
The RFC1996 is about NOTIFY. Does not mention EDNS0. Mistaken.

~   {new normative language} The DNS Database consistency MUST be
~   maintained.  Data MUST NOT leak between zones.  [RFC 1997]
The RFC1997 is about BGP. What is this DNS Database, and what is this
consistency between zones? Maybe I'd better implement BGP :-) (I mean,
this is confusing).

~   {new normative language} Processing if dns names in US-ASCII range
~   MUST be case insensitive.  [RFC 1035 (2.3.3)] also see [RFC 1034
~   (3.1)]
Oh and you can refer to RFC4343, this isn't referenced yet in the document.

About 4.1.1 zone contents.
How about splitting this section up.
* Zone file format. And its support.
* Zone contents. Checking of.
* supported RR types (not only in the context of a 'zone file').

The zone file format section should also not the $BLA directives to
support. $TTL and $ORIGIN are a MUST.

~   {new normative language: needs RFC reference} A served zone SHOULD
~   not contain errors, or produce unpredictable results when RRs that
~   are obsolete, or not implemented are encountered.
First, let's split this into two parts; no errors and old-RRs.

* a served zone SHOULD not have errors.
Does this mean that an authoritative server (even a secondary) has to
perform zone-checking? Does this mean checking the output of the zone
signer? Or only CNAME rules? Checking signatures? These checks can
become very cumbersome.
Suggest. The operator should not load zones with errors. Or change so
that only the primary server does the checking. Or change so that the
zone-signer does checking of its work.
There also exist human errors, I mean, the address in an A record could
be wrong because a server has moved. This is not what you mean here.
It is evident I do not like this as written, I do support some limited
checks on zone content, more along the lines of syntax checks than
full-blown 'lint for DNS zones'.

* A served zone SHOULD produce unpredictable results when RRs that
~   are obsolete, or not implemented are encountered
You mean SHOULD NOT. Engineering software to be robust in the face of
unpredictable and unexpected inputs is a great thing, but I feel this is
the wrong place to discuss implementation engineering practice.
Suggest. Handle such RR types in a sane and reasonable manner. Possibly
falling back to treating as unknown RR types.

~   4.  The TTLs of all RRs in an RRSet MUST be the same. {RFC reference
~       required}
RFC 2181 section 5.2.

~   5.  You must adhere to [RFC 2672 (Section 3)] and {reference will
~       need updating to published RFC}
~       [I-D.ietf-dnsext-rfc2671bis-edns0] in respect of data below
~       DNAME.
Suggest. in respect of data conflicting with DNAME records.

~   6.  There MUST be no data below CNAME, and only DNSSEC records with
~       CNAME.  [RFC 4034] [RFC 4035]
Suggest, There MUST be no data at the same name as a CNAME, and only
DNSSEC records with a CNAME.

TCP
I suggest 'The server MAY NOT accept TCP'.
The closing dormant connection timeout is reasonable, and used in practice.

~      *  {new normative language} The following are optional but
~         recommended techologies, which SHOULD be handled gracefully,
~         rather than through use of NOTIMPL
~         +  OPCODE 4 (NOTIFY) SHOULD+ be supported [RFC 1995]
~         +  OPCODE 5 (UPDATE) SHOULD+ be supported [RFC 2136 (sect 3)]
Suggest, which SHOULD be implemented, instead of replied with NOTIMPL.
I consider a NOTIMPL reply perfectly fine in DNS protocol.

~   o  {no RFC/normatives found, need guidance}
~      *  AA bit in query packet SHOULD be ignored.
~      *  TC bit set in a query packet SHOULD+ be answered with FORMERR.
Guidance: In the spirit of lenient acceptance and strict sending for
network implementation (there is probably an RFC or BCP for that).
The TC bit answer FORMERR MUST not have the TC bit set.

5. Stub Resolvers
~   TBD
6. Recursive Resolvers
~   TBD
7. Middle-Boxes
~   TBD
Text is needed.
Add 8. Zone signers.

I think the document tends to get down into too many details, where it
is meant to be a dry list of READ RFC 1,2,3,4 ...
Discussing the bits, error codes and so on, and drilling down into 1034
sections can be useful, but should be done in -bis documents, or their
own guideline documents. Consider trimming section 4 in this draft to a
simpler list. Simply put 1034 in the list of MUST support RFCs. The lack
of normative language in the 1034 can require a 1034 update, but don't
do this in this draft. I do not think it is worth the effort to
normatize 1034 now.
It would be nice for the reader to refer to RFCs with a one-liner. You
MUST comply to rfc1995 which details incremental zone transfers. Note
well that such friendly text does not alter the RFC referenced. Possibly
put a couple (less than 5) bullet points summarizing the main issues
from that RFC.

Best regards,
~   Wouter

--
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/>