[dns-operations] The perils of retroactive DNSSEC validation

[Florian Weimer]

* Edward Lewis:

> At 20:57 +0100 11/14/08, Florian Weimer wrote:
>
>>The initiator could set a flag, similarly to the RD bit, which
>>requests new data.  This has been implemented for HTTP, for instance.
>
> This is an old desire - a "ignore the cache, get new data for me" bit.
> I'm at a loss as to why this has never been implemented, perhaps Paul
> or someone who has been around the protocol longer than I recalls the
> problem.

Well, as I wrote--it's rather unlikely that it's going to be
implemented given recent developments.

>>DO has nothing to do with validation.
>
> DNSSEC OK bit - it's meant to be set when the querier has a trust
> anchor for a domain in which the QNAME sits.

Please look at some real network traffic.  Here's a packet I just
received at ns.enyo.de:

Domain Name System (query)
    Transaction ID: 0x0576
    Flags: 0x0010 (Standard query)
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ...1 .... = Non-authenticated data OK: Non-authenticated data is acceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        deneb.enyo.de: type MX, class IN
            Name: deneb.enyo.de
            Type: MX (Mail exchange)
            Class: IN (0x0001)
    Additional records
        <Root>: type OPT
            Name: <Root>
            Type: OPT (EDNS0 option)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x0
            EDNS0 version: 0
            Z: 0x8000
                Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
                Bits 1-15: 0x0 (reserved)
            Data length: 0

This is a DO=1 query.  But the sender has certainly no intent or
ability to validate.

> But that's not important to this thread - it's why I mentioned the DO
> is about all the responder can use to detect if the querier has the
> ability or intent to validate.

No, it can't, see above.  BIND 9 and Unbound set the DO bit in all
queries.

>>>  Let's say you get an RRset with a signature valid for November
>>>  2008. And for simplicity let's say you have a trust anchor validating
>>>  the key in the signer field.  What does "retroactively validate" mean?
>>
>>I meant "first populate the cache, then validate", in contrast to
>>"validate and store on success".
>
> In the sense of "lazy evaluation" - that is, storing a result and then
> using it later on?

No, it's just the order of evaluation.  This is really just an aside
regarding the internal workings of some validating resolvers.  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.

> I forget the point, but in talking about this with someone else who
> dropped by today, perhaps you might think about the caching of failed
> data along the lines of negative caching.

I'm not talking about the BAD cache described in RFC 4035.  I think
I've already made that clear.