Re: [dnsext] rfc6195bis draft : thoughts on CLASS sub-registry

[Donald Eastlake <[e-mail]>]

I am opposed to closes the CLASS registry. The key feature of
alternative data CLASSes is that each CLASS can have independent
roots. The availability of this escape from monolithic control of
CLASS=IN is, in my mind, very important even if it has not yet been
used.

Don't bother telling me about how impractical you think it would be to
actually use, say, CLASS=42. If there were a big enough problem,
people who care would be motived to make it work and would probably be
just the same sort of people who could evade or avoid problematic
middle-boxes.

I don't care that much either way about deprecating use/implementation
of CLASS=* in queries but the use of new meta CLASS values in other
operations may be useful.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

On Wed, Mar 28, 2012 at 6:11 PM, Alfred HÎnes <[e-mail]> wrote:
> Reconsidering the section on the DNS CLASSes sub-registry in the
> rfc6195bis draft, some thoughts came to my mind.
>
> I'd like to emphasize that this is a rough sketch to solicit
> discussion, not a request to change the draft (at this stage).
>
>
> * RFC 6410 (2-track) emphasizes the criteria for Internet Standard,
>  which include removal of unused protocol options that complicate
>  implementations and thereby increase the risk of security flaws.
>
> * The only Data CLASSES registered were originally specified in
>  RFCs 882+883 (November 1983) and finally standardized in STD 13,
>  RFCs 1034+1035 (November 1987), and in non-IETF documents listed
>  in the IANA registry with references dating back to June 1981
>  and April 1987.  The only other change to the set of assigned
>  DNS CLASS codepoints was the addition of QCLASS NONE by RFC 2136
>  (April 1997).
>
>  The only Data CLASS in public use is IN, the other registered
>  Data CLASSes are used in the contemporary Internet in some
>  obscure, implementation-specific manner (with strictly local
>  scope) by diagnostic functions built into DNS servers.
>  (This clearly is a hack, but it obviously works sufficiently for
>  those who know how to use that.)
>
> * Therefore, the addition of new Data CLASSes seems to be a feature
>  that does not fulfill a perceived need of the Internet community
>  and isn't expected to happen in the foreseeable future.
>  Given the significant potential issues with QCLASSes (see below),
>  there alse does not seem to exist a need for new QCLASSes, since
>  selection among an essentially one-element set of Data CLASSes
>  does not admit a great variety of choices anyway.
>
>  Does that mean that we also should *close* the DNS CLASSes IANA
>  subregistry with the rfc6195bis draft ?
>
>  Doing so would allow to significantly shorten the text in the
>  draft on CLASS value assignment policy.
>
>  Note that there is a CLASS range dedicated for Private Use, which
>  could be used anyway for proprietary functions, if deemed useful.
>
> * Delegation in the DNS happens within the namespace of a Data CLASS.
>  The current global, unique DNS root only delegates for CLASS=IN.
>  Therefore, the QCLASS=* (ANY) defined in STD 13 is rather
>  problematic and complicates implementations much more than it
>  might be regarded justified by occasional use for curiosity.
>  The basic reason is that, due to the independent delegation trees
>  for domain names per Data CLASS, queries with QCLASS=* are of no
>  practical value, and might even be regarded as conceptionally
>  inappropriate.  This already has been observed repeatedly in the
>  past, *very long* ago.
>
>  Both RFC 1034 and RFC 1035 already scratch at that idiosyncrasy
>  and specify that responses to QCLASS=* can never be authoritative;
>  these clauses already were present in RFCs 882+883.
>
>  STD 3, RFC 1123 (s6.1.2.2) says:
>   "A query with "QCLASS=*" SHOULD NOT be used unless the requestor
>    is seeking data from more than one class. In particular, if the
>    requestor is only interested in Internet data types, QCLASS=IN
>    MUST be used."
>  (Note that the summary table in s6.1.5 contradicts the above;
>   the respective check ('X') should be in the "SHOULD NOT" column,
>   not in the "SHOULD" column.)
>  Use of the DNS on the public Internet per definition is "interested
>  in Internet data types" only, so the "SHOULD NOT already applies
>  since October 1989.
>
> * Thus, in the sense of RFC 6410, RFCs 1034 and 1035 contain protocol
>  elements that complicate implementations, are of no practical
>  benefit and de facto not in use -- since two and a half decades.
>  Thereby, any revision to STD 13 would have to eliminate such
>  feature as QTYPE=* in order to pass the IESG today.
>
>  So the question arises whether it would be wise to now formally
>  deprecate QCLASS=* (maybe declare it HISTORIC and NOT RECOMMENDED
>  for implementation).
>
>  This could be done in rfc6195bis or in an independent Standards
>  Track RFC, but procedurally it would be much less work if done
>  in rfc6195bis.  (Note that the I-D targets BCP status and hence
>  actually can update Standards Track RFCs.)
>
>
> Thoughts, opinions?
>
>
> Kind regards,
>  Alfred.
>
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext