initial thoughts on draft-ietf-dnsext-dns-protocol-profile-00

[Joe Abley <[e-mail]>]

Some initial comments follow. I have not done much thinking, but  
perhaps some of my crude scrawl will trigger comments from those  
brains are performing more adequately on this particular Friday.

Many of these are knee-jerk editorial objections, which you should  
feel free to scoff at. I appreciate that many of these sections  
contain notes rather than polished text in this revision.

> Abstract
>
>    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.

editorial: s/-functioning//

editorial: s/standards advancement/standards' advancement/

> 1.  Introduction
>
>    The DNS is almost 25 years old. In that time a significant amount  
> of

editorial: Since this document presumably aims to remain relevant for  
a long time, the comment on the age of the document ought to be  
relative to something (e.g. to the time of writing).

>    change has occurred in the collection of RFCs which document how  
> DNS
>    systems should be implemented and operated.
>    o  Developers of DNS systems need a single reference which can be
>       used consistently to review interoperability between
>       implementations and to guide implementation of DNS systems.
>    o  Operators of DNS systems need a reference which can be used to
>       understand existing DNS systems conformance and to guide
>       acquisition and management of new DNS systems.
>
>    Accordingly, the DNSEXT working group has been asked by the RAI ADs
>    and others to document what the basic requirements for 'modern' DNS
>    implementations are.

editorial: Working groups come and go; organisational structures  
change. DNSEXT, RAI and possibly even ADs ought to be expanded upon  
first use. If we're being consistent, DNS ought to be expanded  
somewhere early in this document.

>    By reviewing the normative sections of the 'head' documents (ie the

editorial: s/ie/i.e./

>    documents which are current, have not been superseded by a -bis  
> or a
>    different document,

editorial: s/by a -bis or a different/another/

>                        explicitly deprecated or fallen into disrepair)
>    the DNSEXT working group identified the set of references into  
> those
>    documents which specify all of the 'directives' which define how  
> the
>    'modern' DNS system should work.
>
>    In the process of review, areas of attention were identified.   
> These
>    represent normative directing text(s) in the RFCs, or the entire  
> RFCs
>    themselves, which required change, to reflect the current state of
>    the DNS.
>
>    During this documents development, areas of standardization which

editorial: s/standardization/standardisation/ (assuming I'm right from  
other text that the document editor aims to use English, and not US  
spelling)

>    required attention were noted, and were addressed in one of the
>    following four ways.
>    o  Firstly, if the revisions were simple enough, a -bis process was
>       used to define the smallest set of changes to the RFC, and a new
>       version rolled, with the old one deprecated.

The use of "bis" and "ter" to name successors to existing documents is  
common in many technical fields, following from the Latin bis  
("twice") and ter ("three times"). It's not immediately clear that the  
phrase "-bis process" has a commonly-understood meaning. If the aim of  
this text is to provide clarity, then I think a little more  
explanation is in order.

If what is meant is "the document text was lightly edited in order to  
achieve the desired changes, and the resulting document was published  
as a complete replacement for the original" then I think spelling it  
out would be clearer.

> 2.  General Considerations
>
>    {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.

s/fully compliant to/fully compliant with/

Given that this document catalogues many RFSs which are not really  
pertinent to anything any more, I wonder what "fully-compliant to DNS  
RFCs and STDs" means. Perhaps "... to be considered fully standards- 
compliant." is better?

>    {not normative} Because important DNS RFCs pre-date RFC 2119 this
>    document explicitly shows where their text is to be re- 
> interpreted in
>    line with RFC2119 normative language
>
>    The document is organized into five major sections, addressing  
> Common
>    Requirements, Authoritative Servers, Stub Resolvers, Recursive
>    Resolvers and Middle-boxes.  DNS Implementors should read all
>    sections carefully since subsequent sections refer back to prior
>    sections and catalog variances as well as new requirements.
>
>    Application specific considerations are not normatively addressed  
> by
>    this document.  Where mentioned, the text should be considered
>    guidance only.

s/considered guidance/interpreted as guidance/

> 3.  Common Requirements
>
>    {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.

There's a replacement for 1996?

>    {new normative language} Unknown RRtypes MUST be preserved.  This  
> is
>    in line with [RFC 3597]

I think this needs expansion. Preserved in what way?

>    {new normative language} The DNS Database consistency MUST be
>    maintained.  Data MUST NOT leak between zones.  [RFC 1997]

I think this also needs expansion. Consistency in what sense?

>    {non normative} The following documents define registries of DNS RR
>    types.  All new record types can be treated as unknown RRs as  
> above.
>    {list of RR-types refs.  Just the IANA registry, rather than all  
> RFCs
>    has been suggested by Olafur}
>
>    {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)]

editorial: s/if/of/
editorial: s/dns/DNS/
editorial: s/case insensitive/case-insensitive/

> 4.  Authoritative Servers
>
>    {Much of this text comes from [NLNet-1].  These requirements are in
>    order of importance: }
>
> 4.1.  Zones
>
> 4.1.1.  Zone Contents
>
>    {non normative} The zone file format as specified in [RFC 1035  
> (5.1)]
>    is optional.  It is used as a common presentation format only.
>
>    {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.
>
>    Zones MUST follow the rules as defined in [RFC 1035 (5.2)] and
>    subsequent revisions by the following RFCs:
>       [RFC 1101]
>       [RFC 1122]
>       [RFC 1183]
>       [RFC 1706]
>       [RFC 1876]
>       [RFC 1982]
>       [RFC 1995]
>       [RFC 1996]
>       [RFC 2136]
>       [RFC 2137]
>       [RFC 2181]
>       [RFC 2308]
>       [RFC 2535] {this needs to be reviewed, and probably updated to a
>       new RFC}
>       [RFC 2782]
>       [RFC 2845]
>       [RFC 3425]
>       [RFC 3658]
>       [RFC 4034]
>       [RFC 4035]
>
>    from [RFC 1035 (section 5.2)] and [RFC 2181 (section 5.2)] the
>    following text has been extracted, and re-written in line with RFC
>    2119 normative language.

This paragraph (above) would be clearer if re-cast in the form "The  
following text has been extracted from [RFC 1035 (section 5.2)] and  
[RFC 2181 (section 5.2)] and re-written using normative language  
specified in [RFC 2119]."

>    [RFC 1035 (Section 5.2)] Rules governing zone content
>
>    {new normative text}
>    1.  All RRs in the file MUST have the same class.  [RFC 1035  
> (Section
>        5.2 rule 1)]

If support of a "zone file" is optional, I think s/file/zone/ above?

> 4.1.2.  Zone synchronization

editorial: s/synchronization/synchronisation/ (see earler re.  
spelling). "Replication" might be a better word.

This section presumably should say something about whether the use of  
zone transfers is mandatory.

It might also express an opinion about whether using REFRESH, RETRY,  
EXPIRE or MINIMUM timers in a zone's SOA RDATA is mandatory, when  
using AXFR/IXFR as the replication mechanism or when using some other  
mechanism.

Is it required for servers which support AXFR/IXFR also to support  
NOTIFY?

> 4.1.2.1.  Timeout management
>
>    {referencing RFC details needed} Timeouts on the SOAs for secondary
>    zones according to [RFC...].

"secondary zone" is a clumsy phrase. I realise this is just a  
placeholder, however. :-)

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

I think that MAY should be a MUST.

If it's really to be a MAY, then there ought to be some restrictions  
placed on the data that can be served, and the use of the TC bit in  
responses.

>    Note that there may be one or more DNS messages in the stream.   
> Each
>    message is prepended with a 2 byte size servers follow [RFC 1035
>    (4.2.2)]

The text in RFC 1035 is much clearer:

"[Each] message is prefixed with a two byte length field which gives  
the message length, excluding the two byte length field."

> 4.2.3.  TCP Connection Management
>
>    from [RFC 1035 (section 4.2.2)] the following text has been
>    extracted, and re-written in line with RFC2119 normative language.
>
>    [RFC 1035 (4.2.2.)]  TCP Usage
>
>    {new normative text}
>
>    o  the server SHOULD not block other activities waiting for TCP  
> data
>    o  The server SHOULD assume that the client will initiate  
> connection
>       closing and SHOULD delay closing its end of the connection until
>       all outstanding client requests have been satisfied.
>    o  { this is 25 year old advice. is this still relevant or what
>       should it be? } For closing dormant connections the timeout  
> should
>       be in the order of 2 minutes.

Two minutes sounds like a very long time to me.

The goal of the timeout text is presumably to avoid having to incur  
the TCP setup handshake overhead unnecessarily. I can't think of an  
obvious heuristic which would lead me to a definitive, correct timeout  
based on this vague goal, but it does seem to me that on a busy server  
the implications of keeping all TCP sessions open on the server for  
two minutes has poor scaling properties.

> 4.3.  DNS Message processing
>
>    DNS messages should be processed in line with the precepts of [RFC
>    1034 (Section 4.3.1)]
>
>    { new normative language. there is no explicit reference in  
> existing
>    RFCs to the following} Non parsable messages SHOULD be replied to
>    with a FORMERR.
>
>    Each UDP packet only carries one DNS Message.  Any data behind the
>    DNS message SHOULD be considered garbage and SHOULD be ignored.
>    {better text requested}

"When UDP transport is used, each UDP datagram MUST contain exactly  
one DNS Message. UDP datagrams SHOULD be constructed such that they  
contain no data following the DNS Message. If present, any additional  
data present following the DNS Message MUST be ignored."

>    o  Incoming DNS messages with the QR bit set to 1 (response) are
>       discarded.  [RFC 1035 (sect 7.3)]

Clearly this is the desired behaviour for a DNS server. It's not  
desired behaviour for a DNS client, however. Since the document  
appears to be talking generally about "DNS Systems", I think some  
further categorisation would be beneficial, here. Perhaps it just  
needs to be made more clear that this section concerns itself with the  
processing of DNS messages which are received, rather than those which  
are being processed in any other way (e.g. before sending).

>    o  RD is copied into the response [RFC 1035 (4.1.1)] the RA bit is
>       set to 0 and the QUERYID is copied into the response message as
>       follows:
>       *  OPCODE 0 (QUERY) MUST be supported [RFC 1035]
>       *  OPCODE 1 (IQUERY) MUST result in RCODE=4 NOTIMPL [RFC 3425]
>          {has this actually been deprecated?}
>       *  OPCODE 2 (STATUS) MUST result in RCODE=4 NOTIMPL [RFC 1035]
>          {new normative language, not explicitly brought out}
>       *  OPCODE 3 (RESERVED) MUST result in RCODE=4 NOTIMPL  
> {requires an
>          RFC reference}
>       *  {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)]
>    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.
>       *  RCODES SHOULD ignored.
>       *  QDCOUNT!=1 SHOULD result in RCODE=1 FORMERR

I'm interested in the basis on which decisions as to what is  
appropriate in the four lines above might be arrived at. Should we  
review a survey of existing implementations, or check representative  
resolvers and authoritative-only servers to see whether clients are,  
in fact, sending queries formed with these errors, or something else?

>    o  Presence of OPT RR indicates support of EDNS [RFC 2671].  If the
>       VERSION > 0 then the server will respond with an OPT with
>       RCODE=BADVERSION and VERSION=0 (The server supports EDNS0) In
>       further processing ENDS0 support is taken into account.

Presence of the OPT RR in the ADDITIONAL section, right? Not  
specifying the section seems like the wrong thing. A reference to RFC  
2671 (or -bis) seems to be missing.

> 4.4.  Further Query processing
>
> 4.4.1.  Actions based on QTYPE of incoming Query
>
>    Further processing of the packet is based on the algorithm from  
> [RFC
>    1034] as modified by [RFC 2672 (4)].
>
>    DNSSEC Considerations follow [RFC 4035]

editorial: missing ".".

> 4.5.  Additional Data processing
>
>    Additional data is added as long as there is space in the packet.
>    {need reference}

"space" is vague. "... data MAY be added" seems more helpful.

>    When processing the additional section priority is as specified in
>    [RFC 2874 (4)]
>    o  A
>    o  AAAA
>
>    For truncation see section [Truncation handling]
>
> 4.6.  Label compression in RDATA
>
>    [RFC 1035 (section 3.3. and 4.4.1)] ("Pointers can only be used for
>    occurrences of a domain name where the format is not class
>    specific.")
>
>    Do label compression for labels in rdata for which this is
>    specifically mentioned in the RFC defining the RR.
>    o  NS, SOA, CNAME, and PTR [RFC 1035 (3.3)]
>    o  Others defined in [RFC 1035 (3.3)]are not compressed.
>    o  MB, MG, MR, MINFO, MX also have compressed dnames.  These RRs  
> and
>       their compression are described in [RFC 1035].
>    o  AFSDB, RP, RT [RFC 1183, (Section 1,2 & 3.3.3)]
>    o  You MUST follow the rules in [RFC 3597].
>
>
>
>
>
>
> Michaelson                Expires July 13, 2008                  
> [Page 9]
> Internet-Draft     The Modern DNS Implementation Guide      January  
> 2008
>
>
> 4.7.  Truncation handling
>
>    Truncation handling is as specified in [RFC 2181 (9)]
>
>    {TBD normative text for this section.  RFC references required.} If
>    inclusion of a RR set that is REQUIRED in either the answer or
>    authority section leads to message truncation.  The section is left
>    empty and the truncation (TC) bit is set.  If the DO bit is set  
> RRSIG
>    RRs are required in the answer and authority section.
>
>    If inclusion of an RRset in the Additional section is not possible
>    RRs are omitted one by one.  This may lead to incomplete RRsets.
>    Omission of RRs from the Additional section because of message size
>    constraints will NOT lead to setting of the TC bit.  [RFC 2181 (9)]
>
>    {RFC references required.} Implementations need to allow for
>    incomplete RRsets in the additional section.
>
> 4.8.  NSEC processing
>
>    {section reference required.} The NSEC record is required to be in
>    the authority section if a QNAME or a QTYPE cannot be matched [RFC
>    4035 (section ?)].
>
>    {this text needs to be moved out of authoritative servers.  Not  
> clear
>    which section its in yet.} Note that on a QNAME match the NS  
> records
>    are not copied into the AUTH section (This is a requirement from  
> step
>    4 'matching down the cache' from [RFC 1034 (Section 4.3.2)].   
> This is
>    a requirement only for caching servers.
>
> 9.  Acknowledgments
>
>    Much of the initial ideas, and structure of the text reflect ideas
>    taken from a design document developed by NLNet Labs, in the  
> process
>    of developing NSD.  This was written by Dr. Wouter C.A. Wijngaards
>    and Jaap Akkerhuis.  [NLNet-1].

editorial: s/Dr./Dr/ (unless the convention is to do otherwise in  
Dutch? In English the punctuation only appears if the abbreviation is  
terminated by a letter other than the one which terminates the  
expanded word.)

I didn't see a reference to RFC 5001 anywhere.


Joe

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