Re: {Blocked Content} I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-07.txt

[Edward Lewis <[e-mail]>]

Regarding

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-07.txt

# 2.3.  DNAME Apex not Redirected itself
...
#  This means that a DNAME RR is not allowed at the same domain name as
#  NS records unless there is also a SOA record present.  DNAME RRs are
#  not allowed at the parent side of a delegation point but are allowed
#  at a zone apex.

The first sentence makes no sense to me.  I would suggest omitting it 
as the valid point is made in the second sentence.  (That is - if you 
are a cache and happen to have all of a domain name's information 
stored you will always have an SOA where there is an NS.  From that 
perspective a restriction saying "it can't have NS unless there's an 
SOA" has got to be defined in the context of a zone file.)

# 2.4.  Names Next to and Below a DNAME Record
#
#   Other resource records MUST NOT exist below the owner of a DNAME RR.

MUST NOT exist *at a domain name* below
and maybe "s/below/subordinate/" as is in the succeeding sentence.

To disambiguate with records at the same name, some might confuse the 
concept of types at a name as having "higher/lower" position when we 
consider DNSSEC's canonical ordering of types within a domain name.

#3.2.  CNAME synthesis
...
#   It does not make sense for the authoritative server to follow the
#   chain of DNAMEs, CNAMEs and wildcards outside of the zone of the
#   query, as some resolver implementations will remove out-of-zone
#   information from the answer.

This wording bothers me.

What is the "zone of the query?"  A query does not have an intended 
zone, e.g., the same iterative query is sent to the root servers 
(barring anything better in a cache) as is sent to the TLD and so on, 
down to the server hosting the zone closest to the zone authoritative 
to the query name.  Is the intent that the zone picked in step 2 of 
RFC 1034, 4.3.2, the "zone of the query?"

Quoting from RFC 1034, chapter 4.3.2, verse 2:
@    2. Search the available zones for the zone which is the nearest
@       ancestor to QNAME.  If such a zone is found, go to step 3,
@       otherwise step 4.

I philosophically agree with "does not make sense for the 
authoritative server to follow" chains as I think that is one of the 
mistakes in RFC 1034.  However, that is what RFC 1034 "commands" 
later in 4.3.2:

Quoting from RFC 1034, chapter 4.3.2, verse 3:
@         a. If the whole of QNAME is matched, we have found the
@            node.
@
@            If the data at the node is a CNAME, and QTYPE doesn't
@            match CNAME, copy the CNAME RR into the answer section
@            of the response, change QNAME to the canonical name in
@            the CNAME RR, and go back to step 1.

Go "back to step 1" is the restart of the query within the server, 
meaning redo step 2 (choosing the zone).

If the intent is to edit those comments, this is a much bigger deal 
than advertised (=update to DNAME).

#3.3.  Acceptance and Intermediate Storage
#
#   DNS Caches MUST NOT allow data to be cached below the owner of a
#   DNAME RR, except CNAME records and their signatures.  CNAME records

All sorts of alarm bells began to ring on this one - "and their 
signatures" set them off.  The CNAMEs aren't signed in this case.

What about a situation in which data at a name is cached for a week 
and three days later the zone administrator puts in a DNAME above the 
name cached.  If the cache learns of the DNAME, does the cache have 
to purge the previously cached data?

Another thing bothers me that is not related to the text here and I 
couldn't find where it is mentioned.  Synthesizing the CNAME with a 
TTL of 0 is a mistake because that means unaware caches (those that 
can't handle DNAME) will not hold onto the CNAME.  Perhaps the TTL 
should be the same as the DNAME but DNAME aware caches ought to treat 
the CNAME as 0 - if they even ever see it.  (They'll see it from 
older responders that don't understand the UD bit.)

#5.2.  Dynamic Update and DNAME
#
#   Zones containing a DNAME RR MUST NOT accept a dynamic update message
#   that would add a record or delegation with a name existing under a
#   DNAME.
#
#   A server MUST return an error message with RCODE=REFUSED [RFC2136] in
#   response to a dynamic update message that would add a resource record
#   under a DNAME in the zone.

This section should state that it is permissible to delete a DNAME RR 
set from a name or modify one.  What about adding?  That's more 
complex because there may be existing names below the proposed owner 
of the DNAME.  Would it be like adding an NS RR?  Masking away the 
obscured names?  Or is the addition a flat-out error?  I think that 
needs to be discussed (meaning, I don't have a definite opinion 
myself).

#5.3.2.3.  Response With Synthesized CNAME
...
#   The answer shown above has the synthesized CNAME included.  However,
#   the CNAME has no signature, since the server does not sign online (it
#   is a slow operation and exposes the signing key).  So it cannot be

The parenthetical comment is true but wrong.  The CNAME isn't signed 
for other reasons, such as a cache synthesizing the record.  Such a 
cache doesn't have the key.  In addition, signing the CNAME does not 
expose the signing key, the presence of the key on the server makes 
it conceivable that the key would be exposed.  I'd recommend just 
removing the comment altogether as it isn't really needed here and 
the caveats that could be included would dwarf the rest of the 
paragraph.  Case in point, this comment is more than twice as long as 
what I'm commenting on.

Finally, if there is an update to this, change the copyright to 2008. 
;)  Been there, done that, got the bounce.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                [phone]
NeuStar

Think glocally.  Act confused.

--
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/>