[dnsext] Re: REMINDER: rfc2672bis WGLC expiring!
Peter Koch
On Thu, Aug 28, 2008 at 12:17:08PM -0400, Andrew Sullivan wrote:
> We posted the WGLC for draft-ietf-dnsext-rfc2672bis-dname-14 on
> 2008-07-31.
here is my review of that draft with apologies for the late response.
I have deliberately not read other people's review for "implementation
independence", so far.
The draft is in a really good shape for the most part, so generally I support
it going forward on standards track, but there are some nits and a few
requests for clarification that I think could improve the clarity and
quality of the document, if addressed.
I do explicitly not support section 4, for reasons given down in the text.
The intended goal could be achieved better and cleaner (process wise)
with a different approach, IMHO.
Best regards,
Peter
> Update to DNAME Redirection in the DNS
> draft-ietf-dnsext-rfc2672bis-dname-14
> Requirements Language
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119 [RFC2119].
NIT: This is easily lost between the abstract and the toc and could better
go into the introduction, maybe as a subsection
> 1. Introduction
> This document is a revision of the original specification of DNAME in
> RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of
> maintaining address-to-name mappings in a context of network
> renumbering. With a careful set-up, a renumbering event in the
> network causes no change to the authoritative server that has the
> address-to-name mappings. Examples in practice are classless reverse
> address space delegations.
CLARIFY: I don't understand the server's (sic!) role here. Do you mean
that with the scheme suggested in section 5.3 of RFC 2672 there is
no change needed to the reverse mapping _data_ in the respective zone?
> 2. The DNAME Resource Record
>
> 2.1. Format
>
> The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is
> not class-sensitive.
[...]
NIT: Later in the document it is mentioned that DNAME is a singleton type,
but for completeness I'd suggest to state this here, too.
> 2.2. The DNAME Substitution
> A DNAME substitution is performed by replacing the suffix labels of
> the name being sought matching the owner name of the DNAME resource
> record with the string of labels in the RDATA field. The matching
CLARIFY: Maybe _because_ I know how it works, I was confused by this
description. Maybe it's the ordering:
A DNAME substitution is performed by replacing those suffix labels
of the QNAME that match the DNAME RR's owner name with the
domain name in the DNAME RR's RDATA.
TERMINOLOGY: On several occurences the draft talks about "a DNAME" when
it actually refers to a DNAME RR. DNAME can be confused with
"domain name" and sometimes -- as with the term "CNAME" -- it isn't
too obvious whether the owner, the target/RDATA or the whole RR
is meant. Suggested solution: consequently use "DNAME RR" where
appropriate.
> QNAME owner DNAME target result
> ---------------- -------------- -------------- -----------------
> com. example.com. example.net. <no match>
> example.com. example.com. example.net. <no match>
> a.example.com. example.com. example.net. a.example.net.
> a.b.example.com. example.com. example.net. a.b.example.net.
> ab.example.com. b.example.com. example.net. <no match>
> foo.example.com. example.com. example.net. foo.example.net.
CLARIFY: the latest example line is not different from the third, is it?
Suggest to remove the "foo" example.
> a.x.example.com. x.example.com. example.net. a.example.net.
> a.example.com. example.com. y.example.net. a.y.example.net.
> cyc.example.com. example.com. example.com. cyc.example.com.
> cyc.example.com. example.com. c.example.com. cyc.c.example.com.
> shortloop.x.x. x. . shortloop.x.
> shortloop.x. x. . shortloop.
We should "eat our own dogfood" here and stick with RFC 2606 TLDs, even
if that causes a line break, IMHO.
> corner case DNAME can form a loop. Resolvers and servers should be
> cautious in devoting resources to a query, but be aware that fairly
> long chains of DNAMEs may be valid. Zone content administrators
> should take care to insure that there are no loops that could occur
> when using DNAME or DNAME/CNAME redirection.
The fuzziness is likely deliberate, but "fairly long" isn't enough
guidance IMHO. Also, the text seems to demand loop detection instead of
setting a lower bound (of, say, 8 or 16) for the combined DNAME/CNAME chain
length.
> 2.3. DNAME Apex not Redirected itself
> Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
> owner name; the owner name of a DNAME is not redirected itself. The
> domain name that owns a DNAME record is allowed to have other
> resource record types at that domain name, except DNAMEs or CNAMEs.
> This means that DNAME RRs are not allowed at the parent side of a
> delegation point but are allowed at a zone apex.
The precondition doesn't seem to support the conclusion. The reason that
DNAME RRs can't appear in parallel to the dlegating NS RRSet is that the
protocol just doesn't allow anything else but the NS RRSet, glue address
records and DNSSEC RRs at the delegation point in the parent. This is no
special property of the DNMAE RR type.
> 2.4. Names Next to and Below a DNAME Record
>
> Resource records MUST NOT exist at any domain name subordinate to the
> owner of a DNAME RR. To get the contents for names subordinate to
> that owner, the DNAME redirection must be invoked and the resulting
In the spirit of RFC 4592, I think the question of existence of names
should be addressed at least in addition to the existence of RRSets.
Do names below a DNAME RR's owner exist? Does that depend on the resolution
of the target? How does this interact with CNAME synthesis?
NIT: suggest to replace "content" for names with ``RRSets associated with''
> target queried. A server MAY refuse to load a zone that has data at
> a domain name subordinate to a domain name owning a DNAME RR. If the
This supports unpredictable behaviour, so I'd suggest to allow the strict
variant only for master servers, not slaves. People running "multi master"
setups need to know what they are doing, but no harm is done when a slave
loads a zone with occluded data as long as it coirrectly treats the
DNAME RR.
> occluded, RFC 2136 [RFC2136], section 7.18. Also a server SHOULD
> refuse to load a zone subordinate to the owner of a DNAME record in
> the ancestor zone. See Section 5.2 for further discussion related to
Same here. Imagine migration from a child zone to a DNAME'd tree. Outright
refusal doesn't appear helpful to me from an operational perspective.
> DNAME is a singleton type, meaning only one DNAME is allowed per
> name. The owner name of a DNAME can only have one DNAME RR, and no
> CNAME RRs can exist at that name. These rules make sure that for a
> single domain name only one redirection exists, and thus no confusion
> which one to follow. A server SHOULD refuse to load a zone that
> violates these rules.
People have been arguing that names below a CNAME RR's owner do exist and
can have/own non-CNAME RRSets. Therefore, I don't understand why a DNAME
and a CNAME RR could not co-exist. There's no immediate confusion
since for the owner name the CNAME RR is to be consulted, whereas everything
below the owner would be covered by the DNAME RR. Both _could_ have
different targets, but that possibility (or opportunity, if you wish)
should not prohibit the RR types' co-existence.
> 2.5. Compression of the DNAME record.
> Although the previous DNAME specification [RFC2672] (that is
> obsoleted by this specification) talked about signaling to allow
> compression of the target name, such signaling has never been
> specified and this document also does not specify this signaling
> behavior.
Wouldn't the "UD" bit provide this signalling? Not that I'd expect much
gain from compression in DNAME RRs, though ...
> 3. Processing
>
> The DNAME RR causes type NS additional section processing.
That would mean the NS RRSet for the DNAME RR's target would be queried for
by the responding authoritative server?
I'd rather not see explicit QTYPE=NS queries being introduced en passant
without a more detailed specification. Also, im sceptical of the gain
to be achieved here, since most paranoid^Wmodern resolvers would likely
ignore random NS RRSets anyway.
> 3.1. CNAME synthesis and UD bit
> section for old resolvers. The owner name of the CNAME is the QNAME
> of the query. DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the
> synthesized CNAME does not have to be signed. The DNAME has an RRSIG
NIT: RFC 4035 actually says it SHOULD NOT be signed.
> and a validating resolver can check the CNAME against the DNAME
> record and validate the DNAME record.
>
> Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
> equal to the TTL of the corresponding DNAME record. A TTL of zero
> means that the CNAME can be discarded immediately after processing
> the answer. DNAME aware resolvers can set the Understand-DNAME (UD
> bit) to receive a response with only the DNAME RR and no synthesized
> CNAMEs.
NIT: Is this descriptive only or meant to be normative?
Then I'd suggest to s/can/SHOULD/;
> resolver processing of unsigned synthesized CNAMEs. Resolvers can
> set this in a query to request omission of the synthesized CNAMEs.
NIT: "can" or "MAY"?
> Servers copy the UD bit to the response, and can omit synthesized
NIT: Servers "MUST" copy? Or should they only copy the UD bit, if
a DNAME RR was actually involved in finding the answer?
> CNAMEs from the answer. Older resolvers do not set the UD bit, and
> older servers do not copy the UD bit to the answer, and will not omit
> synthesized CNAMEs.
NIT: To avoid ambiguity and since older servers' behaviour cannot be
retroactively changes, I'd change "do not copy" and "will not" to
"are not expected to" ...
CLARIFY: What are the expectations for unsolicited UD bits in responses?
> Servers MUST be able to answer a query for a synthesized CNAME. Like
> other query types this invokes the DNAME, and synthesizes the CNAME
> into the answer.
CLARIFY: What type of servers is meant here? Authoritative servers MUST
synthesize a CNAME RR for an RD=0, QTYPE=CNAME query and set the AA bit?
Recursive "servers" are a bit different, since they might not want to
respond to RD=0 and with RD=1, they'd be obliged to follow the
CNAME/DNAME to resolve the CNAME at the target, wouldn't they?
> 3.2. Server algorithm
[admittedly skipped]
> 3.3. Wildcards
>
> The use of DNAME in conjunction with wildcards is discouraged
> [RFC4592]. Thus records of the form "*.example.com DNAME
> example.net" SHOULD NOT be used.
NIT: Use normative language in the normative part of the text rather than
the example: The use of DNAME RRs at the wildcard owner is NOT
RECOMMENDED. Thus records ... ought not to be used {credits to Ed ;-}
> A server MAY give a warning that the behavior is unspecified if such
NIT: s/A server/An authoritative server/;
> a wildcarded DNAME is loaded. The server MAY refuse it, refuse to
> load or refuse dynamic update.
CLARIFY: What does "MAY refuse it" mean? Should it ignore just this
DNAME RR?
CLARIFY: Which error code to use for a dynamic update refusal?
> 3.4. Acceptance and Intermediate Storage
>
> Recursive caching name servers can encounter data at names below the
> owner name of a DNAME RR, due to a change at the authoritative server
NIT/TERMINOLOGY: change in the zone (not at the server)
> where data from before and after the change resides in the cache.
> This conflict situation is a transitional phase, that ends when the
> old data times out. The caching name server can opt to store both
> old and new data and treat each as if the other did not exist, or
> drop the old data, or drop the longer domain name. In any approach,
NIT: s/drop the longer domain name/drop the DNAME RR with the longer owner name/
> Recursive caching name servers MUST perform CNAME synthesis on behalf
> of DNAME-ignorant clients. A recursive caching name server that
> understands DNAMEs can send out queries on behalf of clients with the
> UD bit set (See Section 3.1). After receiving the answers the
> recursive caching name server sends replies to DNAME ignorant clients
> that include DNAMEs and synthesized CNAMEs.
CLARIFY/NIT: rearrange sentences to disambiguate:
A recursive caching name server that understands DNAME RRs MUST(?) send
a query with the UD bit sets on behalf of its client. After receiving
the response, the recursive caching name server sends a reply that
contains the DNAME RR and a synthesized CNAME RR to a client that
did not set the UD bit in the original query.
> 4. DNAME Discussions in Other Documents
> The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME.
> The opening premise of this section is demonstrably wrong, and so the
> conclusion based on that premise is wrong. In particular, [RFC3363]
> deprecates the use of DNAME in the IPv6 reverse tree, which is then
> carried forward as a recommendation in [RFC4294]. Based on the
> experience gained in the meantime, [RFC3363] should be revised,
> dropping all constraints on having DNAME RRs in these zones. This
> would greatly improve the manageability of the IPv6 reverse tree.
> These changes are made explicit below.
>
> In [RFC3363], the paragraph
>
> "The issues for DNAME in the reverse mapping tree appears to be
> closely tied to the need to use fragmented A6 in the main tree: if
> one is necessary, so is the other, and if one isn't necessary, the
> other isn't either. Therefore, in moving RFC 2874 to experimental,
> the intent of this document is that use of DNAME RRs in the reverse
> tree be deprecated."
>
> is to be replaced with the word "DELETED".
This is a purely operational issue for the maintenance of the IPv6
reverse tree and thus has little place in this clarification of the DNAME
document, IMHO. Also, the proposed change - apart from trying to "edit"
a foreign document, which doesn't sound right to me in the first place -
provides little guideline, even though the introductory text claims,
it "would greatly improve the manageability of the IPv6 reverse tree".
I'd rather drop this and address the issue of v6 reverse mapping in
a separate document that actually says _how_ this great improvement
can be achieved.
> In [RFC4294], the reference to DNAME was left in as an editorial
> oversight. The paragraph
>
> "Those nodes are NOT RECOMMENDED to support the experimental A6 and
> DNAME Resource Records [RFC3363]."
>
> is to be replaced by
>
> "Those nodes are NOT RECOMMENDED to support the experimental
> A6 Resource Record [RFC3363]."
If that was truly an oversight, then this change should either be posted
as an erratum with appropriate review and AD approval or RFC 4294
should be updated. Of course, there's little point in explicitly
"NOT RECOMMENDING" DNAME implementations for v6 nodes -- as opposed to
"not recommending" (the former discourages, the latter just doesn't encourage).
Therefore, I really would like to see this section be dropped completely.
> 5.1. Canonical hostnames cannot be below DNAME owners
>
> The names listed as target names of MX, NS, PTR and SRV [RFC2782]
> records must be canonical hostnames. This means no CNAME or DNAME
> redirection may be present during DNS lookup of the address records
> for the host. This is discussed in RFC 2181 [RFC2181], section 10.3,
> and RFC 1912 [RFC1912], section 2.4. For SRV see RFC 2782 [RFC2782]
> page 4.
NIT: s/page 4/description of "Target"/
> The upshot of this is that although the lookup of a PTR record can
> involve DNAMEs, the name listed in the PTR record can not fall under
> a DNAME. The same holds for NS, SRV and MX records. For example,
> when punycode alternates for a zone use DNAME then the NS, MX, SRV
NIT: "punycode" is probably old terminology these days, so why not explicitly
mention IDNs here, but ...
This seems to be a leftover from the early DNAME clarification that was
inspired by the IDN TLD discussion. The explicit reference to IDN/punycode
seems odd to me, since even when the document says "for example", it looks
like a special IDN problem, which it isn't. IMHO the previous text in this
section is good enough to serve as a reference for technical input into the
IDN debate.
> 7. Security Considerations
>
> DNAME redirects queries elsewhere, which may impact security based on
> policy and the security status of the zone with the DNAME and the
> redirection zone's security status.
NIT: s/redirection zone's/redirection target zone's/
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>