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

From: Alfred Hönes <[email-masked]>
Date: Mon, 1 Mar 2010 15:03:37 +0100 (MEZ)

First of all, I support going ahead with this document.

In previous messages exchanged after the posting of the current
draft version, but before WGLC had been announced, I had suggested
editorial improvements, in particular adding the definition of
"well-known" (or an indirect version of it) to the Terminology section.
Please take these suggestions as part of my WGLC comments.

The recent thread has caused me revisit the old standards again.

Andreas Gustafsson wrote:
> Dick Franks wrote:
>> Clarification needed at para 2 of section 4.
>>
>> |  4. Name Compression
>> |
>> |   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 only the RR types
>> |   defined in [RFC1035] are to be considered "well-known".
>>
>> Does this mean "all RR types defined in RFC1035", or the much smaller
>> list defined in RFC1035 3.3 para 1?
>
> The intended meaning is "all RR types defined in RFC1035".  I'm not
> convinced this actually needs clarification; the latter interpretation
> seems a bit far-fetched to me.  Besides, in the unlikely event that
> an implementer were to use the latter interpretation, the
> implementation would still interoperate correctly; the only practical
> consequence would be the loss of compression in the the MX RR, as all
> the other types not in the list are either class-specific, obsolete,
> experimental (and in practice obsolete), or lack embedded domain
> names.
>
>> Propose revised wording:
>>
>> ... hereby specified that all RR types defined in [RFC1035] are
>> eligible for compression.
>
> That wording would imply that even the class-specific types defined in
> RFC1035 are eligible for compression, which is incorrect.  Also, by
> dropping the word "only", it would weaken one of the main points of
> the document, namely that types not defined in RFC1035 MUST NOT be
> compressed.
> --
> Andreas Gustafsson, [email-masked]

All true.  However, wouldn't simply listing the few RR types covered
by the definition *explicitly* add a *lot* of clarity?

Given that  MD, MF, MB, MG, MR, MINFO are all obsolete (the first two
already were so per RFC 1035), the list of class-independent, standard
RR types from RFC 1035 that carry domain names in defined locations in
their RDATA  would simply amount to:
   SOA, NS, PTR, CNAME, MX.

(Arguably in doing so we would not even need the definition of
 "well-known" any more.  But we might perhaps better leave it
 in the memo for continuity from RFC 3597.)

Kind regards,
  Alfred.

P.S.:

There seems to be no "official" deprecation of the outdated experimental
RR types MB, MG, MR, and MINFO.   Should we do that in a suitable way?
RFC 5321 (Draft Standard) actually did the deprecation only implicitly
by not mentioning these RR types and normatively prescribing the use of
MX RRs for mail routing -- as did RFC 974 and RFC 2821 before.

RFC 1123, Section 6.1.3.6 said:

        DISCUSSION:
             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.
             ^^^^^^^^^^^^                               ^^^^^^^^^^

Also, with the phase-out of AFSDB RRs per draft-allbery-afs-srv-records
(accepted by IESG, Std Action now at the RFC Editor) it looks like
the experimental RR type definitions in RFC 1183 have reached their
end of live.

---

From: Andreas Gustafsson <[email-masked]>
Date: Tue, 2 Mar 2010 16:58:06 +0200

> by the definition *explicitly* add a *lot* of clarity?

Yes, it would, but... There is the potential problem that while
RFC1035 constitutes a shared point of reference that everyone can
easily agree on, a list of RR types does not have that property.
I fear that switching from a reference to RFC1035 to an explicit list
may lead not only to disagreement about what the list should contain,
but also to an open-ended debate about exactly how the obsolete and
experimental RR types in RFC1035 should be treated.  Since these
types currently have no practical use, their treatment is largely a
matter of taste, and achieving consensus on matters of taste is hard.

> their RDATA  would simply amount to:

If we do decide make it an explicit list, I agree that the above is
what it ought to contain.  But then we need to be clear that this is
not just a clarification of RFC3597 but a change (since compression of
MD, MF, MB, MG, MR and MINFO is currently allowed).  Also, we then
need to decide whether a server that receives RRs of those types MUST
NOT, SHOULD NOT, MAY, SHOULD, or MUST decompress them.

The MD and MF types have the additional problem that specifying any
server behavior at all might be seen as conflicting with RFC1123
section 6.1.3.6 which says they "MUST NOT be implemented".

> RR types MB, MG, MR, and MINFO.   Should we do that in a suitable way?

I would support that.

---

From: Dick Franks <[email-masked]>
Date: Wed, 3 Mar 2010 11:14:53 +0000

Alfred,

Andreas has persuaded me to revise my proposed rewording of section 4
para 2 to read:

    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.

The intention is to avoid any need to define "well known" without any
risk of inadvertently imposing new requirements on existing (albeit
obsolete) RRs. The issue of obsolescence does not need to be addressed
here and now.

--Dick

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 09 Mar 2010 22:59:46 -0500

> |            most domains.  Furthermore these types are subject to

This is not a bad idea, IFF this means people can drop code and/or not
write code when doing new implementations.
The goal of the draft would be to declare that these types do not need
to be "known" any more, not to reclaim the type codes.

Such a draft needs to go through all the type code allocations <= 42
(last RRtype allocated before RFC3597).
Any type defined after RFC3397 does not need to be cleaned up.
i.e. DNS RRtypes registry for newer types is write-only.

	Olafur

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Mar 2010 15:48:17 +1100

> i.e. DNS RRtypes registry for newer types is write-only.

While RFC1123 may have said they were recoverable DNSSEC has made
them not so (excluding NULL).
 
I see RP records from time to time.  I see no reason to deprecate RP.

As for MB, MG, MR, NULL and MINFO, I don't see them being used
except in tests.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 10 Mar 2010 16:07:54 +1100

> I see RP records from time to time.  I see no reason to deprecate RP.

RP unlike MB, MG, MR and MINFO is intended for human consumption
as well as machine consumption so the lack of applications that look
this up should not be seen as a indication that it is not used.

---

From: SM <[email-masked]>
Date: Tue, 09 Mar 2010 22:58:46 -0800

At 19:59 09-03-10, Olafur Gudmundsson wrote:
>On 01/03/2010 9:03 AM, Alfred wrote:

draft-allbery-afs-srv-records was written to define a SRV RR for 
AFS.  I suggest talking to the AFS3-standardization folks before 
taking an action on AFSDB RR as current AFS clients might not support 
the new RR yet.

Dropping code may be an effective way to clean up the space.

Regards,
-sm

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 10 Mar 2010 12:11:10 +0000

Hi Olafur, Alfred, folks,
 If we're grinding away old experimental RR types, please can we keep LOC (code 29).
Given that 1876 < 3597, LOC falls into this group.
I and a load of others use LOC, I believe it's still useful, it works, so let's not zap it.
all the best,
  Lawrence