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 <pemen...@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.thurs...@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.thurs...@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
Description: Binary data
> -- > 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
OpenPGP_signature.asc
Description: Binary data
-- 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
