Subject: Re: version -01 of draft-ietf-dnsext-dns-protocol-profile sent

From: Matthijs Mekking <[email-masked]>
Date: Tue, 04 Mar 2008 14:13:10 +0100

Hi,

I recently read this draft and I was 'suprised' by the structure.
I was expecting a list of DNS references and how they relate to each
other,
but when I start reading I saw some common requirements, requirements
for authoritative servers, stub resolvers, recursive resolvers, middle
boxes and per category some extra information about zone contents,
zone synchronization, message processing, further query processing,
some extra information about the additional section, label
compression, truncations, then NSEC is mentioned, some info about NSID...

My point is: I was way lost in how all these documents and
requirements was related.
So I guess what I was expecting was something like:

    1. Introduction
         ...
    2. Fundamental requirements
         The basic DNS implementation and specification is described in:
         - RFC 1035.
         Implementations MUST follow the specification in this document.
         Background information can be found in:
         - RFC 1034: Domain names: concepts and facilities
         - ...
    3. Extensional requirements
         For modern DNS implementations the following extensions MUST
be implemented:
         - RFC 2671: EDNS0
         - RFC 4035: DNS Security Extensions
         ...
         For modern DNS implementations the following extensions
SHOULD be implemented:
         ...
    4. Resource Records
         A modern DNS implementation MUST handle the following RRtypes
correctly:
         - from RFC 1035: A, NS, MX, ...
         - from ...
    5. Zone files
         ...

Well, after this rather elaborating example, I should ask: do you
agree? If not, I would like to
suggest that in the introduction you describe how this document is
structured, to give the reader
some guidance. Otherwise, maybe a restructuring of the document should
be considered.

I have some other comments too:

- - What is the definition of modern DNS implementation? This
information is not included in the draft.

- - page 5: EDNS0 MUST be implemented by all DNS systems. --> all modern
DNS systems

- - in 4.5 Additional Data processing
   >> Additional data may be added as long as there is space in the
packet. {need reference}
The reference is in RFC 1035 (section 4.1):
   >> the additional records section contains RRs which relate to the
query, but are not strictly answers
   >> for the question.
RFC 1035 also has many information about which RRs causes additional
section processing.

- - However, there are limits to this: RFC 4035 (section 3.1.2, page 11)
states:
   >> The name server SHOULD NOT include the DNSKEY RRset unless there
is enough space in the response
   >> message for both the DNSKEY RRset and its associated RRSIG RR(s).
I suggest the following text to be added, (but actually I think this
is too much detail, and should not
be in this draft at all):
   Exceptions:
   * RFC 4035 (section 3.1.2, page 11)
   * ...
   (I don't know if there are more limitations to adding additional
data that should be noted?)

To summarize: I would like to see a different structure for this
draft, and that it sums the necessary RFCs
for the "modern" DNS implementation, and how these RFCs relate.
Otherwise, consider

Regards,

Matthijs Mekking
NLnet Labs

--
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: George Michaelson <[email-masked]>
Date: Thu, 6 Mar 2008 13:02:41 +1000

Thanks for your comments Matthijs.

The structure of the document was chosen as a guide to implementors/ 
testers/purchasors, following RFC4035. Its aimed at giving them the  
information that relates to the architecture they are interested in.

Its not a general DNS reading list, but a requirements document.

I will certainly try to improve the introductory text(s) to make it  
clearer, and if you have any suggested wordings I'd welcome them!

-George

On 04/03/2008, at 11:13 PM, Matthijs Mekking wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHzUrmIXqNzxRs6egRAvH1AKCAvT2mVSqH4HoNHhV+sDRQgHT4UwCghQub
> AQYHxC1ib/ytfTbBvMzY9I0=
> =fco6
> -----END PGP SIGNATURE-----
>
>
> --