[dns-operations] The perils of retroactive DNSSEC validation
Ed.Lewis at neustar.biz
Fri Nov 14 22:33:40 UTC 2008
At 14:05 -0800 11/14/08, David Conrad wrote:
>Well, it _was_ meant to do that, but because I used unfortunate wording,
>implementors interpreted the RFC differently.
Sigh, the twin perils of protocol engineers - document editors & code writers.
>DO must now be interpreted to mean the validator supports DNSSEC-related RRs,
>not that it is going to do anything useful with them.
Okay, well, in the thread, it was a side point and even more says
that there is no way to stop a validating server from talking to an
non-validating one or vice versa. If you can't tell if the remote is
one or the other, you can't enforce a gag rule.
At 22:38 +0100 11/14/08, Florian Weimer wrote:
>question ("how is this supposed to work?") is about queries for data
>which are Bogus (in the terminology of RFC 4035) from the point of
>view of the initiator, but Indeterminate from the responder's point of
Are you asking about how to process a CD=1 bit?
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
The responder processes the query and discovers a matching RRset (or
sets) in the cache of data that has failed validation. If the CD bit
is 1, the response is set to include the set(s) and the AD bit is
off. If the CD bit is 0, the response is SERVFAIL. (This is what I
think it should be.)
When the querier (or initiator?) processes the response, ..., it will
either see a SERVFAIL (which on the surface could be from DNSSEC or
not) or data with no indication of validation. At this point it is
up to the querier to decide how to proceed.
1) Accept the SERVFAIL and end
2) Perform the validation from what it can get (e.g., the issue might
3) Disregard the opinion of the respondent and use the data anyway
>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.
(That is why I'm typing so much in trying to figure out the intent
and meaning of your question.)
Edward Lewis +1-571-434-5468
Never confuse activity with progress. Activity pays more.
More information about the dns-operations