Subject: [dnsext] To whomever asked for this, hope you're happy

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Sep 2008 13:54:39 -0400

Irritating nits against this:
http://tools.ietf.org/id/draft-ietf-dnsext-rfc2672bis-dname-14.txt

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

s/except/except other/ -- applies to DNAME only.  I think citing CNAME is
misleading, while true, CNAME isn't the only other barred type (think odd
like "ANY" or "OPT").  A blanket clause like "or other types that have
restrictions on what they can co-exist with."

#    This means that DNAME RRs are not allowed at the parent side of a
#    delegation point but are allowed at a zone apex.

"This means" - don't know what that refers to.  The restriction 
before that has no bearing on cut points.

#    The reason for this decision was that one can have a DNAME at the
#    zone apex.  There still is a need to have the customary SOA and NS
#    resource records at the zone apex.  This means that DNAME does not
#    mirror a zone completely, as it does not mirror the zone apex.
#
#    These rules also allow DNAME records to be queried through RFC 1034
#    [RFC1034] compliant, DNAME-unaware caches.
#
# 2.4.  Names Next to and Below a DNAME Record
#
#    Resource records MUST NOT exist at any domain name subordinate to the

domain name subordinate to the => a sub-domain of the
(don't think "subordinate" has been defined in DNS)

# 3.  Processing
#
#    The DNAME RR causes type NS additional section processing.

This seems to be leaving something hanging.  Off the top of my head, I
don't know what is meant by "type NS ..."  Maybe you need a pointer or
more context.

# 3.1.  CNAME synthesis and UD bit
#
#    When preparing an response, a server upon performing a DNAME
#    substitution will in all cases include the DNAME RR used in the
#    answer section.  A CNAME RR record with TTL equal to the
#    corresponding DNAME RR is synthesized and included in the answer
#    section for old resolvers.  The owner name of the CNAME is the QNAME

Clarify "old resolvers" to mean resolvers not showing any indication of
understanding DNAME.

#    of the query.  DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the
#    synthesized CNAME does not have to be signed.  The DNAME has an RRSIG
#    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.

"to indicate that they can 'deal with' DNAME/noCNAME response."  as opposed
to "to receive a response with..."

#    The UD bit is part of the EDNS [RFC2671] extended RCODE and Flags
#    field.  It is used to omit server processing, transmission and
#    resolver processing of unsigned synthesized CNAMEs.  Resolvers can
#    set this in a query to request omission of the synthesized CNAMEs.
#    Servers copy the UD bit to the response, and can omit synthesized
#    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.

"Older" means - prior to this specification. Or rather, compliant to previous
definitions of DNAME.  "Older" is tricky.

# 3.2.  Server algorithm
#
#    Below the server algorithm, which appeared in RFC 2672 Section 4.1,
#    is expanded to handle the UD (Understand-DNAME) bit.

This also includes the wild card RFC change too?  I think so.
(The part about chasing CNAME's through "*".)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>