> On 7 Oct 2021, at 15:49, George Michaelson <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
