Subject: Re: DNSSECbis clarifications: QTYPE ANY & "DNSSEC RRSets"

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Feb 2006 18:00:20 +0000

#   Also: the DO bit was introduced to protect "innocent" resolvers from
#   DNSSEC RRs they might not expect or understand.
# 
# Opinions?

i think a security aware server should elide dnssec metadata unless DO is set,
whereas we already know that a security-nonaware server will not do this and
will never do this.

we can hope that a security non-aware server will never see dnssec metadata
but we know this isn't true either.

--
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: Mark Andrews <[email-masked]>
Date: Tue, 21 Feb 2006 09:26:01 +1100

> but we know this isn't true either.

	I'd expect to see the records in the answer section as a
	client making a * query is expecting to see records it
	cannot decode.  A RFC 1035 client cannot decode a RP record
	but no one here would say don't sent the RP.

	I would not expect to see the DNSSEC records in the additional
	and authority sections.

	Asking * to a parent server with a signed parent zone of a
	signed child zone gets more interesting.  DS, NSEC and RRSIG
	should be in the answer section.  There should be a referral
	containing the NS records.  Again there would be not DNSSEC
	records in the authority or additional sections.

	Mark

;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.2 <<>> dv.isc.org any
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37013
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 7

;; QUESTION SECTION:
;dv.isc.org.			IN	ANY

;; ANSWER SECTION:
dv.isc.org.		3600	IN	SOA	bsdi.dv.isc.org. marka.isc.org. 2006021500 86400 21600 2419200 86400
dv.isc.org.		60	IN	RRSIG	DNSKEY 5 3 60 20060316195737 20060214195737 37083 dv.isc.org. WtxeB8M2lAkrXIpdn/X2F0d8Zlx0UOXEyBkdVN6w+mX9KhO2hWf8vZ5C JHPGFoNEXQ7NEBuVJbUcntNKWXQR7QMBTE7LV5vOcbZLoyRR4aI1vwjz mC/9X9ODdZ9UQt/kDOaqKmwtrMtepbRmkw7MXjSNbO4xhJ3AsbPOdNrj UzV0rHfR/XHe9eD+NbDPCGXYF/hSqfjDv8iFx12JLAX3u3ymZ9FYhb5v xAtQBQO1KtiH9i5mPY7AVOxhtppYY70YB5VoBNvCC1uwfmI4d2tFnfcv mzfj1M4f1C3PqscAlsWNCWMfzezX3xW53mkpDiQHE1d3AWrH6R+S8wq/ rtgZ3Q==
dv.isc.org.		60	IN	RRSIG	DNSKEY 5 3 60 20060316195737 20060214195737 52595 dv.isc.org. n2Xn9e300LIJcVhXXi4ZTFEpYDZT6ZSdjQdlWwc5HBbPyRSO7tDIbP78 yayc6dKyX19Bj06k47kbdiXeaCNkEgyNhtpKHeaxCd7lCQGZLaXSAz4m 7XHneELIgylLSGNCM87AHSzRzISsVSpzlcpyDVVUz/TxdxAnHM/lHNYe 9WU=
dv.isc.org.		60	IN	DNSKEY	257 3 5 AQO/WTD1QT9aOKORz8l7lcWgghCH0E+cxr3cnm7v0oLA0NLMFa1NzZMt PVl6AGWu+jDo0y/y37lWUiNK9FLcmxzTvm2BgWHoZ3/aQcdxkR+SDIxB Ru3HlGGZcrk80lT77OBrYjiJmImQt9cLefG0TxzwYbWEX2AwYCMil/Gf Fia11Cu3HC2JER/Z7INIYiXgX42FWQtqYqSwl20TkH1NLGoWXDQZEcUM BG/dz+o9JTTalQkIcohhxdJ9Bd1Yceq+4hEdN25mMvL2us8nJXa8nqry TEZ2iAce2RxYjhEAuZ4Dg0u0hgCvhOkEyf/M3erv1RkdB1UPMLgh7xiY cw5K87yd
dv.isc.org.		60	IN	DNSKEY	256 3 5 AQPGP80zt8pQS5xVaaaD054XBet8sCKaYZ9WrnYyuznqNXkS91j6qqHu w7Y9kKAVsFoWfNw0CpahdIJIhUPFM1JRJtXhNy1cg9Ok3kBnN+fwCe2L Y3qOtweFbL9bSjgolQWr42AlFOjZnJVW1cECgVBfinKHBIEIIwIdHGGu LyIQaQ==
dv.isc.org.		86400	IN	RRSIG	NSEC 5 3 86400 20060316195737 20060214195737 52595 dv.isc.org. SICQlRWLkkm246Hd6e1YgU5Qq32zJAtOUjWuw9wmq14Qx9FKdjYS1xHu gYZ0cNj7bgzH0zg5Ke5oJ7g+VTkbIzXVO1wLd3nBKiKmnIIuUM97AAAd DdSrqpg8txEZr3nad8xN48hUllntPjZRM9dRuEulFcTPARUk+t5tTwP5 kbM=
dv.isc.org.		86400	IN	NSEC	_kerberos.dv.isc.org. NS SOA MX RRSIG NSEC DNSKEY
dv.isc.org.		86400	IN	RRSIG	MX 5 3 86400 20060316195737 20060214195737 52595 dv.isc.org. logv6ZVCD/TCjSmu+UIy9Fdg/S4rtZvVtbKpJGLos8RnfONkHYH6bPbe 8u5GzTJlB+MiGw55vl9JdXslNxsOhSyal3pPg+beboWiEo7W6D0BlDgQ VXb48fpHiislIySd/Hu+0fzh9aXWLdOVP9R/XxOiO2cFEdxFUX2jbht+ NGw=
dv.isc.org.		86400	IN	MX	0 bsdi.dv.isc.org.
dv.isc.org.		86400	IN	RRSIG	NS 5 3 86400 20060316195737 20060214195737 52595 dv.isc.org. qdPqO3dr2oPYD+baCWbJ7oQ8WBQVfeWjPvPy08tllITBz/0q+QS4W6Ec IbrzRV77hJfu6GoAcbiG55SqScmrFJQ46VIP5x2CHOGp4gupjSaCH7e+ RZojBdHPC6OwRnePmx4/z/X2bJkPquGT9sOvIFYesPKgaTklwrxR1tMK 4cA=
dv.isc.org.		86400	IN	NS	drugs.dv.isc.org.
dv.isc.org.		86400	IN	NS	bsdi1.dv.isc.org.
dv.isc.org.		3600	IN	RRSIG	SOA 5 3 3600 20060316195737 20060214195737 52595 dv.isc.org. kyhBxS3oR8LApMHb/G5I7TYbRPqVaJYz2B3qcfUYo6Bpq/RKEvgtsuyJ iUboj0Fwdq7dru0EN0Go5fdrbx9ajBj6qALykH14h9jabjw1RI7nA28I OmLBUsMELWkgUkRLBXiujN912OQYHYRiEQ7E/oC72z3lJyAOa6pPlOs9 Zuk=

;; ADDITIONAL SECTION:
bsdi.dv.isc.org.	3600	IN	A	192.168.191.233
bsdi.dv.isc.org.	3600	IN	A	220.237.98.197
bsdi1.dv.isc.org.	86400	IN	A	192.168.191.233
drugs.dv.isc.org.	86400	IN	A	192.168.191.236
bsdi.dv.isc.org.	86400	IN	AAAA	2001:470:1f00:ffff::5a1
bsdi.dv.isc.org.	86400	IN	AAAA	2001:470:1f00:820:2e0:29ff:fe19:c02d
drugs.dv.isc.org.	86400	IN	AAAA	2001:470:1f00:820:208:74ff:fe9f:eeae

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 09:15:29 2006
;; MSG SIZE  rcvd: 1890

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

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 21 Feb 2006 12:30:22 +0200

Peter Koch wrote:
> during a discussion at a different venue the question arose whether or not
> the "DNSSEC RRs" should be included in a response to an ANY query with DO=0.

My take is that they should be included.

> con:
[...]
>      If the DO bit in an initiating query is not set, the name server side
>      MUST strip any authenticating DNSSEC RRs from the response but MUST
>      NOT strip any DNSSEC RR types that the initiating query explicitly
>      requested.
> 
>   The important part is the last full sentence.

IMO, an ANY query should be considered "explicitly requesting" all
records at the query name.  Also, these DNSSEC RRs are not
"authenticating" DNSSEC RRs in the sense that they do not authenticate
the response, but are simply part of the unauthenticated response data
comprising the complete set of records at the query name.

>   Also: the DO bit was introduced to protect "innocent" resolvers from
>   DNSSEC RRs they might not expect or understand.

As Mark said, a client sending an ANY query must expect to receive
records of arbitrary types in the answer section even without DNSSEC.
-- 
Andreas Gustafsson, [email-masked]

---

From: David Blacka <[email-masked]>
Date: Tue, 21 Feb 2006 10:34:31 -0500

On Feb 20, 2006, at 12:41 PM, Peter Koch wrote:

> Colleagues,
> pro:
>   section 3 of RFC 4035 (top of page 9) says:
>
>      A security-aware name server that receives a DNS query that  
> does not
>      include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
>      treat the RRSIG, DNSKEY, and NSEC RRs as it would any other  
> RRset and
>      MUST NOT perform any of the additional processing described  
> below.
>
>   "treat ... as it would any other RRset" would support ANY  
> covering those,
>   which is consistent with RFC 3225 (which explicitly listed ANY).
>
>   Also, this would be consistent with RFC 3597, not requiring special
>   handling for "unknown" types.
>
> con:
>
>   RFC 4035, 3.2 says:
>
>   3.2.1.  The DO Bit
>
>      The resolver side of a security-aware recursive name server  
> MUST set
>      the DO bit when sending requests, regardless of the state of  
> the DO
>      bit in the initiating request received by the name server  
> side.  If
>      the DO bit in an initiating query is not set, the name server  
> side
> Opinions?

My reading is that the DNSSEC types are included in the ANY response.

In my reading, section 3.2.1 doesn't conflict with the earlier  
section.  In this case, the DNSSEC types at the qname were  
"explicitly requested", and thus fall under the "MUST NOT strip"  
clause in that last full sentence.

However, I will readily admit that qtype=ANY and the adverb  
"explictly" don't go together terribly well.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Sam Weiler <[email-masked]>
Date: Tue, 21 Feb 2006 11:54:11 -0500 (EST)

On Mon, 20 Feb 2006, Paul Vixie wrote:

> i think a security aware server should elide dnssec metadata unless 
> DO is set, whereas we already know that a security-nonaware server 
> will not do this and will never do this.
>
> we can hope that a security non-aware server will never see dnssec 
> metadata but we know this isn't true either.

Following the same logic, should modern name servers strip out other 
new record types, in hopes of protecting innocent (and broken) 
resolvers?

As Mark points out, the general answer is "no" -- we're willing to let 
a resolver that asks for ANY get unknown RR types and, if it can't 
cope with the answer, we're willing to let it break.  I don't see any 
need to treat the DNSSEC records differently.

-- Sam

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Feb 2006 17:52:00 +0000

# > i think a security aware server should elide dnssec metadata unless DO
# > is set, whereas we already know that a security-nonaware server will not
# > do this and will never do this.
# >
# > we can hope that a security non-aware server will never see dnssec
# > metadata but we know this isn't true either.
# 
# Following the same logic, should modern name servers strip out other new
# record types, in hopes of protecting innocent (and broken) resolvers?

no.  i was mistaken, but not about that.  i thought there was a way to
signal dnssec awareness that wasn't DO=1.  if there were, then i'd say
any requestor who could signal dnssec awareness and also signal that
dnssec metadata wasn't wanted, shouldn't get it, even on qtype=ANY.

# As Mark points out, the general answer is "no" -- we're willing to let a
# resolver that asks for ANY get unknown RR types and, if it can't cope with
# the answer, we're willing to let it break.  I don't see any need to treat
# the DNSSEC records differently.

i wasn't worried about seeing something that wasn't understood, i was
looking to optimize message size and avoid truncation/fragmentation/tcp.

---

From: David Conrad <[email-masked]>
Date: Wed, 22 Feb 2006 18:36:42 -0800

Hi,

As someone who was somewhat involved in the DO bit thing (and  
apologies and all that)...

> My take is that they should be included.

Or, perhaps put differently, there should be no special treatment of  
DNSSEC RRs in response to an ANY query, regardless of the setting of DO.

> records at the query name.

Right.

> Also, these DNSSEC RRs are not

It might be argued that in a world in which DNSSEC matters, ANY  
queries are pretty pointless.

>>   DNSSEC RRs they might not expect or understand.

Yes and no.  It was also introduced to try to reduce the impact on  
servers who would otherwise have to respond with data that no one  
cared about.

> records of arbitrary types in the answer section even without DNSSEC.

(Mark and Andreas agreeing?  Wow.  :-))

Rgds,
-drc

---

From: Peter Koch <[email-masked]>
Date: Thu, 23 Feb 2006 20:12:36 +0100

Thanks for all the responses so far. Just in case my question was neutral,
i support the "pro" side. The "con" may identify himself :-)

> 	I would not expect to see the DNSSEC records in the additional

Agreed, my question was imprecise. Suggest the follwoing text for the
clarifications document:

ANY queries
	When responding to ANY queries without the DO bit set, authoritative
	or recursive servers MUST include in the answer section any DNSSEC
	specific RRSets that are present for QNAME, just as they would for
	any other RR type.
	Since no DNSSEC processing is requested, DNSSEC specific RRSets MUST
	NOT appear in the authority or additional section.

> 	signed child zone gets more interesting.  DS, NSEC and RRSIG

Yes, that touches a whole lot of different issues.

> 	containing the NS records.  Again there would be not DNSSEC

Which NS RRSet in this case?

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Fri, 24 Feb 2006 11:37:19 +0800

>the "DNSSEC RRs" should be included in a response to an ANY query with DO=0.
...
>   3.2.1.  The DO Bit
...
>  (IF)the DO bit in an initiating query is not set, the name server side

Don't treat the DNSSEC records that are unknown differently than 
other unknown records. ;)

>Opinions?

I think the latter is "pro" as well.  DNSSEC records included here 
explicitly patch the query type, they are not authenticating.  (A 
"QTYPE=any" explicitly matches all type codes.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: Mike StJohns <[email-masked]>
Date: Sat, 25 Feb 2006 15:41:15 -0500

Read all the current responses to this thread - but didn't go back 
into prehistory.

OK - depending on the resolution for NSEC3 and type code rollover -

Do you need a specific "DO" bit for each flavor of DNSSEC?  Or if an 
RRSet is signed by DNSSECold (SIG), DNSSECcurrent(RRSIG) and 
DNSSEC(NSEC3SIG) are all of these returned for "DO"?

Mike

At 12:41 PM 2/20/2006, Peter Koch wrote:
>      A security-aware name server that receives a DNS query that does not
>      treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
>      MUST NOT perform any of the additional processing described below.
>
>   "treat ... as it would any other RRset" would support ANY covering those,
>      The resolver side of a security-aware recursive name server MUST set
>      the DO bit when sending requests, regardless of the state of the DO
>      bit in the initiating request received by the name server side.  If
>      the DO bit in an initiating query is not set, the name server side