Re: a view from an application person

[Edward Lewis <edlewis@arin.net>]

At 14:38 -0400 5/13/04, Michael Richardson wrote:
>     Edward> Well, if the log's are engineered right, then the
>     Edward> determination of an expired signature would result in this:
>
>   Yes, that would work. But, that won't be in the logs.

Why not (be in the logs)?  It might not be now, I'm suggesting that 
we should put $it there.

>   What I'm advocating is that when I do:
>
>marajade-[/corp/projects/sw5000/proj] mcr 1149 %dig +dnssec \
>                               @istari4.sandelman.ca. www.sandelman.ca.

...

>That I should get the following back in addition:
>
>      1) a SIG for ottawa.on.ca/on.ca/ca/. (if that was the route things
>	took).
>      2) some kind of extra data that told me that things stopped at .
>	because it was where the trusted anchor was.
>	(in this case, it was locally trusted to sandelman.ottawa.on.ca.)
>
>And, that I want all of this stuff on SERVFAIL as well. I want to know
>how far we got before things failed.

This sounds like the job for debugging, it's above and beyond the 
simple premise of the DNS.

>
>     Edward> No - I've never suggested that the victim in the situation
>     Edward> do the debugging.
>
>     >> Ask them to click on the "email details to IT" button on the
>     >> dialogue?  I think so.
>
>     Edward> The email would just need to identify the query details and
>     Edward> the iterative server used to do the lookup.  From there it
>     Edward> should work.
>
>   Doubtful.

Doubt?  As a engineer, I can't come up with any retort to someone's doubts. ;)

>   If the iterative server follows BCP, then the IT guy won't be able to
>do recursive queries to it to find out what it thinks. Worst, the
>iterative server is local, and the laptop is off by the time the query
>gets to the IT guy.

I don't follow, what BCP?  If the IT department wants to do remote 
(telephone) response, then they ought not reply on the laptops doing 
resolution.  They ought to be using a remotely accessible server.

(That's an IT procedures problem, not a DNS problem.)

>   Note I am specifically assuming that the end-user is in some remote
>location - i.e. a hotel room, and that calling the Hotel's IT is a total
>loss.  The user contacts their own IT people first.

I can't respond to that.  My experience is that VPN's are common too. 
But arguing all this is external to DNS.

Give DNS a fair shake - it can only make apparent the work it has 
done to arrive at an answer.  It can't easily cough up reasons for 
failed responses.

I guess my point is that you have separate what is an operations 
issue and what is a DNS issue.  DNS can't reason, reasoning about 
errors is not part of DNS. I certainly can't decipher what's in a 
named.conf from a series of digs.

>   My application is Opportunistic Encryption, it's purpose is privacy.
>   But, I think my arguments would apply to SSHKEY use as well.
>
>   I know of no other DNSSEC aware applications to date.

I'm suggesting that we not "jump the gun" because of one point of 
data.  OE is just one application, SSHKEY is two.  I'm reluctant to 
"optimize" for just two applications without any understanding of the 
broader spectrum of applications.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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