> 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.
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.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>-- > 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: ma...@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
