[Dnssec-deployment] In-band DNSSEC explanations was Re: Analysis of NASA.GOV...
Ed.Lewis at neustar.biz
Mon Feb 6 14:40:35 EST 2012
All of that is true and I'll add one [or] more thing[s]: if you have
the validator sign the message you need to figure out how to
distribute the key to verify the signature. Plus - having to figure
out how to do key management on machines that might be behind a load
balancer (or anycast). And we need an authorization model: how do
you know the reason and valid signature were generated by the
legitimate validator. Etc. I.e., a whole can of worms.
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
>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.
>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
>>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.
>>NeuStar You can leave a voice message at +1-571-434-5468
>>2012...time to reuse those 1984 calendars!
NeuStar You can leave a voice message at +1-571-434-5468
2012...time to reuse those 1984 calendars!
More information about the Dnssec-deployment