draft-ietf-dnsext-dns-protocol-profile-00

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

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hello,
after browsing through the Internet-Draft authored/edited by you,
        draft-ietf-dnsext-dns-protocol-profile-00,
I'd like to submit a few comments, supplying some additional
information, addressing textual flaws I found in that memo,
and suggesting a few additional topics that should be addressed.


(1)  Section 1.1, 3rd paragraph -- typo

s/the documents normative language/the document's normative language/
                                               ^

(2)  Section 3

(2a)
Missing full-stops at the end of paragraph 2 & 4.
(Also applicable to some subsequents sections/paragraphs.)

(2b)
The last paragraph od Section 3 says:

   {new normative language} Processing if dns names in US-ASCII range
   MUST be case insensitive.  [RFC 1035 (2.3.3)] also see [RFC 1034
   (3.1)]

There are multiple issues:

- s/if/of/

- s/dns/DNS/

- Processing must be done by *label*, not necessarily in a homogenous
  manner for an entire DNS name -- e.g., there could be binary labels
  in a domain name.  Although this is currently not very important
  because the original use of binary labels for IPv6 has been
  deprecated, there might be other uses or new label types in the
  future.  Therefore, I suggest to unambiguously state:

|  {new normative language} Processing of DNS 'ASCII labels' MUST be
|  case insensitive.  See [RFC 1035 (2.3.3)], [RFC 1034 (3.1), and
|  [RFC4343] (3.1).

Accordingly, a reference '[RFC4343]' to RFC 4343 needs to be added to
Section 12 of the draft.


(3)   Section 4.1

(3a)  (don't know where to insert)

RFC 2308, section 5 has normatively changed the semantics of the
SOA.MINIMUM TTL field to become the 'Negative Caching TTL'.
Nevertheless, I frequently see zone files giving the old
interpretation of SOA.MINIMUM in a comment, and I fear that
this only is a symptom of outdated thinking, burned into the
brains of DNS implementors as well.

Therefore, I suggest to emphasize this change from STD13
in this roadmap document.

(3b)  4.1.1 -- Re: RFC 2535

RFC 2535 has been formally obsoleted by RFCs 4033..4035
(and as listed in the RFC index), but in fact some parts of
RFC 2535 are not considered obsolete.
This is quite confusing, in particular because there are other
documents equally considered still valid that make normative
references to RFC 2535 -- in particular RFC 2931 ('SIG(0)'),
and RFC 3445 that also has been obsoleted by RFCs 4033..4035,
but contains important updates to RFC 2535 still valid for /
defining the non-obsolete parts of RFC 2535.

There's a real need for a new, standalone specification
containing the non-deprecated parts of RFC 2535, perhaps
integrated with an updated version of RFC 2931, to make
an end to the existing confusion.  Such document should
also incorporate (and obsolete) RFC 3445 and delineate
the (diminishing) applicability of the KEY RR, according
to current wisdom.

(3c)  4.1.1 -- item 4.

The draft says:

   4.  The TTLs of all RRs in an RRSet MUST be the same. {RFC reference
       required}
       ^^^^^^^^
The normative text you are looking for is in RFC 2181, section 5.2.


(4)  Section 4.2

The most frequent trouble with DNS I found in the last two years
is the inappropriate firewall filtering of DNS requests.

While it is common practice for (recursive) DNS resolvers to use
port 53 for listening for queries *and* sending queries, there is
no requirement to do so, in any DNS related RFC ever published.
DNS resolvers behind a NAT box with port translation cannot
enforce the source port of the DNS queries they emit, as seen
in the public Internet.
Furthermore, there are a lot of upcoming recommendations for
source port randomization as a partial defense against blind
off-path attacks.
Therefore, filtering DNS queries on source port is a major
obstacle to connectivity, and it does not add anything to the
security of the sites doing so.  (BTW: M$ is one particular site
doing so since months, such making it impossible for me to contact
IETFers with email addresses served by these DNS servers, including
hotmail.com!)

I suggest to add a sentence to Section 4.2, pointing out that
the source port for DNS queries is not restricted in any way
by all existing DNS RFCs (for UDP and TCP as well).


(5)  Section 4.3 -- Re:  OPCODE 1

IQUERY indeed has been *obsoleted* by RFC 3425.


(6)  Section 4.6

It should be noted that the use of MB, MG, MR, and MINFO has been
deprecated long ago, in favor of MX.
Definite RFC ref. is 2821, and statement reinforced in upcoming
2821bis (IETF LC passed, currently in final IESG processing).


(7)  Section 4.8

Document is unclear as to whether it is intended to cover DNSSEC
in the sense of RFC 4033..4035.  (I'd like to recall that DNS
transaction secority has been declared part of basic DNS, no more
part of DNSSEC -- as it was in RFC 2535 ff.)


(8)  Section 12.2

In Section 12.2, the citations [RFC1811] and [RFC1816] have been
truncated; in both cases, the document title is "U.S", should be:
"U.S. Government Internet Domain Names".


(9)  Appendix A

(9a)  RFC 1348

RFC 1348 was first obsoleted by RFC 1637, then by RFC 1706.  This
is clearly stated in the heading of RFC 1637 and in the RFC index.
The entry for RFC 1637 already is present in the list in Appendix A,
yet, the entry for RFC 1348 should be amended accordingly.

(9b)  RFC 1712

Although RFC 1876 semantically is a replacement for RFC 1712,
it has not formally obsoleted RFC 1712, and the RFC index still
lists both RFCs as current.  Even more, RFC 1876 does not mention
RFC 1712 or RRtype 27 at all, and RRtype 27 is not indicated
as deprecated or obsolete in the IANA registry.

It either should be considered to ask for a Protocol Action
by the IESG to retrofit the 'obsoletes' relationship 1712-->1876
and annotate RRtype 27 as obsolete in the IANA registry,
or to omit the entry for RFC 1712 fron Appendix A.

(9c)  RFC 2065

In line with other entries, the entry for RFC 2065 should be
amended by ", then by RFC 4033 through 4035".


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



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>