draft-iab-dns-choices-00 comments

[Pekka Savola <pekkas@netcore.fi>]

Hi,

The fight over draft-iab-dns-choices-00 appears to have settled down a 
bit.. I wonder how it's going forward.  In any case, below are the 
comments I sent in May but for which I didn't get a response to.

In summary, I think the document should be either more focused (be 
more clear from the start, title, etc. that it's only interested in 
storing arbitrary data in the DNS) or more generic (data storage and 
record discovery).  Currently it seems to be including a bit of both, 
but not doing a sufficiently complete job on both.

---------- Forwarded message ----------
Date: Thu, 20 May 2004 12:24:45 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Patrik Fältström <paf@cisco.com>
Cc: sra@isc.org
Subject: Re: I-D ACTION:draft-ymbk-dns-choices-00.txt

[...]

major issues
------------

 1) the existence of wildcards (or not) seems to be dominating at 
least some design choices [and being overly assumptive about being 
used in an MX environment].  It might make sense to discuss this in a 
more explicit manner.  For example, for certain kinds of applications, 
the usage of wildcards might not prevent specific kinds of approaches, 
or you might be able to just say "don't push if there's resistance".

 2) I think the document either needs to be more focused or needs more
text.  As it is, the doc seems mostly centered on applications wanting
to store all kinds of data (not facilitated by the existing records,
if not for TXT) in the DNS.  I see a couple of different aspects which
may result in a different kind of conclusions, at least:

  a) using DNS for service discovery, but so that the result of that
     discovery is properly defined DNS record or hostname.

  b) using DNS to store service/application-specific data, in a
     fashion that isn't easily facilitated with current records (e.g.,
     keying material, certificates, other kinds of data, etc.)

  c) something else?

These approaches have a number of common issues like "where in the
domain tree to put this data?", "who are the users of that data, and
how can they find it?", and "which records to use to store the data?"
-- but the answers to these questions, and others, might vary
depending on what you want to be doing.

more or less substantial
------------------------

    Even when a specific prefix is chosen, the data will still have to beM
    stored in some RR type.  This RR type can either be a "kitchen-sinkM
    record" or a new RR type.  This implies that some other mechanism hasM
    to be applied as well, with implications detailed in other parts ofM
    this note.M

==> For non native speakers, it may not be 100% certain what you refer 
to with a 'kitchen-sink record' maybe worth spelling out?

==> I couldn't find that "other part of this note".  Could you be more
specific in the reference and/or spell this out better?

(I think this is part of the distinction between "where to put the
data" and "how to encode the data" -- maybe 3.2 and 3.3 should go into
their own section, or the like?)

    Adding a new RR type is the technically correct answer from the DNSM
    protocol standpoint (more on this below), doing so requires some DNSM
    expertise, due to the issues listed in Section 3.5.  As a result,M
    this option is usually considered too hard.M

==> it might be worth pointing here to RFC2929 that some types require
IETF Consensus, but some only Specification Required.

4.  The case against protocol use of TXT RRs

==> this, again, is a case about using TXT RRs for _storing_
arbitrary data in the DNS, but doesn't address e.g., the service
discovery issues.  (Of course, you could try to do service discovery
by storing the parameters in appropriately located TXT records, but
that's probably not so interesting for anyone..)

   Using one of the naming modifications discussed in Section 3.2 andM
    Section 3.3 would address the subtyping problem, but each of theseM
    approaches brings in new problems of its own.  The prefix approachM
    (such as SRV RRs use) does not work well with wildcards, which is aM
    particular problem for mail-related applications, since MX RRs areM
    probably the most common use of DNS wildcards.

==> again, here, IMHO at least in most cases the answer could be like,
"if it hurts, don't do it" (meaning either the application, or the use
of wildcards).  As long as the application designers are aware how
wildcards operate and how they are (or not) deployed, using a
mechanism which might not work 100% with wildcards might be entirely

editorial
---------

    application.  DNS extension discussion too often circulate aroundM
    reuse of the TXT record.  This document lists different mechanisms toM

==> s/circulate/circulates/ ?

   accomplish the extension to DNS, and comes to the conclusion use of aM
    new RR Type is the best solution.M

==> s/use/that the use/

    Historically, extension of DNS to store data for applications tied toM
    a domain name has been done in different ways at different times.  MXM

==> s/extension of/extending/ (sounds better)

   Adding a new RR type is the technically correct answer from the DNSM
    protocol standpoint (more on this below), doing so requires some DNSM
    expertise, due to the issues listed in Section 3.5.  As a result,M

==> s/doing/but doing/

    lack of defined semantics becomes a problem, because there is nothingM
    to prevent collisions some other incompatible use of TXT RRs.

==> s/collisions/collisions with/ ?

8  ReferencesM

==> split to norm/informative refs, please

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings