Value of a DNSSEC validating resolver

[Petr Menšík]

Hello Mark,

allow me here to correct your statement. We spent in Red Hat some time 
thinking and testing validating clients. Validating resolver is *not* 
necessary for validating clients to work. They are better and 
recommended, but not always necessary.

What is required is dnssec (security) awareness. Meaning that resolver 
will fetch signatures for all queries with do=1 bit set. For example 
even dnsmasq in default configuration will forward DNSSEC signatures to 
all DNSSEC enabled queries. Also in cases dnssec validation is not 
enabled in it. It is not strictly required fetching them for do=0 queries.

For example our office resolvers do not have validation enabled. But 
they allow any clients using dnssec-trigger to validate all queries 
themselves. And that works for majority of existing DNS caches.

What is required from bind9 is to have dnssec-enabled yes; That was 
default even in 9.11 and this is the last version, where it is possible 
to change it to dnssec-enabled no; Since 9.16 it is not possible to 
configure it that way. In this case any validating client, be it end 
station or dns forwarder, will fail all queries sent to it. Clients can 
validate regardless dnssec-validation value is used, but they need do=1 
answers to their do=1 queries.

Following chain of forwarders will still deliver non-bogus answers only. 
fwd means forwarder only, not using root hints.

[root-servers]---[non-validating iterative]----[non-validating 
fwd]---[validating fwd]--->(secure or unsigned answers only)

Validating client can refuse answer to dnssec-failed.org, even if the 
recursive forwarder it is using did not check its validity. If it sends 
you do=1 enabled answers, that is enough. You have to compute your own 
SERVFAIL result, which validating upstream forwarder could have sent you 
straight away. That that is the beauty of DNSSEC. Not everyone in the 
chain needs to be doing crypto operations. But everyone in the chain 
can, as long as crypto records are included.

delv +vtrace or unbound-host -rvD commands work even on non-validating, 
but security aware resolvers.

And to answer original question. You store in cache only valuable 
records, not bogus garbage. Having cache filled also with signatures 
makes validation of your clients much faster, just RTT between you is 
used, even when they validate.

Regards,
Petr

On 12/1/23 22:40, Mark Andrews wrote:
> A validating resolver is a prerequisite for validating clients to 
> work. Clients don’t have direct access to the authoritative servers so 
> the can’t retrieve good answers if the recursive servers don’t filter 
> out the bad answers.
>
> Think of a recursive server as a town water treatment plant. You could 
> filter and treat at every house and sometimes you still do like 
> boiling water for baby formula but on the most part what you get out 
> of it is good enough for consumption as is.
>
> -- 
> Mark Andrews
>
>> On 2 Dec 2023, at 08:14, John Thurston <john.thurston at alaska.gov> wrote:
>>
>> 
>>
>> At first glance, the concept of a validating resolver seemed like a 
>> good idea. But in practice, it is turning out to be a hassle.
>>
>> I'm starting to think, "If my clients want their answers validated, 
>> they should do it." If they *really* care about the quality of the 
>> answers they get, why should my clients be trusting *me* to validate 
>> them?
>>
>> Can someone make a good case to me for continuing to perform DNSSEC 
>> validation on my central resolvers?
>>
>> -- 
>> --
>> Do things because you should, not just because you can.
>>
>> John Thurston    907-465-8591
>> John.Thurston at alaska.gov
>> Department of Administration
>> State of Alaska

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x4931CA5B6C9FC5CB.asc
Type: application/pgp-keys
Size: 9736 bytes
Desc: OpenPGP public key
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240209/800fd00e/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240209/800fd00e/attachment.sig>