Subject: DNAME and the Understand-DNAME bit

From: Scott Rose <[email-masked]>
Date: Fri, 10 Aug 2007 14:02:12 -0400

DNAME and the Understand-DNAME flag bit

In an effort to have a flag for clients to signal DNAME
understanding, we propose to add a flag to the extended flags
field in the OPT RR:

(From the new draft):

    The UD bit is part of the EDNS extended RCODE and Flags
    field.  It is used to omit server processing, transmission
    and resolver processing the unsigned synthesized CNAMEs
    when DNSSEC validation is performed. 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.

            +0 (MSB)                +1 (LSB)
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: |   EXTENDED-RCODE      |       VERSION         |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|UD|                 Z                       |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    Servers MUST be able to answer a query for a synthesized
    CNAME.  An answer containing the synthesized CNAME cannot
    contain an error (since a CNAME has been followed), as
    per RFC 1034 CNAME rules.

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 or perhaps NSEC3
    records and their signatures.  CNAME records below the owner
    of a DNAME MUST be re-synthesized from the DNAME, or checked
    against the DNAME record before sending them out.  This
    improves consistency of the DNAME and CNAME records below
    the owner of the DNAME.

    DNS Caches MUST perform CNAME synthesis on behalf of DNAME-
    ignorant clients.  A DNS Cache that understands DNAMEs can
    send out queries on behalf of clients with the UD bit set.
    After receiving the answers the DNS Cache sends replies to
    DNAME ignorant clients that include DNAMEs and synthesized
    CNAMEs.

</snip>

So a client that implements EDNS0 can signal DNSSEC
understanding, DNAME understanding, both, and neither.

This will have an impact on caches that understand DNAME
and wish to set the UD, but get queries from clients
that may not understand DNAME and need synthesized CNAME
RRs in responses.  A recursive cache could send iterative
queries with the UD bit set, and synthesize CNAME RRs to
be placed in responses for clients that do not set the UD
bit (or don't implement EDNS0).

Please read the draft-ietf-dnsext-rfc2672bis-04.txt when
it is announced and comment.

DNAME editors
Wouter and Scott

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

---

From: Rob Austein <[email-masked]>
Date: Fri, 10 Aug 2007 19:30:55 -0400

> understanding, DNAME understanding, both, and neither.

DNSSECbis explictly required that DNSSEC-aware software also be
DNAME-aware, so <DO=1, UD=0> would be a protocol violation.

---

From: Peter Koch <[email-masked]>
Date: Sun, 12 Aug 2007 22:48:27 +0200

>    this in a query to request omission of the synthesized

sounds like an idea.  Maybe a bit more guidance by normative language
could help, i.e. MAY or SHOULD instead of "can".  Probably it's a SHOULD here.

>    UD bit to the answer, and will not omit synthesized CNAMEs.

So, is this copy action just to avoid any doubt or should the resolver
actually try to remember or otherwise use this information?

>    per RFC 1034 CNAME rules.

Not sure I understand this. Are you saying there's only NOERROR possible
as an RCODE with a synthesized CNAME RR? What if the server is also authoritative
for the target and knows that, e.g., the name doesn't exist?

>    ignorant clients.  A DNS Cache that understands DNAMEs can

again: "can" -> SHOULD?

>    DNAME ignorant clients that include DNAMEs and synthesized

Aren't the clients more "UD agnostic" than "DNAME ignorant"?  There are a couple
of resolvers out there today which will understand DNAME but don't and can't
(yet) use the signalling mechanism.
Sending the DNAME back anyway is backwards compatible, but I've always
wondered why a resolver would accept this even if it did not understand
the RR type and although it came after the synthesized CNAME RR.

-Peter

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 12 Aug 2007 23:26:13 -0400

>DNAME-aware, so <DO=1, UD=0> would be a protocol violation.

<hats-off>
Strictly speaking that is an old implementation that does not know about
UD bit. Here are the four different states
DO = 0 UD = 0  Understand ENDS0, but not DNSSEC or DNAME
DO = 0 UD = 1  Understand ENDS0, process DNAME but do not deal with DNSSEC
DO = 1 UD = 1  Understand ENDS0, DNAME and DNSSEC (modern implementation)
DO = 1 UD = 0  Same as above the one above but implemented
                 before rfc2672bis publication

         Olafur

---

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 13 Aug 2007 09:42:41 +0200

> actually try to remember or otherwise use this information?

To avoid doubt in the reply (like existed for the DO bit).

> for the target and knows that, e.g., the name doesn't exist?

Many non-answer rcodes are possible (servfail, refused, ...), however
when you include the CNAME as (part of) an answer, even if the server is
also authoritative for the target and the name does not exist, the RCODE
stays NOERROR. This is per CNAME spec, rfc 1034. This is also true for
synthesized CNAMEs.

> (yet) use the signalling mechanism.

That may be better wording.

Best regards,
   Wouter

---

From: Rob Austein <[email-masked]>
Date: Mon, 13 Aug 2007 12:13:33 -0400

At Sun, 12 Aug 2007 23:26:13 -0400, Ólafur Guðmundsson wrote:
> Strictly speaking that is an old implementation that does not know
> about UD bit.  Here are the four different states

I'm ok with this interpretation, but the point is that you can't
express "I understand DNAME but don't understand DNSSEC."  I think
it's ok that you can't express this, I'm just arguing with Scott's
characterization.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Aug 2007 12:57:32 -0400

>DNAME-aware, so <DO=1, UD=0> would be a protocol violation.

...because the synthesized CNAME is not signed.  I had to think a 
while to remember the rationale for the restriction.

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

Think glocally.  Act confused.

---

From: Scott Rose <[email-masked]>
Date: Mon, 13 Aug 2007 12:58:09 -0400

I mis-characterized it in a (failed) attempt to keep the text short :)

The UD bit is only to signal that the client does not need CNAME 
synthesis done on its behalf by the server.

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Rob Austein <[email-masked]>
Date: Mon, 13 Aug 2007 13:11:05 -0400

> synthesis done on its behalf by the server.

As Ed reminded us, DNSSEC requires the client not to need CNAME
synthesis, because we can't sign the synthesis.

Bu I'm not expressing myself very well today either:

> > express "I understand DNAME but don't understand DNSSEC."

Before someone else points it out, I said this backwards: the state
you can't express is "I understand DNSSEC but don't understand DNAME"
(he who lives by the nit shall die by the nit....)

Casting this back into Scott's terms, I still like Olafur's answer: if
you say you understand DNSSEC, you don't need CNAME synthesis.  Done.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 20 Aug 2007 14:43:09 +0200

T-shirt !!!!

> (he who lives by the nit shall die by the nit....)

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/