Re: dnssec: resolver - application communication

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

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Matt" == Matt Larson <mlarson@verisign.com> writes:
    >> 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.

    Matt> Michael,

    Matt> It sounds like you're arguing for a richer signaling mechanism
    Matt> between security-aware iterative-mode resolver and
    Matt> recursive-mode resolver.  I have been in the "AD bit, SERVFAIL

  Yes, that puts it very consisely.

    Matt> mechanism) to communicate DNSSEC validation status are
    Matt> necessary and inevitable.  One of these days I'll just break
    Matt> down and write an I-D.

  Why not today? :-)
  Openswan currently uses a helper application, "lwdnsq" to speak
"lwres" protocol to bind9. Right now, "lwres" is just DNS on
127.0.0.1:953. This is what I want to extend.
  See draft-ietf-ipseckey-rr-10.txt and
      draft-richardson-ipsec-opportunistic-15.txt
  
  and grep for DNSSEC for the kinds of information that we want to get
back. 

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

  Yes, that's what a security-ignorant stub resolver that is speaking to
a paranoid recursive resolver would get.  For many, this is going to be
the first exposure to DNSSEC.

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

  Yes, is where I think 90% of applications that are security aware want
to be. 

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

  dig will do this.
  Some other diag tools will do this.
  Some applications will need to be deployed into situations where they
will have to do all the work, but in general, I think this will be a
rare case.

    Matt> We won't know which apps fall into which classes until we get
    Matt> some experience.  But I absolutely believe there will be a

  I agree entirely.

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

iQCVAwUBQKF1A4qHRg3pndX9AQE6dAP/Y/LS1uHEXbIW3I82kiPiEj2yihtQrlBy
lnRRc7QMkRuU7m7QMmpIJQELFVMPeYehDkXTVx+C5LLFETAivgJuP41DDoiDeeUR
R/AlTVSjvTmqH9KehASEWF4TGMS4K0cH898OzQar+4wfbHQL7Ugw1NDW+6SqkvQA
LqfGC6HW16k=
=YYCS
-----END PGP SIGNATURE-----