[dns-operations] The perils of retroactive DNSSEC validation

[Edward Lewis]

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:

>My main
>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
>view.

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 
arrives?)

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 
be clocks)
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
NeuStar

Never confuse activity with progress.  Activity pays more.