Re: dnssec: resolver - application communication

[Edward Lewis <edlewis@arin.net>]

At 15:23 +0200 5/10/04, Miek Gieben wrote:
>So basically it comes down to answering the question:
>
>       * Must applications know the security status of DNS answers? *

Here we go again...

After reading the thread - I'd say quickly, but youse guys do write a 
lot - I'd thought I'd offer these perspectives.

One of the lessons of the SIKED BoF (Spring 2002 IETF) was that it's 
perilous for the DNS community to speak for the applications 
community.  To keep this short, I'd think about approaching the Apps 
AD's (Scott Hollenbeck and Ted Hardy) to see if there's something 
architectural to say about this topic.  I.e., where are the IETF 
applications efforts going and how does DNSSEC factor in.  Some 
applications explicitly mention DNSSEC, others are suspiciously 
silent on the topic.

The question above is not binary.  Under the principle of "don't tell 
me anything I can't deal with" it's a waste to over inform 
applications that can't use the information.  Under the principle of 
"I need to know how to react in a crisis" there's a need to reveal as 
much as possible.  These principles contradict, and applications 
individually adhere differently to them.

 From the origin of time of DNSSEC (which, contrary to Miek's comment 
was not before he was born or "around") the point of DNSSEC was to 
verify that data could travel from an DNS administrator's signer to a 
master server, slave server, cache, and up to something doing 
validation in a way that was identifiably good or bad.  So - it makes 
sense for DNSSEC to have a binary outcome (it made it, it didn't make 
it) and for the overloading of SERVFAIL.  (Data that doesn't make it 
is a "service failure.")

I know that the above will rankle a lot of folks.  But wait, there's 
more to be mad at me about.  (And not just for things DNS.)

Let's keep separate the debugging of an application and the debugging 
of the DNS.  Let's throw out the whole thing of transitive trust and 
mistrust.  Let's leave debugging to debugging devices and dedicated 
tools.

An application ought to know strictly whether it got the info from 
DNS or not.  If an application cares how DNS arrived at the answer, 
then the application has assumed a debugging role.  I stop thinking 
of the application as an end-user, GUI-attached application at that 
point and start thinking of it as a debugger.

DNS has never made statements on the "quality" of the answer, just 
"here it is."   If an application wants more, it'll have to do some 
diagnostic research.

Debuggers need to retrieve diagnostic information.  (Do we want to 
standardize the access of diagnostic information?)  This can be done 
by examining the logs or by some interactive approach, such as 
performing a "verbose reporting of the validation chain."

Once into debugging, the network isn't this smooth end-to-end beast. 
It becomes fragmented into operational domains.  I.e., application 
data is insulated from the lower layers, but debugging information is 
intended to reveal the internals, including what has happened along 
the way.  Perhaps there is something folks like to keep hidden in 
their infrastructure.

What I'm rambling towards is a divide and conquer strategy.  One, let 
the Apps community tell the DNS what it needs (requirements).  Two, 
separate normalcy from debugging.

I haven't gotten to operations and operators yet.  These groups 
essentially rely on the debugging information.  Say IT is hit with 
"why does ssh bank.example.com not work - it says DNS failure".  The 
answer is for the IT department be able to determine what resolver 
returned the error and then have access to the resolver to check the 
logs.

I'd settle for much clear logs out of the BIND validator right now. 
If the logs were better, I think the problem ahead for applications 
would be clearer.  'Course, I'm not blaming ISC for not having good 
logs, I don't think the workshops have put enough emphasis on 
determining what makes a good activity log.

So - let's do a workshop sometime on suggesting good, clear logs...

PS - About SERVAIL.  I've argued that it's overloaded to the 
detriment of debugging in workshops.  I've found that I can easily 
separate DNSSEC SERVAILs from DNS SERVFAILs by doing a "dig ... 
+norec" - i.e., by using a debugging tool already available.  In a 
way, SERVFAIL is overloaded, but not fataly. On the other hand, to 
the application - whether its a DNS or DNSSEC failure, the DNS 
service had a failure.

If an application wants to "route around" the problem, well, ... 
that's an application specific thing.  DNS ought to be able to help, 
but don't tailor the DNS to any specific application's unique desires.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.