Subject: [dnsext] Lookup ambiguity of CNAME and DNAME

From: Edward Lewis <[email-masked]>
Date: Fri, 21 May 2010 09:55:34 -0400

This is a follow up to the claim that CNAME + DNAME would cause 
problems at caches because we can't make a rule that says "once at a 
matching domain name, if RRSET X and RRSET Y are present, here's what 
to do".

The rule in RFC 1034 concerning CNAME is this:

# The domain system provides such a feature using the canonical name
# (CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
# specifies the corresponding canonical name in the RDATA section of the
# RR.  If a CNAME RR is present at a node, no other data should be
# present; this ensures that the data for a canonical name and its aliases
# cannot be different.  This rule also insures that a cached CNAME can be
# used without checking with an authoritative server for other RR types.

If we break the rule to allow just the DNAME (DNSSEC's NSEC/RRSIG 
have already been special cased), then the above text applies to the 
DNAME.  In the example below, the crucial element is that the DNAME's 
RDATA differ between name1 and the CNAME-RDATA-referenced name2.

Zonefile has (please excuse typos, I can't verify this with running 
code because this presumes that CNAME and DNAME can co-exist at an 
owner).

example.tld.       9000 IN SOA
example.tld.       9000 IN NS
example.tld.       9000 IN NS

name1.example.tld. 7000 IN CNAME name2.example.tld.
name1.example.tld. 5000 IN DNAME name3.example.tld.

name2.example.tld. 9000 IN DNAME name4.example.tld.

name3.example.tld. 9000 IN NS    server-0.example.com.
name3.example.tld. 9000 IN NS    server-1.example.com.

name4.example.tld. 9000 IN NS    server-a.example.com.
name4.example.tld. 9000 IN NS    server-b.example.com.

A cache has this at some point in time:

name1.example.tld. 1000 IN CNAME name2.example.tld.

A query comes in for "name1.example.tld./IN/DNAME".  What does the cache do?

A cache following existing rules would return:

name1.example.tld. 1000 IN CNAME name2.example.tld.
name2.example.tld. 9000 IN DNAME name4.example.tld.

But the desired effect would probably have been:

name1.example.tld. 5000 IN DNAME name3.example.tld.

This is one ambiguity that would arise from having special processing 
happen when the lookup hinges on there being the presence of two 
different RRsets at a name.

We also have another complication - what happens at with wildcards. 
See RFC 4592, sections 4.3 and 4.4.  We can handle a CNAME at a 
wildcard but the behavior of a DNAME at a wildcard is "to be 
avoided."  (Please see the referenced text for more on that.)

I'll say the most alluring thought is that CNAME only restricts 
records at the same name but allow for data to be held below, DNAME 
only restricts names below the same name.  The only cross over is 
that CNAME says it can't live with the DNAME.  If a CNAME is at a 
(non-empty) non-terminal then the co-existing DNAME would have a 
problem but this is an issue only at the authoritative servers that 
see the entire zone.  Depending on how an authority reacts to this, 
it is possible that a cache wouldn't be "set up for a failure." 
(That is, if the DNAME occludes the records below, then the cache 
won't face an ambiguous state.)

PS - I anticipate the "oh, but who would do this?" and the ever 
popular "but this would only be seen when testing because that's the 
only time you ask for $foo records."  But such arguments have not 
succeeded in the past in changing quirks in the protocol.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Alex Bligh <[email-masked]>
Date: Fri, 21 May 2010 07:42:48 -0700

--On 21 May 2010 09:55:34 -0400 Edward Lewis <[email-masked]> wrote:

> We also have another complication - what happens at with wildcards. See
> RFC 4592, sections 4.3 and 4.4.  We can handle a CNAME at a wildcard but
> the behavior of a DNAME at a wildcard is "to be avoided."  (Please see
> the referenced text for more on that.)

I'm not even sure what a wildcard CNAME and wildcard DNAME together would
be meant to do. Were we to go down the CNAME+DNAME route, I do not imagine
drastic loss of functionality and rioting in the streets if we said
it didn't work with wildcard CNAME.

-- 
Alex Bligh

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 21 May 2010 16:19:32 +0200

Hi Ed,

Agreed that a query for qtype=DNAME would in this situation not give the
expected answer with older versions of software.

But I previously posted some CNAME text for dnssec-bis-updates that
proposes to solve an almost identical case but with a NSEC or RRSIG next
to the CNAME and with qtype=NSEC.  So, current caches follow the CNAME
but this is not good for answers that can be proven.

I believe this similarity is what Ondrej was trying to convey to you.

Reliable elicitation of the types can be gotten due to their special
processing.  For DNAME prepend a label, for NSEC ask for qtype=Null, for
RRSIG set DO flag.  Not that this is pretty and I'm dodging the
wildcards :-)

Best regards,
   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Sat, 22 May 2010 09:39:42 +1000

> it didn't work with wildcard CNAME.

It's a non-issue.  The same at a CNAME + DNAME can't exist at the apex
of a zone as CNAME + DNAME co-existance is not the sole constraining
rule.  CNAME + DNAME at a wildcard cannot exist.   The rules for both
types need to be satisfied for them to co-exist.

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

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 27 May 2010 10:44:44 +0200

On 21.5.2010 16:19, W.C.A. Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Ed,
>

Yes, that's true.  I am only pointing that we have been able to solve 
this sort of problems.

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

> RRSIG set DO flag.

True.

> Not that this is pretty and I'm dodging the wildcards :-)

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

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/R&D manager
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------