Subject: draft: resolver-application interface

From: Miek Gieben <[email-masked]>
Date: Thu, 12 Feb 2004 15:44:44 +0100

Hello,

During the LCWS workshop of a few weeks ago the topic was also discussed: what
does an application wants/needs to know from a secure aware resolver. I then
said I was working on a draft trying to initiate and focus that discussion.

During the last few days this topic has also (sort of) sprung up on the
namedroppers ML. I'm not sure the draft is dnsop or dnsext material, but
I'm posting it here as I feel we were already discussing these sort of
things.

It is still a *very rough* draft, but I didn't want it to delay any more
than it already has.

Authors:  
   Gilles Guette, Olivier Courtay and Miek Gieben

Abstract:
   This document describes an interface between a DNSSEC aware resolver
   and an application. This interface will define which kind of
   information a DNSSEC aware resolver is able to send back to an
   application. The basic question we want to answer is: "What does an
   application wants to know from a secure aware resolver?".

   In section Section 4 we define an error bit array. The secure aware
   resolver will set specific bits in the array. With the added 
   information in this error array, the application can have extra 
   control on what to do with bogus data.

   This document is written in the hope that it will lead to a
   discussion within the IETF on the resolver-application
   interaction(s).

Where: 
   http://www.nlnetlabs.nl/dnssec/draft-gieben-resolver.txt

grtz
      Miek
--
...all white space is equivalent except in certain situations...
- C99 Standard -- http://www.vmunix.com/~gabor/c/draft.html

--
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: bill <[email-masked]>
Date: Thu, 12 Feb 2004 07:30:42 -0800 (PST)

thanks.   there was an old thread on this topic that Michael Richardson
and myself (with some others) worked on last year. After the LCWS ws, i
promised myself to dig it back up... looks like you beat me to it. :)

---

From: Suresh Krishnaswamy <[email-masked]>
Date: 23 Feb 2004 14:14:30 -0500

Miek,

I think this draft is a good start towards defining the 
interface between the resolver and the application for 
signalling error and status information.

You've already covered some of the following error codes; 
I've tried to disambiguate (for my own reference mostly) 
the meaning associated with some of them.

XX	UNSECURE - No signatures are present, not required 
	to be present either (provable non-existence of parent 
	DS, no local trust anchor)

XX	INDETERMINATE - signatures present, DNSKEY record 
	present, but no authentication chain could be found 
	that would allow validation of the signatures 
	(missing or different local trusted anchor, provable 	non-existence of
parent DS, or parent DS does not 
	cover the zone DNSKEY). 
	Q. Is this same as bit field 9 -- delegation problem DS/KEY ?

00	NODNSKEY - signatures present, but no DNSKEY could be 
	retrieved for the zone

05	BOGUS - some signature was required to be present 
	(parent DS said so, or by local trusted anchor 
	setting),the sig was present but it failed validation

01	NODS - DS should have been present in the parent 
	(some NSEC told us so) but the DS record 
	could not be retrieved. 

02-03 	only relevant to the signature verification 
	operation directly -- so these error codes indicate 
	the absence of NSECs, SIGs for the name being directly 
	queried for (and not the absence of NSECs, SIGs that 
	would otherwise tell us that the parent DS is missing 
	for example).

Is the above interpretation same as what you had envisioned? 

I also seemed to think that there was a need for the following
additional status codes as well:

XX	NOCLRPATH - one or more intermediate name servers
	does not support DNSSEC 

XX	LOCPOL - some local policy decision has contributed
	to the resultant set of RRs/flags 

An open question is whether the error/status codes should 
actually be defined as extended RCODEs as opposed to a bit array.   

Suresh