[dnsext] A quick review of draft-cheshire-dnsext-special-names-02

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

Hi,
I've performed a quick review of the DNSEXT-related I-D,
    draft-cheshire-dnsext-special-names-02
and would like to submit a few notes.


(A)  Significant issues

(A.1)
Firstly, I'm surprised by the non-trivial overlap of this work
with RFC 6303 and the IANA Registry created by it, the "AS112" RFCs,
and the ongoing work-in-progress to address more emerging overload
reasons for the authoritative root/infrastructure DNS servers by
extending the scope of the AS112 project, registering more "special"
domain names in that "Locally Served DNS Zones" IANA registry, and
specifying that they be treated as specified in RFC 6303.

The present draft not even quotes RFC 6303 for Sect. 5.1, where
the largest overlap with RFC 6303 occurs.  (I have not yet studied
in detail inhowfar the new specification in that section is
compatible or collides with the normative behavior specified in
RFC 6303.)


(A.2)
Second, the new draft version has expanded the scope of the I-D
significantly, and that has not been reflected in the Abstract.
Maybe that should be amended like this:

OLD:

|Abstract
|
|  This document describes what it means to say that a DNS name is
|  reserved for special use, when reserving such a name is appropriate,
|  and the procedure for doing so.

NEW:

|Abstract
|
|  This document describes what it means to say that a DNS name is
|  reserved for special use, when reserving such a name is appropriate,
|  and the procedure for doing so.  It establishes an IANA registry for
|  such domain names and seeds it with some of the special domain names
|  established by existing RFCs.


(A.3)  Terminology, use of leading/trailing dots with domain names

Despite the colloquial "dot-com" speak, a dot should not be used
on the left-hand side of domain names -- maybe except when used as
an indication for subdomains, but that can be handled better by
suitable text.  Detailed examples are shown in the walk-through below.

In practice, the presence or absense of a trailing period is used to
distinguish between fully qualified and relative domain names (which
might be subjected to "domain suffix list" expansion in common APIs,
or which can appear in industry standard zone files under effect of
$ORIGIN directives) -- cf. Section 3.1, page 8 of RFC 1034.

Similarly, it might be worth using the more precise, common DNS terms
"Stub Resolver", and "Iterative Resolver" (instead of "Caching DNS
servers") throughout the draft -- authoritative DNS servers, DNS
proxies, and even stub resolvers commonly use some caching as well!


(A.4)  Section 5.1

As already mentioned above, this collides with RFC 6303 and the
IANA registry established by it.

I strongly recommend to remove _all_ domain names from this section
and instead include by reference the domain names registered in the
"Locally Served DNS Zones" IANA Registry established by RFC 6303.
It looks like all domain names suitable for registration there
-- not only the reverse DNS zone names for RFC 1812 addresses --
deserve the same behavior.
Also, to avoid collisions with behavior specified in RFC 6303,
Sections 2 and 3 of RFC 6303 should be carefully evaluated and any
overlapping or colliding text -- in particular in bullet 4. --
should be removed and replaced by a pointer to the normative text
in RFC 6303.


(B) editorial linear walk-through

(B.1) Section 1, 2nd para

The draft should better use the definite article when "DNS" is used
as a noun:

|  Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own
   concept of reserved names, [...]
---                                                   vvvv
|  Analogous to Special-Use IPv4 Addresses [RFC5735], the DNS has its
   own concept of reserved names, [...]


(B.2) Section 4, list item 6.

I suggest to add a comma for clarity:

      Does this reserved Special-Use Domain Name have any potential
      impact on DNS server operators? If they try to configure their
|     authoritative DNS server as authoritative for this reserved name
      will compliant name server software reject it as invalid? [...]
---
      Does this reserved Special-Use Domain Name have any potential
      impact on DNS server operators? If they try to configure their
|     authoritative DNS server as authoritative for this reserved name,
      will compliant name server software reject it as invalid? [...]


(B.3)  Sections 5.2 through 5.5, leading text each

*  The text in Section 5.4 says:

|                              [...]  In the text below the term
|  "invalid" is used in quotes to signify such names, as opposed to
|  names that may be invalid for other reasons (e.g. being too long).

This is a useful convention, and although "invalid" is likely the
most serious case, I strongly suggest to extend this convention
and style uniformly to Sections 5.2, 5.3, and 5.5 as well.
(Besides, in the quote above, a comma should be placed for improved
 readability after "below".)

*  As mentioned above above, the placement of leading/trailing periods
   in domain names should be aligned woth RFCs 1034, 1035, and 2181.

So, for instance, I recommend to change the "head" of Section 5.4
as follows:

OLD:

|5.4.  Domain Name Reservation Considerations for ".invalid."
|
|  The domain ".invalid.", and any names falling within ".invalid.", are
|  special in the ways listed below. In the text below the term
|  "invalid" is used in quotes to signify such names, as opposed to
|  names that may be invalid for other reasons (e.g. being too long).

NEW:

|5.4.  Domain Name Reservation Considerations for "invalid."
|
|  The domain "invalid.", and any names falling within "invalid.", are
|  special in the ways listed below. In the text below, the term
|  "invalid" is used in quotes to signify such names, as opposed to
|  names that may be invalid for other reasons (e.g. being too long).


I recommend that the "heads" of Sections 5.2, 5.3, and 5.5 are
modified in a similar manner, and the double-quoting of the
respective domain names be introduced throughout these sections.
For example:

NEW:

|5.2.  Domain Name Reservation Considerations for "test."
|
|  The domain "test.", and any names falling within "test.", are
|  special in the ways listed below.  For clarity, in the text below,
|  this domain name is always used in double-quoted form.


(B.4)
Following established practice, protocol field names and protocol
values should be spelled as in the normative specifications.

Hence, throughout the draft (i.e. in Sections 5.3, 5.4, and 5.5 --
bullet 6. each), please  s/rdata/RDATA/ .


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext