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

[Alfred Hönes <[e-mail]>]

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