On 16. 08. 26 11:45, Ondřej Surý wrote:
Hi everyone,
it was also suggested off-list that returning "something" might be an option. I
did think
about this for a while and in fact, I've implemented several variants of that
until coming
to conclusion that it makes no sense going half-way.
I would be happy to turn the text below into paragraph in the draft.
### Authoritative servers
For authoritative servers, returning "something" (first RRSIG, whatever) is fine
### Recursive servers
For recursive servers, it is possible to return "something" if there's
something in the
cache, but if there's no RRSIG under the name, you can't return "something"
because
you don't know if there's a RRSIG or not in the authority. So, you want to
prime the
cache with something, so what do you do? There's couple of options:
1. send A/AAAA/MX (whatever) query to upstream with +rd +dnssec
2. send RRSIG query to upstream with +rd (+dnssec)
3. send SOA query to upstream with +rd +dnssec
4. something else?
Either of these can return a positive or negative answer. The positive answer
might include
RRSIG, but if it doesn't you are at square one. Same thing with negative answer
or error,
the resolver also does not have anything to return.
I believe it is better to be strict here (even if the deployment can take
years) and both refuse
to answer RRSIG queries and to send RRSIG queries to upstream servers (both
authoritative
and forwarders).
### Validating servers
Validating servers might store the "extra" RRSIG(RR) in the cache with
"unvalidated" status,
but there's no reason to do so because answers with RR will always include the
signatures,
so that would only increase complexity.
### Non-validating servers
There's only one scenario where returning something for RRSIG queries has a
little value
and that's non-validating servers (servers that don't understand DNSSEC).
Non-validating
servers could cache RRSIG records as opaque blobs and return them to the
clients.
I still believe this is a weak reason to return "something" instead of return
FORMERR or
REFUSED.
FTR I originally thought we should return 'something', but then there's
prior art in what Cloudflare and NS1 auths are doing - which is REFUSED
- and it seems the sky has not fallen.
Given there's no legitimate reason to ask for RRSIG (because it is
useless without associated clear text rdata) I think not answering it is
sensible.
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
