Subject: Re: [dnsext] "Proof" that CNAME + DNAME is safe

From: Florian Weimer <[email-masked]>
Date: Sun, 25 Apr 2010 19:02:03 +0200

* George Barwood:

> Therefore correct resolvers cannot fail, because that would mean
> they are fundamentally incorrect, that is they would fail if the
> zone had been updated between the two queries.

If there is inconsistent data with overlapping time-to-live, resolvers
are allowed to fail queries, so I don't think this argument is correct
even from a formal point of view.

In the end, actual deployed resolver behavior trumps these
considerations anyway, especially this is about introducing a protocol
incompatibility.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Apr 2010 09:28:16 +1000

In message <B24B8008783B4536BFD00D6071300D40@local>, "George Barwood" writes:
> Florian
> 
> ----- Original Message ----- 
> From: "Florian Weimer" <[email-masked]>
> To: "George Barwood" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, April 25, 2010 6:02 PM
> Subject: Re: [dnsext] "Proof" that CNAME + DNAME is safe
> 
> 
> >* George Barwood:
> > 
> Temporal inconsistencies can arise, for example where an RRSIG references
> a DNSKEY record. This means that new keys should not be used until the old
> DNSKEY RRset has had time to expire ( or that old signatures be supplied in addition ).
> And there are other cases, e.g. a NS RRset may reference A records, that must be served
> until the old NS RRset has had time to expire, or failures can occur, etc.
> 
> But I don't see how any temporal inconsistency can arise in this case, since
> queries below the DNAME are independent of queries at the DNAME owner.
> Neither one gives any information about the other ( non-trivial statement, but I think
> it holds). The job of a resolver can be seen as obtaining an authoritative response
> to QNAME:QTYPE,  after following CNAME indirection, and that response may be cached.
> http://tools.ietf.org/html/rfc4035#section-4.5 cautions against using results from one
> response to infer facts about other queries ( although I don't rely on that here ).
> 
> Perhaps you could be more explicit about what inconsistencies could have any effect here.
> I don't see any ( but I accept that my "proof" could be seen as incomplete until all possible
> cases have been enumerated - probably by someone more expert in the DNS standard than myself ).
> 
> Well yes. But what I'm saying is that there is no incompatibility, and demonstrating how
> no such incompatibility can arise in correct resolvers.
> 
> Not setting the DNAME bit in the NSEC record when the CNAME bit is set is the key - a resolver
> could possibly reject an NSEC record with the CNAME and DNAME bits both set as bogus/invalid.
> But having solved that, I cannot see how any incompatibility can arise.

But that is exactly the NEC/NSEC3 record that MUST work.  It is
ridiculous to require the authoritative server to serve up different
NSEC/NSEC3 records and their signatures.

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, 27 Apr 2010 12:30:35 +1000

In message <66DE2F29E0C348D88A8851AE0E747819@local>, "George Barwood" writes:
> From: "Mark Andrews" <[email-masked]>
> Cc: "Florian Weimer" <[email-masked]>; <[email-masked]>
> Sent: Monday, April 26, 2010 12:28 AM
> It may be "disturbing", but why "ridiculous"?
> 
> Note that the type bitmap of a NSEC record at a CNAME is never used, since the CNAME
> redirects every type. The NSEC record is used only to prove non-existence of adjacent
> non-existent domains, never NoData conditions at the CNAME owner ( since such conditions
> cannot arise ).
> 
> So why do you say it "MUST" work? 
> 
> George

Because you should prove no DNAME to accept NXDOMAIN.  This
can require checking to see if the DNAME bit is set depending
on whether the next name is below the owner name of the NSEC
or not.

e.g.
foo.example.com NSEC foo.example.com SOA NS RRSIG NSEC
foo.example.com NSEC example.com CNAME DNAME RRSIG NSEC

So you can't remove DNAME.  You also can't remove CNAME, to prevent
spoofing away of the CNAME, as now CNAME can co-exist with DNAME.

Mark

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 27 Apr 2010 16:11:15 +0200

On 27.4.2010 08:17, George Barwood wrote:
> So back to either hoping resolvers don't fail when they see
> CNAME+DNAME set in an NSEC, or new algorithms.

George,

let's wait for my thorough testing I am planning to do, so we don't have
to hope.  Unfortunately I have only two days in work this week, so I
will probably do that in RIPE week or week after that.  That will
hopefully remove some fears of general DNS breakage.

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