[Dnssec-deployment] In-band DNSSEC explanations was Re: Analysis of NASA.GOV...
mcr at sandelman.ca
Mon Feb 6 14:57:00 EST 2012
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> 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
>> 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
>>> 2012...time to reuse those 1984 calendars!
Edward> Edward Lewis NeuStar You can leave a voice message at
Edward> 2012...time to reuse those 1984 calendars!
More information about the Dnssec-deployment