Value of a DNSSEC validating resolver

Fri Feb 9 11:39:30 UTC 2024

Do the analysis where the resolver is under attack or the auth server with the best rtt is stale.

-- 
Mark Andrews

> On 9 Feb 2024, at 21:40, Petr Menšík <pemensik at redhat.com> wrote:
> 
> 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/octet-stream
Size: 9889 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240209/2695dd57/attachment-0002.obj>
-------------- next part --------------
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/octet-stream
Size: 495 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240209/2695dd57/attachment-0003.obj>