[dns-operations] The perils of retroactive DNSSEC validation
fw at deneb.enyo.de
Fri Nov 14 21:38:25 UTC 2008
* 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
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
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
deneb.enyo.de: type MX, class IN
Type: MX (Mail exchange)
Class: IN (0x0001)
<Root>: type OPT
Type: OPT (EDNS0 option)
UDP payload size: 4096
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
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
>>> 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
> 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.
More information about the dns-operations