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

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

Sigh...

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 Lewis
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 mailing list