Value of a DNSSEC validating resolver
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 Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- 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
Re: Value of a DNSSEC validating resolver
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 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 Thurston907-465-8591 > john.thurs...@alaska.gov > Department of Administration > State of Alaska > -- > 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 -- 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
Re: Value of a DNSSEC validating resolver
Hi there, On Sat, 2 Dec 2023, Mark Andrews wrote: On Fri, 1 Dec 2023, John Thurston wrote: > Can someone make a good case to me for continuing to perform DNSSEC > validation on my central resolvers? 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. Thank you for that outstandlingly useful analogy, I hope to use it! -- 73, Ged. -- 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
Re: Value of a DNSSEC validating resolver
Preface: Please don’t read any judgement of DNSSEC’s value into this question. Just looking for the opportunity to understand DNSSEC better from some world-class experts if any care to respond. When a client (or any DNS-speaker) is doing validation, doesn’t it set CD on queries through a forwarder? In that sense, the intermediate servers do not filter “bad answers.” Or is my understanding incorrect? Or do you mean the data that the forwarder is using internally has been filtered of bad answers? On Fri, Dec 1, 2023 at 1:40 PM 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 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 Thurston907-465-8591john.thurs...@alaska.gov > Department of Administration > State of Alaska > > -- > 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 > > -- > 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 > -- 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
Re: Value of a DNSSEC validating resolver
Clients need to send both cd=0 and cd=1 queries. The two types of queries address different failure scenarios. I tried hard to prevent the stupid just send cd=1 advice before it was published. Years before there was a wish to reduce the amount of work a validating resolver does. There was bad advice from that and the WG chair refused to reopen the issue. CD=1 addresses bad clocks and trust anchors in resolvers. CD=0 addresses bad authoritative servers and spoofed responses. You can start with either and try the other when validation fails. -- Mark Andrews > On 3 Dec 2023, at 12:31, Crist Clark wrote: > > > Preface: Please don’t read any judgement of DNSSEC’s value into this > question. Just looking for the opportunity to understand DNSSEC better from > some world-class experts if any care to respond. > > When a client (or any DNS-speaker) is doing validation, doesn’t it set CD on > queries through a forwarder? In that sense, the intermediate servers do not > filter “bad answers.” Or is my understanding incorrect? Or do you mean the > data that the forwarder is using internally has been filtered of bad answers? > > >> On Fri, Dec 1, 2023 at 1:40 PM 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 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 Thurston907-465-8591 >>> john.thurs...@alaska.gov >>> Department of Administration >>> State of Alaska >>> -- >>> 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 >> -- >> 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 -- 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
Re: Value of a DNSSEC validating resolver
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 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 Thurston907-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: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- 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
Re: Value of a DNSSEC validating resolver
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 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 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 Thurston907-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
Re: Value of a DNSSEC validating resolver
On 2/9/24 12:39, Mark Andrews wrote: Do the analysis where the resolver is under attack or the auth server with the best rtt is stale. I admit here we most often work with internal only forwarders, which are not accessible from outer internet. So those won't be under attack, at least directed from uncontrolled outside. For internal organization resolver it is somehow easier to find source of attack and make them stopped. Something not possible on public internet. And of course, if auth server becomes unreachable, it is up to resolver to try alternative servers known. If they do not respond as well, then yes, stale cache is the only thing protecting us from serving SERVFAILs. But I am not sure how that contradicts what I have written before. Can you elaborate a bit more, please? -- Petr Menšík Software Engineer, RHEL Red Hat,https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- 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
Re: Value of a DNSSEC validating resolver
> I admit here we most often work with internal only forwarders, which > are not accessible from outer internet. So those won't be under attack i am always impressed by security optiism randy -- 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
Re: Value of a DNSSEC validating resolver
-- Mark Andrews > On 10 Feb 2024, at 04:18, Randy Bush wrote: > > >> >> I admit here we most often work with internal only forwarders, which >> are not accessible from outer internet. So those won't be under attack > > i am always impressed by security optiism > > randy -- 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
Re: Value of a DNSSEC validating resolver
> On 9 Feb 2024, at 21:40, Petr Menšík 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 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 Thurston907-
