Subject: Re: [dnsext] WGLC Summary: Unknown RR's to Draft standard (rfc3597bis)

From: Alfred Hönes <[email-masked]>
Date: Mon, 5 Apr 2010 17:52:53 +0200 (MESZ)

At Mon, 29 Mar 2010 13:42:04 +0100, Dick Franks wrote:

> All,
>
> On 28 March 2010 03:00, Olafur Gudmundsson <[email-masked]> wrote:
>
>> - Whether to continue to allow compression of, and require support
>>   for decompression of, the obsolete and experimental RR types from
>>   RFC1035 (MD, MF, MB, MG, MR and MINFO), as discussed in
>>
>> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00551.html
>>
>
> Like it or not, these obsolete RR types are still part of RFC1035
> until formally expunged by standards action elsewhere. IMHO this seems
> out of scope  for RFC3597bis.
>
> ...

Well, 3597bis targets *Draft Standard*, and it is not uncommon for
*Proposed Standard* documents to Update a full Standard RFC.
(Otherwise, the Full Standards could essentially never been changed
because on the way from DS to FS, no significant technical changes
should be introduced, but this would be the only opportunity to
modify a FS under that premise.)

Note however that RFC 1035 *explicitly* (and repeatedly) states that
{MD, MF} are OBSOLETE and {MB, MG, MINFO, MR, NULL} are EXPERIMENTAL.
According to my understanding, this is not overridden by the FS status
of RFC 1035.  Thus these RR types are not under Full Standard status.
Furthermore, RFC 1123 (October 1999) said:

  !        Name servers MUST be able to load all RR types except MD and
  !        MF from configuration files.  The MD and MF types are
  !        obsolete and MUST NOT be implemented; in particular, name
  !        servers MUST NOT load these types from configuration files.
    [...]
  !        The RR types MB, MG, MR, NULL, MINFO and RP are
  !        considered experimental, and applications that use the
  !        DNS cannot expect these RR types to be supported by
  !        most domains.  Furthermore these types are subject to
  !        redefinition.

You had proposed the following text:

>    To avoid such corruption, servers MUST NOT compress domain names
>    embedded in the RDATA of types that are class-specific or not well-
>    known.  This requirement was stated in [RFC1123] without defining the
>|   term "well-known"; it is hereby specified that the RR types defined
>|   in [RFC1035] section 3.3 are the only types eligible for compression.

IMHO "the RR types defined in [RFC1035] section 3.3" could be read as a
(soft) requirement to support the legacy types listed in RFC 1035,
section 3.3, including the "MUST NOT implement" (RFC 1123) RR types
MD and MF.  Do we really want that?

Do we really need a specific document,
  "Section 8.2 of RFC 1035 is obsolete" (etc.) ?

If we adopt the above text, I suggest to amend it by:

|  Note however that, according to [RFC1123], the obsolete RR types from
|  section 3.3 of [RFC1035] (i.e., MD and MF) MUST NOT be implemented
|  and support of the experimental RR types from section 3.3 of
|  [RFC1035] (whereof MB, MG, MR, and MINFO carry domain names in their
|  RDATA) cannot be expected; thus, implementations still supporting
|  these RR types SHOULD NOT apply domain name compression for such RRs
|  any more because caches cannot be expected to support them and being
|  able to undo the compression.

This is a complicated, yet conservative rule.

But I'd actually prefer a simple and clean rule, dropping these RR types
and clearly stating the positive list of RR types for which compression
applies (CNAME, MX, NS, PTR, and SOA).

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]                     |
+------------------------+--------------------------------------------+