Re: a view from an application person

[Edward Lewis <edlewis@arin.net>]

At 13:21 -0400 5/13/04, Michael Richardson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>>>>>>  "Edward" == Edward Lewis <edlewis@arin.net> writes:
>     Edward> applications community.  To keep this short, I'd think about
>     Edward> approaching the Apps AD's (Scott Hollenbeck and Ted Hardy)
>     Edward> to see if there's something architectural to say about this
>     Edward> topic.  I.e., where are the IETF applications efforts going
>
>   It might work. It might be too high level.
>   Much work is off in XML land at this point.

You gotta do this though.  The only way to avoid the "IETF late 
surprise" is to engage the AD's early.  Not that you'll get an 
answer, but you should get some idea of who is willing to pitch in to 
the effort.

>     Edward> The question above is not binary.  Under the principle of
...
>   Those are two arms of a spectrum, not a binary choice.

Exactly.  Try solving for a spectrum of points on a curve. ;)

>
>     Edward> An application ought to know strictly whether it got the
>     Edward> info from DNS or not.  If an application cares how DNS
>     Edward> arrived at the answer, then the application has assumed a
>     Edward> debugging role.  I stop thinking of the application as an
>
>   I strongly disagree.
>
>   We complain loudly when applications put up a nice box on user's
>screens which say, "FAILED", yet this is what you are advocating.
>   This is why IT support costs are so high - the user can't make
>intelligent decisions about any of this data, because they aren't given
>any information.

What does a name service promise.  More exactly, what does a lookup 
serivce promise.  Client gives it, in DNS, a name, type, class, and 
the server responds with the rdata.  That's the basic premise.

So, what we are looking for here - i.e., the quality of the rdata - 
is something above and beyond the basic premise of the DNS.  My 
suggestion then is that to get this "quality of answer" we have to 
enter the realm of debugging.

Or replace the DNS with a new service that meets a new basic premise.

>     Edward> This can be done by examining the logs or by some
>     Edward> interactive approach, such as performing a "verbose
>     Edward> reporting of the validation chain."
>
>   WHAT LOGS? where are they?  Think about it.
>
>   Why do you think I want to have audit information returned on every
>request? SO THAT IT CAN GO INTO THE LOGS.

The logs maintained by the implementations of DNS.  The barely 
documented, ill-understood, never really tested, but ever improving 
logs.  There are logs, but for the validation piece, I've yet to make 
much use of them.  (Not that I've tried all that hard.)

I think the DNS logging system is a vast resource I think we've 
barely tapped into for it's usefullness in understanding the quality 
of answers.

You're second paragraph confuses me.  I don't know how to respond to it.

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

?  Heh - often times that fixes the problem anyway.

But I do know of a similar situation I worked 10 years ago that 
invovled packet filters.  An off-my-campus user couldn't reach a 
server at a remote campus.  I could.  It took finding a contact at 
the remote campus and asking them to verify that the filtering was 
taking place.  (I have no recollection how the problem was resolved.)

The moral is, the user reported a problem to me.  I was able to hunt 
down the place where the problem was (a remote campus) and consult 
the log (in this case a human) to isolate the issue.  I assume 
corrective action was taken by one of the end points to fix the 
situation.

>   Let's take the case where the signature appears to have expired. There
>are three reasons I can think of for this:
>     1) the signature really has expired in the primary
>     2) there is some blockage preventing all caches from getting newer
>        data that is signed wrong.
>     3) the clock on the machine doing the verification is wrong.
>
>
>   #3 is the MOST likely reason. Particulary when the security aware
>local caching name server is on the end-user's laptop.
>   How does IT guy find that out?

Well, if the log's are engineered right, then the determination of an 
expired signature would result in this:

DATE TIME validation: error: signature out of time (start-end) for 
NAME/TYPE/CLASS and key <key identifier>

...or something like that.  It would be enough evidence that perhaps 
the clock was out of sync.

It might be tempting to demand that the DNS server know it's time is 
off, but time is of NTP, not DNS.  Just let DNS "report" and have the 
debugging operations and procedures determine the cause.

>   Tell the end-user to run "dig"?  I think not.

No - I've never suggested that the victim in the situation do the debugging.

>
>   Ask them to click on the "email details to IT" button on the dialogue?
>I think so.

The email would just need to identify the query details and the 
iterative server used to do the lookup.  From there it should work.

>   Ed might answer, "but that is the debugger application" - but I
>disagree. It isn't.
>   It is a bunch of information that got captured as a text file and got
>emailed. (or printed. Maybe email doesn't work as a result)

I don't understand you.  The email is part of the error notification, 
not even part of debugging.  The debugging tools come into play later.

>   I just want additional information returned in all cases.

That's an untestable requirement.  "What additional?" for starters. 
Define that for the realm of applications, not any one or ones in 
particular.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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