[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bind-users
Subject:    Re: Value of a DNSSEC validating resolver
From:       Mark Andrews <marka () isc ! org>
Date:       2024-02-12 6:00:49
Message-ID: BDEAA0FD-1314-4B31-9D95-FB8F0E833156 () isc ! org
[Download RAW message or body]



> On 9 Feb 2024, at 21:40, Petr Menšík <pemensik@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.

Your diagram has a "non-validating iterative".  How does that machine meet the \
requirement of "You store in cache only valuable records, not bogus garbage." if it \
does not validate?  Sure this chain will appear to work until it doesn't.  All it \
requires is 1 "bad answer" to be learnt by that first server and responses that \
should succeed, won't.

If you change the chain to

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

and have secure paths to the right of the "validating iterative" things will work.  \
The "validating iterative" server is supposed to discard bogus responses which allows \
it to filter out the garbage.  If you then say always set "CD=1" the validating \
intermediaries stop preforming that role which is why I objected to that being \
specified.

Setup 3 auth servers with signature that have a validity interval of 2 weeks, one of \
which has up to date signatures and 2 that have out of date signatures.  This is the \
sort of thing that happens out there by accident, e.g. unnoticed zone transfers \
failing and the zone has not yet expired.  Try looking up multiple answers from that \
zone with your configuration and then with mine.  

> 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@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@alaska.gov
> > > Department of Administration
> > > State of Alaska
> 
> -- 
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, https://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> 
> <OpenPGP_0x4931CA5B6C9FC5CB.asc>-- 
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


[prev in list] [next in list] [prev in thread] [next in thread]