Quick question in a top-reply, sorry: Mark: Is there any combination of flag bits or EDNS options that a stub can use to reliably determine if a resolver is validating?
Obviously there are clever tricks possible, such as sending queries to a small set of domains that identify whether resolvers validate (at all and/or correctly), that have been used in some previous tests by George and Geoff. But, are there ways that give immediate confirmation (and can be used on every query) of the DNSSEC-validating status of a resolver? Brian On Wed, Oct 6, 2021 at 11:53 PM Mark Andrews <ma...@isc.org> wrote: > > > > On 7 Oct 2021, at 15:49, George Michaelson <g...@algebras.org> wrote: > > > >> First of all, it is apparent that if a resolver maintains a unified > cache in which it has DNSSEC-aware and DNSSEC-oblivious data, things will > definitely break. The general wisdom appears to be that you need to > maintain two caches, and only answer DO-set queries with DO-set cache (or > go fetch); but if there's ever been explicit protocol requirement of this, > I have forgotten it. > > > > Sorry, but I think this is just an over-reach. There is no necessary > > reason for a single information model to break. It is about how you do > > it. The problem of course is transitive links in the tree from one > > state (signed) to the other (unsigned) and back again, and associated > > meta data. Arguably, its one information model, one cache, but the DO > > bit flagging limits what answers you can tell people and you have to > > reply with SERVFAIL for information you hold, even though you know the > > next query might well be for the same info without DO force. > > > > It may well be logistically simpler to run two caches, but this > > statement seems to me to be over-stating things. > > Very much so. > > Eric, > DNSSEC validation does not work *reliably* if the upstream resolvers > are not *validating*. Anyone that does a rigorous analysis of the protocol > will tell you this. > > DNSSEC will work reasonably well if the upstream are just DNSSEC aware > (keep the > RRSIGs with the data they cover, pass through negative proofs required for > the answers) if there is not spoofed traffic, a mix of DNSSEC aware and > DNSSEC > oblivious server for the zone, etc. A validating upstream will block this > badness and only pass through good responses. A non-validating upstream > will > cache this garbage. > > It will fail abysmally if the upstreams are not DNSSEC aware. Don’t even > attempt it. > > I know many on this list don’t like hearing this, that they would like it > if DNSSEC aware was enough so that intermediate resolvers don’t need to > validate. They are fooling themselves. This is where the "just send CD=1" > came from. The fear that the upstream will have a bad trust anchor or bad > time are just that, fears. If a upstream has a bad clock or bad trust > anchors > then everything will be failing and it will get fixed. Just send DO=1,CD=0 > and on the few cases where you get SERVFAIL return with DO=1,CD=1. > > Now there are some improvements that could be made to make the protocol > even more robust when there are intermediate resolvers. Passing the > trust anchors (DS record form) the downstream is using to the upstream > to improve the robustness of the process. One could also pass the clients > concept of time. > > Mark > > > G > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
