Subject: draft-ietf-dnsext-rfc2672bis-dname-11 -- fate of 2672 ??

From: Alfred Hönes <[email-masked]>
Date: Thu, 27 Mar 2008 20:59:37 +0100 (MEZ)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hello all,

After reconsidering the latest revision of the DNAME-bis draft,
I wanted to figure out the real fate of RFC 2672.

Currently, the front matter of I-D.dnsext-rfc2672bis-dname-11 says:
  Updates: 2672,...

This means, anybody interested in DNAME has to consult RFC 2672
and the new RFC (once published), and hence has to find out
which parts of RFC 2672 have been revised by 2672bis and which
are still valid.

I tried, based on the current draft, and I lamentably failed,
caught in a tangling web of text.
Apparently, almost all significant parts of RFC 2672 are
revised or effectively superseded by text somewhere in 2672bis.

This is a very confusing scenario.

To avoid sustained confusion and endless discussions on the proper
exegesis of both documents, IMO the only clean and clear solution
will be to formally obsolete RFC 2672 by 2672bis.

According to my attempt to figure out the 'surviving' text in
RFC 2672, it looks like only section 2.1 of 2672bis should be
slightly amended to give a complete description of the 'static'
aspects of the DNAME RR.  All 'dynamic' aspects, processing
rules, etc., apparently already are fully covered by 2672bis.

To the contrary, obsoleting RFC 2672 will allow to simplify
some parts of the text, e.g. dropping Section 2.6 entirely.
(I leave it as an exercise to pick up further redundant text.)
Finally, as a subsidiary measure, the IANA Considerations have
to be adapted slightly as well.

So what's to do?

(1)  Change the front matter

  Updates: 2672,3363,4294 (if approved)
---
  Obsoletes: 2672    (if approved)
  Updates: 3363,4294 (if approved)

(2)  Update Section 2.1

  For details, see below.

(3)  Delete Section 2.5

(4)  Adjust Section 6

  For details, see below.

==== Details for step (2) ====

I have tried to compile a slightly revised version of Section 2.1
for inclusion into 2672bis, accommodating all the wisdom accrued
in my lazy brain on required precision in terminology and
possible pitfalls -- but this is probably condemned to
incompleteness.  As such, everybody is invited to add more
content and precision if deemed necessary.

For quick reference, here's the current Section 2.1 of 2672bis:

---- snip ----

2.  The DNAME Resource Record

2.1.  Format

   The DNAME RR has mnemonic DNAME and type code 39 (decimal).

   The format of the DNAME record has not changed from the original
   specification in RFC 2672.  DNAME has the following format:

           <owner> <ttl> <class> DNAME <target>

   The format is not class-sensitive.  All fields are required.  The
   RDATA field target is a domain name.  The RDATA field target name
   MUST be sent uncompressed [RFC3597].

   The DNAME RR causes type NS additional section processing.

---- snip ----

Below I present two variants for the proposed revision of this text,
after first giving the detailed considerations that lead these
proposals.

Since the 'core' specification of a RR type has to include hints
to required processing by authoritative servers, the final sentence
above is present and should be retained.  Nevertheless, it does not
fit properly under the headline "Format".  This text also has to be
amended by more clauses defining the basic properties of the DNAME
RR, which have been adapted from RFC 2672.  Therefore, I propose to
change the headline to "Basic Specification".

The first and last (single-line) paragraph above are left unchanged.

To allow obsoleting RFC 2672, the (potentially normative) reference
to the predecessor has been elided.

The terminological distinction between presentation format and
binary (on-the-wire) format of the RR has been emphasized.

To my knowledge, the owner field of all DNS RRs is covered by the
general rules for DNS labels and their concatenation (RFC 1034/1035
plus updates).  The current draft text seems to be too much focussed
on the 'standard' label format.  To allow for future extensibility
(binary / extended label types, etc.) and avoid possible normative
text clashes, I suggest to avoid restating too much details already
normatively specified in other documents.

Nevertheless, I offer two variants to choose from, depending on
the weight given to this 'avoid restatement' argument:
-  The long form specifies the whole RR, and inevitably contains
   significant repetitions from other RFCs.
-  The short form restricts itself to only defining the type code
   and mnemonic, and the RDATA portion of the DNAME RR, the only
   parts left unspecified by existing standards.

---- snip (begin long form) ----

2.  The DNAME Resource Record

2.1.  Basic Specification

   The DNAME RR has mnemonic DNAME and type code 39 (decimal).
   It is not class-sensitive.

   The presentation format of the DNAME resource record is:

           <owner> <ttl> <class> DNAME <target>

   This format follows the general rules of Sections 3.6 and 3.6.1 of
   RFC 1034 [RFC1034]; in particular:
   - all fields are required, unless <owner>, <ttl>, and <class> can be
     implicitely derived in the context of a zone file, according to the
     rules in RFC 1034;
   - the owner name is formatted following the standard rules,
     which imply case-insensitivity for 'text' format labels;
   - the class and RR type mnemonics are case-sensitive.

   The only RDATA field <target> is a fully qualified domain name, and
   its presentation also follows the applicable standard rules for
   domain names [RFC1034] [RFC1035] [RFC4343].

   The binary (on-the-wire) format of the DNAME RR follows Section 3.2.1
   of RFC 1035 [RFC1035].  The RDATA field MUST contain the target name
   in uncompressed form [RFC3597].

   The effect of the DNAME RR is the substitution of the record's
   <target> for its owner name, as a suffix of a domain name.
   This substitution has to be applied for every DNAME RR found in the
   resolution process, which allows fairly lenghty valid chains of DNAME
   RRs.

   Details of the substitution process, methods to avoid conflicting
   resource records, and rules for specific corner cases are given in
   the following subsections.

   The DNAME RR causes type NS additional section processing.

---- snip (end long form) ----

---- snip (begin short form) ----

2.  The DNAME Resource Record

2.1.  Basic Specification

   The DNAME RR has mnemonic DNAME and type code 39 (decimal).
   It is not class-sensitive.

   Its RDATA is comprised of a single field, <target>, which contains a
   fully qualified domain name that must be sent in uncompressed form
   [RFC1035], [RFC3597].  The presentation format of <target> is that of
   a domain name [RFC1034].

   The effect of the DNAME RR is the substitution of the record's
   <target> for its owner name, as a suffix of a domain name.
   This substitution has to be applied for every DNAME RR found in the
   resolution process, which allows fairly lenghty valid chains of DNAME
   RRs.

   Details of the substitution process, methods to avoid conflicting
   resource records, and rules for specific corner cases are given in
   the following subsections.

   The DNAME RR causes type NS additional section processing.

---- snip (end short form) ----

==== Details for step (4) ====

I suggest the following change to the first paragraph of the
IANA Considerations (Section 6):

   The main purpose of this draft is to discuss issues related to the
   use of DNAME RRs in a DNS zone.  The original document registered the
   DNAME Resource Record type code 39 (decimal).  IANA should update the
   DNS resource record registry by adding a pointer to this document for
   RR type 39.
---
   The DNAME Resource Record type code 39 (decimal) originally has been
   registered by [RFC2672].  IANA should update the DNS resource record
   registry to point to this document for RR type 39.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

Spam detection software, running on the system "mail.ogud.com", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
The administrator of that system for details.

Content preview:  [ Moderators note: Post was moderated, either because it was
   posted by a non-subscriber, or because it was over 20K. With the massive
  amount of spam, it is easy to miss and therefore delete relevant posts by
  non-subscribers. Please fix your subscription addresses. ] [...] 

Content analysis details:   (3.0 points, 4.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 3.4 HEADER_SPAM            Bulk email fingerprint (header-based) found
 3.2 CHARSET_FARAWAY_HEADER A foreign language charset used in headers
-2.3 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
                            [score: 0.0000]
 0.1 RDNS_NONE              Delivered to trusted network by a host with no rDNS
-1.4 AWL                    AWL: From: address is in the auto white-list