On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock <[email protected]> wrote: > On 2014-04-29 at 14:22 +0100, Simon Kelley wrote: >> secure no DS means that the original unsigned answer should be accepted, >> except that it shouldn't. There's no way to distinguish between secure >> lack of DS because we've reached an unsigned branch of the tree, and >> secure lack of DS because we're not at a zone cut, except if we know >> where the zone cuts are, and we don't. > > Fair point. > >> That's why dnsmasq works up from the bottom. The first secure no-DS >> answer we find marks the boundary between signed and unsigned tree. >> >> Dnsmasq is acting as a validating stub resolver here. That's a supported >> role for DNSSEC, so this must be possible. If it's not then we have a >> standards problem. > > You have a standards vs reality problem: lots of loadbalancer appliances > suck at DNS and are only just now managing to return errors, instead of > dropping the query (hanging), when queried for AAAA records instead of A > records. > > ( This has led to no end of pain in the IPv6 world; Happy Eyeballs, > expectations around improved _client_ behaviour, handle other parts of > the puzzle and tends to require the concurrency that a client also > needs to handle DNS problems, but it's still distinct. ) > > You're not going to get such loadbalancers responding sanely to a DS > query any time soon, and with the other DNS client software all being > recursors which work fine because they know where zone cuts are, you're > going to be fighting a long hard battle with vendors and sites to get > them to fix their brokenness when "it works for everyone else". > > So the standards 100% support what you're doing, but they don't match > common stupidity in deployed (high end, expensive) equipment.
The only idea I have is to adopt some sort of whitelisting technology, and simultaneously nag the folk with busted implementations. > > To support DNSSEC in the real world without changing from being a > forwarder, you're going to need new insight. My only thoughts are > around whether or not this might provide impetus for TKEY-based TSIG for > forwarders to establish trust links to recursors elsewhere, in which > case once you have a TSIG key (whether TKEY-derived or OOB manual) then > you might delegate trust to the remote recursor. I see there have been a few commits to dnsmasq that address some stuff. > > Sorry to be the bearer of bad news, I'm delighted to have got this far. Is the consensus to not run with negative proofs on at this juncture? > -Phil -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
