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. 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. Sorry to be the bearer of bad news, -Phil _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
