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

[Michael StJohns <[e-mail]>]

At 11:31 12/31/2007, Edward Lewis wrote:
>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.)

Agreed.  AND... this really needs to be defined in terms of server and resolver behavior rather than what can and can't be in the zone file. People will screw up and bad things will happen.  How - exactly - does this record work in the presence of "bad data"?    E.g.  what happens at a cache if it gets both a DNAME and NS records for a specific name?  Does it keep the DNAME records and discard the NS records? Vice versa?  Crash in disgust?

In 2.4 - "refuse to load" should probably be "refuse to serve" data below a DNAME.

What does a recursive resolver do if it gets conflicting data (e.g. data below a DNAME followed later by a DNAME and vice versa?)

There are other places in the text which have this problem as well.


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



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