[dns-operations] The perils of retroactive DNSSEC validation

[Florian Weimer]

* Edward Lewis:

> What's puzzling to me is - okay - the querier ("initiator?") transmits
> a query.  At this point in the exchange, all the querier knows is
> whether there is a trust anchor relevant to the query.  (How can the
> querier/initiator be aware the data will be bogus before it arrives?)
>
> The responder processes the query and discovers a matching RRset (or
> sets) in the cache of data that has failed validation.

No, it hasn't.  It is in the Indeterminate state in the language of
RFC 4035.  This means that there's no way to actually check the
signature.

> 1) Accept the SERVFAIL and end
> 2) Perform the validation from what it can get (e.g., the issue might
> be clocks)
> 3) Disregard the opinion of the respondent and use the data anyway

2) is impossible if it's intermittent Bogus data, like in an attack.
The RRset will expire quickly from the BAD cache, but the upstream
query will just retrieve that data again because the upstream cache
has cached it in Indeterminate state, subject to the normal TTL rules.

>>I'm not talking about the BAD cache described in RFC 4035.  I think
>>I've already made that clear.
>
> No, not clear.
>
> E.g., what is an "initiator?"  DNS is a client-server, query-response
> protocol.  There really is no definition of a DNS session, just an
> exchange.  So, I can only equate the term "initiator" with the client
> (stub resolver, etc.) or the querier.  When terms are introduced on
> the fly, like "hierarchy of caches" the questions will not be clear.

Huh?  I picked up these terms on IETF mailing lists.  Never mind.

"DNS initiator": A party which sends a DNS query packet, either on
behalf of an application or because it is a forwarder and has received
a query (or for some other reason, e.g., detection of cache poisoning
attempts).  "Querier" is ambiguous because it may refer to someone who
is offering services (but maybe this is arcane/BE/AE, I don't know).

"Hierarchy of caches": I've tried to explain this already.  We can
restrict ourselves to the simplified situation of a security-aware,
validating, non-recursive caching resolver forwarding queries to a
security-aware, non-validating, recursive caching resolver (the
default in the end-to-end DNSSEC model).