[Dnssec-deployment] In-band DNSSEC explanations was Re: Analysis of NASA.GOV...

[Michael Richardson]

Ed: Are you speaking to the SiteFinder stuff, or the error messages?

>>>>> "Edward" == Edward Lewis <Ed.Lewis at neustar.biz> writes:
    Edward> All of that is true and I'll add one [or] more thing[s]: if
    Edward> you have the validator sign the message you need to figure
    Edward> out how to distribute the key to verify the signature.  Plus
    Edward> - having to figure out how to do key management on machines
    Edward> that might be behind a load balancer (or anycast).  And we
    Edward> need an authorization model: how do you know the reason and
    Edward> valid signature were generated by the legitimate validator.
    Edward> Etc.  I.e., a whole can of worms.

    Edward> Sigh...

    Edward> At 13:32 -0500 2/6/12, Michael StJohns wrote:
    >> I actually considered a similar approach as a way of getting some
    >> of the "benefits" of SiteFinder without actually breaking the
    >> model. Basically, if a server would send a "NXDOMAIN" it could
    >> also send - in the additional section - an ALT record suggesting
    >> a mapping from the name asked to an existent name.  Doesn't have
    >> to be signed as its a meta record.  This puts the burden on the
    >> receiving end to decide whether to pursue the other name
    >> (e.g. via a pop up controlled by your browser, and ignored by
    >> things like email servers).
    >> 
    >> For the validation error stuff, probably also a meta record in
    >> the additional section.  I don't think the issues with size apply
    >> as the return is probably pretty tiny - unless you actually sign
    >> it. (But that return would need to be signed not by a zone
    >> originator, but by the server/resolver which leads you to a whole
    >> other set of problems with respect to how you find the keys to do
    >> chain validation).
    >> 
    >> With respect to the set of error messages - we figure them out
    >> and figure out which ones need additional info (like "failed to
    >> get the DNSKEY for zone foo.com"), and define the error set.  Add
    >> a "other error, not further described" and you're pretty much
    >> done.
    >> 
    >> Mike
    >> 
    >> 
    >> At 12:19 PM 2/6/2012, Edward Lewis wrote:
    >>> At 16:30 +0000 2/6/12, Tony Finch wrote:
    >>> 
    >>>> (I'm probably thinking of a rather nerdy kind of
    >>>> user-friendliness, where instead of a blank SERVFAIL "it didn't
    >>>> work" you can easily get an "it dind't work because [details]"
    >>>> without having to be a dig jockey.)
    >>> The first thing that leaps to my mind is a new EDNS0 option.
    >>> 
    >>> But here are reasons why not, or at least cause serious doubts:
    >>> 
    >>> 1. It would have to be defined in an IETF document 1a - how do
    >>> you explain an validation error in an
    >>> non-human-language-specific way?  2. We would need to build API
    >>> extensions to retrieve it/dig would need read it 3. This would
    >>> lengthen the packet 4. It's unsecured, unless the exchange was
    >>> TSIG/TKEY protected
    >>> 
    >>> And I don't know what EDNS0 says about what happens if the EDNS0
    >>> option causes a response to be too big.
    >>> --
    >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    >>> Edward Lewis NeuStar You can leave a voice message at
    >>> +1-571-434-5468
    >>> 
    >>> 2012...time to reuse those 1984 calendars!

    Edward> --
    Edward> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    Edward> Edward Lewis NeuStar You can leave a voice message at
    Edward> +1-571-434-5468

    Edward> 2012...time to reuse those 1984 calendars!