Re: dnssec: resolver - application communication

[Matt Larson <mlarson@verisign.com>]

On Tue, 11 May 2004, Michael Richardson wrote:
>   I'm not concerned about the co-located forwarder being malicious.
>   The key thing is that I want to avoid doing the work (and debugging
> the code) in multiple places. I just want information for the
> admin/audit-log, not for independant verification.

Michael,

It sounds like you're arguing for a richer signaling mechanism between
security-aware iterative-mode resolver and recursive-mode resolver.  I
have been in the "AD bit, SERVFAIL sucks" camp for some time and a
voice crying for something else.  I think some additional RCODEs (or
some other mechanism) to communicate DNSSEC validation status are
necessary and inevitable.  One of these days I'll just break down and
write an I-D.

I can think of at least three different classes of
resolver/application requirements that the DNSSEC needs to
accommodate:

1. Legacy: "I don't know anything about DNSSEC and I don't really
   care.  Just protect me from the bad guys by never giving me
   obviously bogus data.  SERVFAIL is OK by me."

2. DNSSEC-aware and compact: "I know about DNSSEC and want to take
   advantage of it, but I don't want to be encumbered with a
   full-blown validator.  Just give me some visibility into the
   upstream validation process so I can communicate more status to the
   user.  Of course, I realize I need to do some kind of transaction
   security to protect the response on the last hop from upstream to
   me."

3. DNSSEC-aware and paranoid: "I know about DNSSEC and want to do all
   the validation myself.  I'll either perform my own iterative
   resolution by sending RD=0 queries to authoritative name servers or
   I'll send RD=1, CD=1 queries and hope for the best from the local
   iterative-mode resolver, depending on the needs of the application,
   capabilities of the local DNS infrastructure and whim of the
   implementor."

We won't know which apps fall into which classes until we get some
experience.  But I absolutely believe there will be a class #2 and
corresponding need for better signaling.  The alternative is pushing
everybody into classes #1 and #3 (because, let's face it, today's #2
with AD/SERVFAIL is not adequate).  Many of those applications that
need DNSSEC and would have been happy as #2 will be forced to #3 and
will end up doing their own validation, which is just not necessary or
prudent in every case.  In other words, let's have the protocol be
rich enough to offer reasonable choices to application developers.

Matt