Subject: Re: DNAME-update draft: revised server algorithm

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 01 May 2007 11:05:54 +0200

--On 24. april 2007 10:01 -0400 Scott Rose <[email-masked]> wrote:

> The new version (-02) of the DNAME-update draft will be posted shortly.
> In the latest version, a revised version of the server algorithm in
> RFC 2672 is found to reflect that the DNSSEC-OK bit also signals
> understanding of DNAME.
>
do current RFCs require all resolvers to understand DNAME if they set 
DNSSEC-OK?

does current deployed software for DNSSEC do so?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Tue, 01 May 2007 07:41:32 -0400

RFC4035 section 4.8 states you need to understand DNAME in order to do
DNSSEC validation.
So if someone is setting DNSSEC-OK w/o understanding DNAME they are
not DNSSEC compliant, if they are setting DNSSEC-OK w/o understanding some
version of DNSSEC they are seriously broken.

Some implementations understand DNAME w/o understanding DNSSEC so this
hack will not help them.

<chair-hat-on>

The question for the WG is:
A. Is DNSSEC-OK hack sufficient for DNAME synthesis suppression ?

or

B. Is there need for special flag for DNAME understanding ?

In meetings the sense of the room has been that a. was a good start.
The question is B needed anyway/in addition ?

         Olafur

At 01:28 01/05/2007, Harald Tveit Alvestrand wrote:

>do current RFCs require all resolvers to understand DNAME if they 
>set DNSSEC-OK?
>

---

From: Scott Rose <[email-masked]>
Date: Tue, 01 May 2007 07:43:05 -0400

> do current RFCs require all resolvers to understand DNAME if they set 
RFC 4035 talks about how resolvers and servers handle DNAME RRs.  DNSSEC 
aware resolvers MUST be able to use the RRSIG(s) over the DNAME to 
validate any synthesized CNAMEs present.  They are not required to cache 
any synthesized CNAMEs.

There is no explicit wording indicating that (it is assumed?)  The text 
does describe how to perform validation of DNAME RRs and DNAME is to be 
signaled by some sort of EDNS flag that has not been specified.  The 
DNAME update draft actually comes out and says it.  It also drops the 
requirement on servers to add the synthesized CNAMEs, since DNSSEC 
resolvers should re-synthesize rather than trust unsigned CNAME RRs.

> does current deployed software for DNSSEC do so?

Haven't tested every resolver and server, but the implementations I have 
seen do understand DNAME according to RFC 4035.  I don't know if they 
all will accept responses without synthesized CNAME RRs (and just take 
the signed DNAME RR as a valid response).

If I find some time, I might try and test some big name resolvers to see 
what they do when encountering responses with missing CNAME RRs.
Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnssec-deployment.org/
-----------------------------------------

---

From: David Conrad <[email-masked]>
Date: Tue, 1 May 2007 07:41:59 -0700

Hi,

> A. Is DNSSEC-OK hack sufficient for DNAME synthesis suppression ?

While perhaps fun to derive, heuristics to derive implicit behavior  
seem sub-optimal to me.

> B. Is there need for special flag for DNAME understanding ?

Seems to me like this would be cleaner.

Rgds,
-drc

---

From: Edward Lewis <[email-masked]>
Date: Tue, 1 May 2007 16:09:04 -0400

>Seems to me like this would be cleaner.

metoo
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 May 2007 10:16:47 +1000

> Hi,
> 
> On May 1, 2007, at 4:41 AM, =D3lafur Gu=F0mundsson /DNSEXT co-chair =
> wrote:
> While perhaps fun to derive, heuristics to derive implicit behavior =20
> seem sub-optimal to me.
> 

	Especially as "DO" does not indicate DNAME understanding.

   In order to deploy DNSSEC (Domain Name System Security Extensions)
   operationally, DNSSEC aware servers should only perform automatic
   inclusion of DNSSEC RRs when there is an explicit indication that the
   resolver can understand those RRs.  This document proposes the use of
   a bit in the EDNS0 header to provide that explicit indication and
   describes the necessary protocol changes to implement that
   notification.

	EDNS version 1 shopping list.

	* DNAME understanding.

	* Allow NXRRSET for QUERY.
		See RFC 2308 for why this is useful.

	* Allow NOTAUTH for QUERY.
		It's a better error code than REFUSED when you don't
		serve the zone for AXFR/IXFR.
		It's a better error code than REFUSED for auth servers
		that get queries for names that are not under any of
		the zones they serve.

	We need to exercise EDNS version agility.

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

---

From: David Conrad <[email-masked]>
Date: Tue, 1 May 2007 17:41:43 -0700

> 	We need to exercise EDNS version agility.

Why?  You have 15 more bits in the header...

Rgds,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 May 2007 11:09:57 +1000

> Why?  You have 15 more bits in the header...

	Because every time anyone suggest bumping the EDNS version
	there are complaints that "this may not work".  It's time to
	kill the FUD by bumping the version.  That was the intent
	of having a version number in there in the first place.

	Mark

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 May 2007 02:21:19 +0000

> Why?  You have 15 more bits in the header...

because i screwed that pooch with "must be zero" logic.  sra was trying
to fix this with his edns0_5 work.  at this point we have to allocate a
new version number to use the unused bits, and with that version number
we ought to say "must be ignored unless nonzero and understood" or similar.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 May 2007 02:19:15 +0000

> 	We need to exercise EDNS version agility.

sounds good to me.

---

From: Scott Rose <[email-masked]>
Date: Thu, 03 May 2007 07:46:17 -0400

>> Hi,
    *snip*
> 	We need to exercise EDNS version agility.

DNAME-update really isn't the place to be defining EDNS1 if it may 
entail all of those features.  That would require a new document.

If that is the case (EDNS1 is not just "signals DNAME understanding") 
than the DNAME-update draft will have to wait until the EDNS1 draft is 
mature enough, or drop the current text regarding signaling and say that 
CNAME synthesis must still be done until updated in a following document 
(EDNS1 for example).

Scott

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 May 2007 14:08:17 +0000

> DNAME-update really isn't the place to be defining EDNS1 if it may entail
> all of those features.  That would require a new document.

i'd be happy to oblige.

> If that is the case (EDNS1 is not just "signals DNAME understanding") than
> the DNAME-update draft will have to wait until the EDNS1 draft is mature
> enough, or drop the current text regarding signaling and say that CNAME
> synthesis must still be done until updated in a following document (EDNS1
> for example).

either way is fine with me.

---

From: Peter Koch <[email-masked]>
Date: Thu, 3 May 2007 21:16:01 +0200

> A. Is DNSSEC-OK hack sufficient for DNAME synthesis suppression ?

overloading existing flags is bad, but as a hack it might be sufficient.
I'm still worried about the DNAME RR appearing in the response regardless,
though.

> B. Is there need for special flag for DNAME understanding ?

So, EDNS is hop-by-hop, where DNAME "understanding" needs to be end-to-end?

-Peter

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 May 2007 09:19:15 +1000

> So, EDNS is hop-by-hop, where DNAME "understanding" needs to be end-to-en

	DNAME understanding doesn't need to be end to end.  A client
	that is is behind a non DNAME aware server will see the
	CNAME.

	For DNSSEC each hop has to be DNSSEC aware and hence DNAME
	aware when DNSSEC aware means much more that it can accept
	DNSSEC records.

	Mark