Subject: Re: [dnsext] Lookup ambiguity of CNAME and DNAME

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Jun 2010 08:02:02 -0400

At 10:44 +0200 5/27/10, OndÞej Sur˜ wrote:

>The reason why I am proposing CNAME+DNAME is that it seems to me that we
>can get this functionality right now and cost would only be to upgrade
>authoritative servers.  (But several people has stated that it's not true
>due different implementation details.)

What is needed is for an examination of why CNAME 
forbids other records and whether that 
prohibition is inappropriate for DNAME records.

CNAME's rules were written before DNAME.  DNAME's 
rules were poorly written.  And lot's of code was 
written and distributed based on this.

(Too bad there was no adherence to the IETF 
process rules of PS, DS, and FS for many years.)

>Wildcards are non-issue.  As Mark has already stated, all it takes is to
>forbid DNAME at wildcard.  You can't have it all :).

When I hear "X is a non-issue" I get concerned. 
This is what got us in to the trouble above.

We now can have * CNAME - that didn't happen 
until RFC 45xy or whatever it was.  (An example 
of incompleteness in STD13.)  And I do think * 
owning DNAME causes conflicts at the caches 
anyway (w/o CNAME that is).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Jun 2010 09:45:57 +1000

In message <4CB1917A35FA4A118AFB4E042D59506D@local>, "George Barwood" writes:
> Edward,
> 
> Looking at 
> 
> http://tools.ietf.org/html/rfc4592#section-4.4
> 
> it seems to me that if you want wildcard DNAME, the solution would be for
> servers not to perform the wildcard substitution on the DNAME record,
> i.e. return the unmodified DNAME record to the client ( but generate an
> unsigned CNAME with wildcard substitution performed there ).
> 
> There may of course be some problems with this, it's just an idea.
> 
> George

Wildcard DNAME's cannot be made to work using the existing definition
of a wildcard match.  "*" matches multiple labels so the DNAME never
gets applied unless a cache learns about it as the result of a
DNAME/ANY query.

What's the answer to a A query for a.b.foo when there is just the
following record in the foo zone apart from the records at the apex?
Hint it doesn't include a CNAME.

	*.*.foo CNAME bar

Those that want wildcard DNAME to work also want the "*" to only
match a single label.

They want

	*.foo DNAME bar

to produce

	c.foo DNAME bar
	a.b.c.foo CNAME a.b.bar

for qname a.b.c.foo.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Jun 2010 19:06:34 +1000

In message <EC05D1A8AEA64101A20C4CB11624F965@local>, "George Barwood" writes:
> 
> ----- Original Message ----- 
> From: "Mark Andrews" <[email-masked]>
> To: "George Barwood" <[email-masked]>
> Cc: <[email-masked]>; "Edward Lewis" <[email-masked]>
> Sent: Tuesday, June 08, 2010 12:45 AM
> Subject: Re: [dnsext] Lookup ambiguity of CNAME and DNAME 
> 
> 
> > 
> Right, agreed. This seems a better explanation that the one given in the
> RFC 4592 for why a wildcard DNAME is a non-starter.

One follows from the other.  Think about what happens once the cache
learns about the DNAME.
 
> I suppose non-wild matching can still happen,e.g.
> 
> *.dname.example.com. DNAME foo.org.
> 
> with the query
> 
> a.*.dname.example.com. A
> 
> is presumably a DNAME match, although best avoided considering the
> likelihood of confusion.
> 
> George