Subject: Re: [dnsext] Questions about RRSIG queries

From: Paul Vixie <[email-masked]>
Date: Mon, 01 Mar 2010 08:18:32 +0000

> From: Mark Andrews <[email-masked]>
> Date: Mon, 01 Mar 2010 14:28:29 +1100
> 
> Does it matter?  No sane validator will ask for RRSIG records.
> RRSIG records are useless without the records that they sign.

i think there's a real need for validation to be able to live in a stub
that's behind a dnssec-unaware recursive, or in a recursive that's behind
a dnssec-unaware forwarder.  to do that we'll need to be able to ask RRSIG.

i'd really appreciate some drafting and testing in this area, fwiw.  to
get dnssec deployed we'll have to work through paths where edns works and
where unknown rr's are properly handled, but where validation only occurs
in or near the initiator.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 01 Mar 2010 20:00:16 +1100

> a dnssec-unaware forwarder.  to do that we'll need to be able to ask RRSIG.

Trying to put data and meta data back together is a recipe for
frustration.  It doesn't work reliably.  It will result in endless
bug reports.  We really don't want to go there.

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

---

From: [email-masked]
Date: Mon, 1 Mar 2010 09:37:20 +0000

> bug reports.  We really don't want to go there.

	well - you don't have to ... others will, since there is
	a need.

> > in or near the initiator.

	right Paul...  thats where some of us were headed.
	and after a short respite, headed back in that direction.

--bill

---

From: Mark Andrews <[email-masked]>
Date: Mon, 01 Mar 2010 20:55:47 +1100

> 	and after a short respite, headed back in that direction.

Well if you want to pre-publish RRSIGs and post-publish RRSIGs to
make it work reliably, go ahead.  Most people have enough trouble
with the timing of DNSKEY and DS changes without having to apply
that logic to every single change they make to the zone.

DNSSEC is NOT designed to work in such envionments.  It a waste of
engineering resources trying to make it work in such envionments.

---

From: "George Barwood" <[email-masked]>
Date: Mon, 1 Mar 2010 13:13:15 -0000

----- Original Message ----- 
From: <[email-masked]>
To: "Mark Andrews" <[email-masked]>
Cc: "George Barwood" <[email-masked]>; <[email-masked]>
Sent: Monday, March 01, 2010 4:52 AM
Subject: Re: [dnsext] Questions about RRSIG queries

> On Mon, Mar 01, 2010 at 02:28:29PM +1100, Mark Andrews wrote:
>> 
>> In message <8540AFD8C8DD470DA74F5992C49F2168@localhost>, "George Barwood" write
>> s:
>> > Could anyone clarify how explicit queries for RRSIG are supposed to =
>> > work?
>> 
>>  A
> of course it matters. a sane resolver should be able to
> ask for RRSIG records independently of the records 
> the sigs belong to.
> 
> resolver != validator.
> 
> I can certainly think of at least two reasons for 
> making explicit queries.

I'm with Andrew here, I cannot think of any reason to make an explicit RRSIG recursive query.
That might be a lack of imagination on my part.
Apparently it will yield unpredictable results with current implementations.
Please give your reasons.

---

From: [email-masked]
Date: Tue, 2 Mar 2010 02:31:44 +0000

On Mon, Mar 01, 2010 at 08:55:47PM +1100, Mark Andrews wrote:

> Paul and then Bill

	no real need for that either mark.

> engineering resources trying to make it work in such envionments.

	design or your implementation?  I don't see the design 
	restriction.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 1 Mar 2010 22:38:19 -0500

It would be a good idea to specify what is returned for QTYPE=RRSIG 
even if there's no sane reason for it ever being queried.  (As in - 
there's also no sane use for QTYPE=ANY except debugging.)

I know in the past we toyed with queries for RRSIG.  We thought they 
might help get DNSSEC through devices that otherwise blocked DNSSEC. 
Ultimately we found that if a device wouldn't let an RRSIG through, 
it probably also didn't handle unknown types correctly, hence a query 
for RRSIG still wouldn't pass the records on.  There's no way to 
force DNSSEC (or any extension) through a device that clamps down to 
the DNS protocol it knows. If the environment is "unreliable," all 
bets are off.

Still, if it is unclear when an RRSIG query arrives, the 
specification is deficient.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Mar 2010 16:58:09 +1100

> 	no real need for that either mark.

Do you really want examples showing where it won't work if you don't
do that?
 
> 	design or your implementation?  I don't see the design 

Design.

Mark

---

From: [email-masked]
Date: Tue, 2 Mar 2010 06:11:05 +0000

> > 	design or your implementation?  I don't see the design 

	ok... plz show chapter/verse where it is illegal to do 
	QUERY=RRSIG?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Mar 2010 17:31:14 +1100

> 	ok... plz show chapter/verse where it is illegal to do 

I didn't say the query wouldn't work or they are illegal.  I said
they are pointless.  I said DNSSEC wouldn't work reliably.  You
will get validation failures if you make seperate queries for the
data and signatures even if you are querying only one authoritative
server for the zone and not working though any caches.

Reliable DNSSEC validation depends on the data and signatures staying
together.

DNSSEC validation is not designed to work when the data and signatures
get seperated.  It's just good luck when it does and yes with most
zones most of the time you will be lucky as most zones don't change.
However for every change there will be a time span where validations
will fail for the data that changes when you make seperate queries
for the data and its signatures.

Mark

---

From: [email-masked]
Date: Tue, 2 Mar 2010 06:59:41 +0000

> server for the zone and not working though any caches.

	the question was - can we do QUERY=RRSIG?  and you have 
	jumped to the conclusion that such is pointless and would
	cause DNSSEC to not work reliably.  I posit its -not- 
	pointless and the rational for doing such queries may have 
	nothing to do with validation or DNSSEC perse. and since 
	its not illegal... :)

	as mentioned perviously, a resolver is not always a validator
	and the converse is true as well, a validator is not always
	a resolver.

> Reliable DNSSEC validation depends on the data and signatures staying

	for validation - sure.  the two datum need to be linked somehow.
	the kicker here is the presumptive timing gap (or lack thereof)
	if the data and sigs "stay together" - being shipped around in 
	a portmantu - the timing gap is small.  if they are stored in the
	same cache - small.  If they are in distinctly different caches?
	maybenot.  If the timing gap is too large then uncertainty creeps 
	in.  how much uncertainty is acceptable to you?  

> get seperated.  

	unfortunately the data and sigs may only get bound at the validator
	at "run time"  -  some of the newer hardware just can't do both
	so will end up outsourcing either validation or resoultion or both.

	but I am not saying we should put DNSSEC on hold again... its "good
	enough" for many things now. but some of the edges are frayed and 
	need to be stitched in.