Subject: [dnsext] CNAME response to DS

From: Sean Wells <[email-masked]>
Date: Thu, 21 Jul 2011 15:19:50 -0700

Hi,

I was unable to find anything in RFC 4035 regarding this. If I lookup a DS
and receive a CNAME response back, how should this be treated ?

- Ignore
- validate the CNAME response and assume that DS does not exist ?
- follow the CNAME and continue to look for a DS ?

What do implementations do today ?

thanks
Sean

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Jul 2011 08:35:02 +1000

> - follow the CNAME and continue to look for a DS ?

Since a CNAME + NS can't exist at the same node and DS only exists where
NS records exist you treat it as DS not existing at QNAME.
 
> What do implementations do today ?

Treat it as indicating the DS does not exist.

That said it would be clearer and safer if there were specs to say that
CNAME records MUST NOT be followed when processing DS queries.

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Jul 2011 19:42:24 -0400 (EDT)

> CNAME records MUST NOT be followed when processing DS queries.

I've seen these too. Usually these are broken setups where a wildcard for
any RRTYPE is returned with the CNAME, eg using dig -t TYPE666 would also
return a CNAME.

I don't think people mean these domains to go down with a broken DS chain :)

Paul

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Jul 2011 08:30:35 +0200

On 22 jul 2011, at 01.42, Paul Wouters wrote:

> Usually these are broken setups where a wildcard for

Broken?

If one have the following:

$ORIGIN example.com.

@ IN SOA ...
@ IN NS ...
foo.example.com. IN A 192.168.1.1
bar IN CNAME foo.example.com.

Then it will return the CNAME for the a query for TYPE666 and owner bar.example.com.

Or what part of your statement do I not understand before morning coffee...

   Patrik

---

From: Edward Lewis <[email-masked]>
Date: Fri, 22 Jul 2011 08:31:43 -0400

>NS records exist you treat it as DS not existing at QNAME.

Yes, but, what if we have three zones?

FIRST ZONE has these plus more records

$ORIGIN zone.example.

www.example.   CNAME  www.place.tld.
                RRSIG  CNAME

and SECOND ZONE has these plus more records

$ORIGIN place.tld.

www            NS     ns1.server.tld.
www            DS     keyid=123
                RRSIG  DS

and THIRD ZONE has these records

$ORIGIN www.place.tld.
@              SOA    soa-params
                RRSIG  SOA
                NS     ns1.server.tld.
                RRSIG  NS
                DNSKEY keyid=123
                RRSIG  DNSKEY
                AAAA   ::1
                RRSIG  AAAA
                NSEC   www.place.tld. SOA NS DNSKEY AAAA NSEC RRSIG
                RRSIG  NSEC

And the query begins : dig www.example. AAAA?

The answer would be

www.example.     CNAME  www.place.tld.
www.place.tld.   AAAA   ::1.

Adding in DNSSEC, I can see how this all would work out and why the 
DS query that would be needed would still make sense and work in the 
specification.

Of course, a smart verifier would just verify the original CNAME and 
then realize it has to work down a different path to validate the 
AAAA.  But when a cut point is used as a the terminal point, you can 
work it out like it's just another CNAME.

The deal is - when a domain name appears in a lookup as a result of 
being in a CNAME RDATA, it ceases to be useful as a cut point.  But 
since the DS is not in the usual place, you just have to know where 
to get it.

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

I'm overly entertained.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 22 Jul 2011 09:58:39 -0400 (EDT)

> Or what part of your statement do I not understand before morning coffee...

I saw the following

$ORIGIN example.com

@ IN SOA ...
@ IN NS ...
* IN * CNAME foo.other.com.

So every RRTYPE including DS would point to foo.other.com, but no DS
record exists at foo.other.com, only an A recor. Turned out this was
some hacked up perl-Net-DNS based nameserver (and some very questioable
domain names being used that are now dead)

Paul