Subject: [dnsext] draft-ietf-dnsext-rfc2672bis-dname-16 follow-up

From: Alfred Hönes <[email-masked]>
Date: Fri, 18 Sep 2009 11:37:10 +0200 (MESZ)

Hello again,
in an attempt to catch up with the evolution of DNSEXT topics
during the months I had almost no cycles available to this end,
I now also have tried to closely follow up to the latest revision
of the DNAME draft, draft-ietf-dnsext-rfc2672bis-dname-16.

The single significant change in that version was the elimination
of the previously proposed UD bit allowing resolvers to signal
their capability to understand DNAME and thereby allowing servers
to omit CNAME synthesis for DNAME RRs -- shortening the response,
but at the price of an added dependency on EDNS0.

However, this UD bit elimination has been performed imperfectly,
and a few nits have also become apparent on studying the draft.

The following details should be corrected:

(1) Section 3.1, first paragraph

The draft currently says:

     [...].  A CNAME RR with TTL equal to the corresponding DNAME RR is
|  synthesized and included in the answer section for resolvers that did
   vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv^^^^^^^^^^^^^^^^^^^^^^^
|  not indicate understanding of DNAME in queries.  [...]

The tagged phrase has become nonsensical by the removal of the UD
bit signalling mechanism.  Hence, the draft should simply state:

     [...].  A CNAME RR with TTL equal to the corresponding DNAME RR is
|  synthesized and included in the answer section.  [...]

(2)  Section 3.4, last (4th) paragraph

The draft says:

   If a recursive caching name server encounters a DNAME RR which
   contradicts information already in the cache (excluding CNAME
   records), it SHOULD NOT cache the DNAME RR, but it MAY cache the
|  CNAME record received along with it or synthesized from the DNAME
   vvvvvv                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|  record, subject to the rules for CNAME caching.

IMHO, the tagged clause solely refers to case previously described
in the second paragraph of section 3.4 up to the previous draft
version and removed with UD bit support in this version:

  "Recursive caching name servers MUST perform CNAME synthesis on behalf
   of DNAME-ignotant clients.  [...]"

I could not find text in the draft that allows CNAME synthesis
in a recursive resolver under other circumstances.
(My reading of sections 3.1 and 3.2 is that these are applicable
to authoritative servers only; it may be that in these sections
the term "server" should be ultimatively disambiguated by using
"authoritative server", since unfortunately the use of DNS role
names diverges in practice.  Please correct me if I'm wrong or
have overlooked something.)

If I'm correct in that there is no other scenario for such
'downstream' CNAME synthesis to be referred here, the "or" clause
tagged above needs to be removed from the draft text as well:

   If a recursive caching name server encounters a DNAME RR which
   contradicts information already in the cache (excluding CNAME
   records), it SHOULD NOT cache the DNAME RR, but it MAY cache the
|  CNAME record received along with it, subject to the rules for CNAME
   caching.

(3)  Nits

(3a) Section 2.2, 1st para

Please fix the grammar; the draft text looks correctly at first
glance, but the sentence does no make proper sense:

                                      v
|                         [...[.  As is the case of finding a CNAME
   resource record or NS resource record set, the processing of a DNAME
   will happen prior to finding the desired domain name.
---                                   v
|                         [...[.  As in the case of finding a CNAME
   resource record or NS resource record set, the processing of a DNAME
   will happen prior to finding the desired domain name.

[ Otherwise,  s/of finding/when finding/  might be an alternative. ]

(3b)  Section 3.1, 1st para

   When preparing an response, [...]
---                ^
   When preparing a response, [...]

(3c)  Section 3.4, 2nd para

The comma in the first sentence should be removed, in accordance with
contemporary RFC Editor style:
                                                  v
|  This conflict situation is a transitional phase, that ends when the
   old data times out.  [...]
---
|  This conflict situation is a transitional phase that ends when the
   old data times out.  [...]

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+