a view from an application person

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----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.

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

  Those are two arms of a spectrum, not a binary choice.
  
    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.  

    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.

    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".
  The relevant logs for them to look at are:
      a) on the end-user's computer (best case), in the local caching,
	 recursive resover's log file.

      b) on the IT department's recursive resolver (assuming they can
	 figure out which resolv.conf equivalent was used)

      c) on the end-user's ISP's resolver. 

      d) on the Linksys gateway box at the no-name coffee shop's
	 hotspot.


  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?

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

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

  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)
  
    Edward> I'd settle for much clear logs out of the BIND validator
    Edward> right now. If the logs were better, I think the problem
    Edward> ahead for applications would be clearer.  'Course, I'm not

  That works for you and I. It doesn't work in general.

    Edward> PS - About SERVAIL.  I've argued that it's overloaded to the
    Edward> detriment of debugging in workshops.  I've found that I can
    Edward> easily separate DNSSEC SERVAILs from DNS SERVFAILs by doing
    Edward> a "dig ... +norec" - i.e., by using a debugging tool already

  I don't care about SERVFAIL vs NOTVAL or whatever. It isn't a question
about 1 bit vs 5. 
  I just want additional information returned in all cases.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQKOurIqHRg3pndX9AQFlcwQAhlnQGfzOQ/IgdJNrbxL01PxSI7fbJx/T
tn8TyHJq+eV/WrTIRswtZH+P4ShExvE5jGjOE0bxYeJvrXey81FunsPM+7Sjp3Ta
yQt2sCHHKs8VcjyoCerx01p304K8qfyVcOFAeslZ1RPbU8CAYMFuISXy6T/LpVEJ
xeKRId/5IkU=
=jhRf
-----END PGP SIGNATURE-----