Subject: Re: DNAME and synthesized CNAMEs

From: "Matt Crawford" <[email-masked]>
Date: Fri, 25 Sep 1998 14:20:04 -0500

Bob,

  First of all, let me just disclaim a bit that the synthesized CNAME
feature was added at the request of other members of the WG, so my
defense of it may not be the most vigorous.  If your objections can't
be overcome, I won't mind removing it too badly.

  Taking the two points separately (text included below for other
readers), the fallout of the secure zone concern is that the
existence of the synthesized CNAME records can be securely denied.
Stated that way, it doesn't seem so awful.  But maybe there's a
better solution.

  How bad a bellyache would a DNSSEC-aware client get if along with
the DNAME record there were a KEY RR with the A/C bits = 11 (no key)
and the NAMTYP bits = 01 (zone key)?  This would indicate an
unsecured sub-zone, although there might not be any delegating NS
records.

  Or, suppose that along with the (signed) record

owner.of.dname	DNAME	target.of.dname

there were also a signed wildcard

*.owner.of.dname	CNAME	*.owner.of.dname ; or *.target.of.dname?

This would fix up the NXT problem.

  Another alternative is the one you siggest: not letting CNAMEs be
synthesized in secured zones.

  Moving on to the second issue, it would indeed seems sensible to
amend step 3.c, 4th paragraph, to say "check whether the name we
are looking for is the original QNAME in the query or a name
we have followed due to a CNAME +or DNAME+."  The difference between
the answers to an EDNS and a non-EDNS query remain, but I would not
call the difference "disturbing".  The difference would be exactly
the presence or absence of the cooked-up CNAME which is meant to help
old code get to the data we want to to reach.

				Matt

> Date: Mon, 21 Sep 1998 15:21:46 -0700
> From: Bob Halley <[email-masked]>
> Subject: DNAME and synthesized CNAMEs
> To: [email-masked]
> Cc: [email-masked]
> 
> Matt,
> 
> As part of design work for the next major revision of BIND, I was
> reading the DNAME draft.  I found some issues with synthesized
> CNAMEs.
> 
> 
> To be a secure zone (for a given key algorithm), all authoritative
> RRsets in that zone MUST be signed ([SECDRAFT5], 3.4).  DNAME thus
> cannot make signing synthesized CNAMEs optional for secured zones
> unless they are treated like glue.  For such an important thing as
> renaming, you really want authentication.
> 
> For secure zones with offline keys, there's no way to sign a
> synthesized CNAME.  The primary master for a zone with an online key
> could sign a synthesized CNAME, but its slaves could not.  Slaves
> shouldn't be able to sign things.
> 
> Synthesizing records in a secure zone also creates NXT problems.
> Assume we have
> 
> 	a.foo.com.	DNAME	bar.com.
> 	a.foo.com.	NXT	c.foo.com. DNAME NXT
> 
> (plus signatures for them) and then synthesize
> 
> 	b.a.foo.com.	CNAME	b.bar.com.
> 
> The NXT record is now wrong.  To make it right would require changing
> the zone.
> 
> I propose that secure servers MUST NOT synthesize CNAMEs.
> 
> 
> Synthesizing CNAMEs potentially causes surprising behavior even in
> non-secure zones.  Assume we have a non-secure zone foo.com with
> 
> 	a.foo.com.	DNAME	bar.com.
> 
> As I understand the algorithm in [DNAMEDRAFT2] section 4.1, if I make
> a recursive query for b.a.foo.com, type CNAME, without EDNS I'd get
> 
> 	a.foo.com.	DNAME	bar.com.			; Step 3c
> 	b.a.foo.com.	CNAME	b.bar.com.			; Step 3c
> 	b.bar.com.	CNAME	this.is.the.cname.target.	; Step 3a
> 
> or
> 
> 	The rcode is NXDOMAIN.
> 	a.foo.com.	DNAME	bar.com.			; Step 3c
> 	b.a.foo.com.	CNAME	b.bar.com.			; Step 3c
> 
> depending on whether or not b.bar.com. has a CNAME.
> 
> It's a little unclear to me whether we'd get that NXDOMAIN or not,
> since step 3c doesn't say what to do if there is no wildcard and the
> QNAME is not the original QNAME but rather one created by DNAME
> substitution.  If we don't get it, then we have to do another query to
> determine if we just got a dangling CNAME or if b.bar.com really
> doesn't exist.
> 
> A non-DNAME-aware resolver would not expect either of the above cases.
> It would be expect
> 
> 	b.a.foo.com.	CNAME	b.bar.com.
> 
> or NXDOMAIN, depending upon whether b.a.foo.com has a CNAME.
> 
> 
> 
> If I ask for b.a.foo.com, type CNAME, with EDNS V1 or greater I get
> something like
> 
> 	a.foo.com.	DNAME	bar.com.			; Step 3c
> 	b.bar.com.	CNAME	this.is.the.cname.target.	; Step 3a
> 
> or
> 
> 	The rcode is NXDOMAIN.
> 	a.foo.com.	DNAME	bar.com.			; Step 3c
> 
> depending on whether or not b.bar.com. has a CNAME.  My previous
> comments about the NXDOMAIN apply here too.
> 
> If the non-EDNS query were to generate the kind of answers that a
> non-DNAME-aware resolver expects, then the non-EDNS and EDNS answers
> to the same question would be disturbingly different.
> 
> You could make a rule "don't do the DNAME procedure if the user asks
> for type CNAME", but it is odd to have the server give you a CNAME as
> part of a non-type-CNAME query that it will deny if you ask about it
> specifically.
> 
> Ideas/comments?
> 
> /Bob
> 
> 
> References:
> 
> [DNAMEDRAFT2]				draft-ietf-dnsind-dname-02.txt
> [SECDRAFT5]				draft-ietf-dnssec-secext2-05.txt

---

From: "Michael A. Patton" <[email-masked]>
Date: Tue, 29 Sep 1998 23:55:39 EDT

Matt, Bob,

It was my recollection from the discussion in the working group that
since the synthetic CNAME was for compatability with legacy systems,
and there are very few DNSSEC aware clients in widespread use, that
the CNAME did not need to be signed (it's nice if it can be, but it
doesn't _need_ to be).  It's really there for clients that don't
support _any_ advanced features.  In some sense, it's only a hint, if
you want authority you need to recognize the DNAME anyway.

My personal hope is that, in large part because the changes for DNAME
are so easy, that DNAME will actually precede DNSSEC into widespread
use.  The problem only occurs in cases where a client is insisting on
secured RRs, from a zone that contains DNAMEs, but the client does not
recognize them.  I expect that resolvers that require DNSSEC, but do
not implement DNAME will end up only being used in experimental
setups, which should limit them both in time and number.

	-MAP

---

From: Bob Halley <[email-masked]>
Date: Tue, 29 Sep 1998 23:55:55 -0700

> unsecured sub-zone, although there might not be any delegating NS

Now the DNAME is at what looks (to the client) like a record at the
top of an unsecured zone.  I'd expect a DNSSEC-aware client to think
the DNAME was in the unsecured zone, and thus not authenticate it.
I'd rather not create something that looks like a zone cut but isn't.

> This would fix up theNXT problem.

With normal wildcards, the rdata doesn't vary based on the name being
wildcarded.  This is how DNSSEC allows RRs generated by wildcards to
be authenticated (section 5.3 of the DNSSEC draft).  In the
synthesized CNAME case, both the owner name and the target name
change, so you cannot sign a single wild CNAME that will authenticate
all the possible targets.

> synthesized in secured zones.

Another approach would be to require that any DNSSEC-aware client must
also be DNAME-aware.  Such a client would presumably either use EDNS
and not get synthesized CNAMEs, or would make non-EDNS queries and
be smart enough to discard the synthesized CNAME.

I still prefer not synthesing CNAMEs, but if people think that enough
non-DNAME-aware clients are likely to encounter DNAMEs to make it
worthwhile, the "DNSSEC-aware implies DNAME-aware" seems like the best
alternative.

> old code get to the data we want to to reach.

But that still produces unexpected and potentially confusing results
from the point-of-view of a non-DNAME-aware client.  Again, assume we
have

By the modified algorithm, if I make a recursive query for
b.a.foo.com, type CNAME, without EDNS I'd get

	a.foo.com.	DNAME	bar.com.		; 3c
	b.a.foo.com.	CNAME	b.bar.com.		; 3c
	b.bar.com.	CNAME	whatever.the.target.is.	; 3c
	rcode is NOERROR

or

	a.foo.com.	DNAME	bar.com.		; 3c
	b.a.foo.com.	CNAME	b.bar.com.		; 3c
	rcode is NXDOMAIN

depending on whether or not there's a CNAME at b.bar.com.

This is unexpected for the non-DNAME-aware client for a few reasons:

In the NXDOMAIN case above, the non-aware client has asked "are there
CNAMEs for b.a.foo.com?"  It has gotten the CNAME it asked about, yet
the rcode is NXDOMAIN instead of NOERROR.

Also, the DNAME will be perceived as not being an answer to the
question it asked.  Recent versions of 'named', for example, would log

	wrong ans. name (a.foo.com != b.a.foo.com)

and then skip over the DNAME.  Mostly harmless, but annoying.  I don't
know what other resolver clients are likely to do when they encounter
an unexpected answer name.  Some may simply quietly skip over the
answer, others might complain and press on, some might even reject the
response.

Finally, the non-DNAME-aware client asked about "b.a.foo.com".  Since
it asked for query type CNAME, it doesn't expect a CNAME chain.

/Bob

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 30 Sep 1998 09:01:49 -0500

>> How bad a bellyache would a DNSSEC-aware client get if ...
> 
> Now the DNAME is at what looks (to the client) like ...

Yes, I know it's strange, but I was wondering what would *happen*,
based on the assumption that (DNSSEC && !DNAME) clients would exist
in small numbers and for a short time.

> [...] so you cannot sign a single wild CNAME that will authenticate

Yes, as I said, it only addresses the NXT problem.

> also be DNAME-aware.

That would of course be my favorite, if it can be so decreed.

>> we have followed due to a CNAME +or DNAME+."  [...]
> 
> [...]
> or [...]

No, you'd get = No Error either way.

				Matt