In message <dc68d2d1-e339-99d7-3e14-7102f19b8...@redhat.com>, Florian Weimer writes: > On 04/27/2017 11:31 AM, Mark Andrews wrote: > > If you want to advocate for changes to behaviour that is fine, but > > advocate for that. Just saying "shouldn't the rcode be NOERROR" > > isn't doing that. Then there is DNSSEC. If the target zone is > > signed and DO=1 is set in the query should you include the data > > from the target zone? > > Do you suggest to use data which is impossible to use under the trust > rules because it is cryptographically signed?
Yes. DNSSEC validators do it all the time. DNSSEC does not care who supplies the data. > This would mean that many DNSSEC validation bugs turn into critical > cache poisoning bugs because they can be used by off-path attackers to > poison caches. And in the last decade how many DNSSEC validation bugs have there been that have marked answers as secure when they haven't been? B.T.W. named has been returning additional as answer if the RRset validates as secure for about a decade now. I devised the trust rules for named 20+ years ago now. They are designed for dealing with answers that can't be cryptographically verified. > (Usually, a single query for an attacker-controlled name > would be enough, and it could likely be a PTR query.) I'm not sure if > saving a server round-trip is worth it. In particular since the > recursive resolver already has the infrastructure records for the target > in cache if it can do cryptographic validation, it should know exactly > where to fetch the target record anyway. > > In general, cryptography as the single line of defense is a very, very > bad idea because it almost never works correctly. > > Thanks, > Florian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
