Subject: Re: [dnsext] Reminder: two WGLC closing in one week

From: Florian Weimer <[email-masked]>
Date: Thu, 02 Oct 2008 10:38:29 +0200

* Mark Andrews:

>> DO necessarily implies UD because the synthesized CNAME is not signed
>> and thus not visible to a DNSSEC client (section 3.1).
>
> 	DO indicates that you want the DNSSEC records.

DO was originally conceived as "intent to validate".  It's not used
this way, though.

> 	UD indicates that you don't want the synthesised CNAME.
>
> 	There are cases where you don't want DO to imply UD.
> 	Think humans reading the output.

If UD is debugging-only, I don't think it's worth the effort.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

--
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: Olafur Gudmundsson <[email-masked]>
Date: Thu, 02 Oct 2008 11:01:12 -0400

<DNSSEC-historian-hat=on>
>DO was originally conceived as "intent to validate".  It's not used

DO was designed to address two issues:
- Protect DNSSEC-ignorant resolvers that failed when they saw 
"unknown" RR types.
- Keep answers smaller for DNSSEC ignorant queriers.

When DO was proposed, someone observed  "DNSSEC is only for consenting adults"

>If UD is debugging-only, I don't think it's worth the effort.

UD is an exit plan from "synthesize CNAME forever" as the old exit plan
"new version of EDNS" is not on the horizon.
There are actively maintained non-DNSSEC DNAME-aware resolvers
out there and these resolvers can send queries with DO=0 and UD=1.
One of the objections from for placing DNAME records
in the root zone was the "CNAME synthesis overhead".

         Olafur

---

From: Edward Lewis <[email-masked]>
Date: Mon, 6 Oct 2008 12:25:06 -0400

>DO was originally conceived as "intent to validate".  It's not used

No, "DO indicates that you want the DNSSEC records" is accurate.

We (= the group that cobbled DNSSEC into BIND 8) stood up a name 
server before the DO bit was invented.  After not hearing from the 
government agency that was funding the work on DNSSEC for a few days 
we realized that something was amiss.  It turned out that we were 
responding to A record requests with responses enlarged by the DNSSEC 
records and the funding agency's firewalls were rejecting all traffic 
to port 53 over a certain size.  This "eating our own dogfood" 
experience led to the DO bit.

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

Never confuse activity with progress.  Activity pays more.

---

From: [email-masked]
Date: Mon, 6 Oct 2008 16:43:17 +0000

> experience led to the DO bit.

	it was a fine way to reduce email traffic. :)

	and shows the wisdom of actually "eating our own 
	dog food".

--bill

---

From: David Conrad <[email-masked]>
Date: Mon, 6 Oct 2008 11:52:40 -0700

Hi,

> No, "DO indicates that you want the DNSSEC records" is accurate.

As someone with some minor involvement in the definition of DO, I can  
say that I actually _intended_ it to signal "intent to validate".  It  
honestly never occurred to me that people would request DNSSEC-related  
RRs with no intent to validate them.  The fact that BINDv9 hardcodes  
DO on, even if trust anchors aren't configured and regardless of the  
state of the multiple variables you have to set to turn on DNSSEC in  
BIND, came as something of a surprise.

"Oops.  My bad."

> After not hearing from the government agency that was funding the  
> work on DNSSEC for a few days we realized that something was amiss.   
> It turned out that we were responding to A record requests with  
> responses enlarged by the DNSSEC records and the funding agency's  
> firewalls were rejecting all traffic to port 53 over a certain  
> size.  This "eating our own dogfood" experience led to the DO bit.

That was part of it.  There were also resolvers out there at the time  
that did ... questionable things if you supplied them with RRs they  
didn't understand (some version of Windows NT DNS server, IIRC).  And  
there was some concern that the root servers might be adversely  
impacted by having _all_ of their responses increase by 3 to 6 times.

Regards,
-drc