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

[Michael StJohns]

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!