[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: {Blocked Content} I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-07.txt
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 +1-571-434-5468
NeuStar
Think glocally. Act confused.
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>