[dns-privacy] Datatracker State Update Notice:
IESG state changed: New State: AD Evaluation::Revised I-D Needed (The previous state was AD Evaluation) Some minor comments/nits sent by email to the authors. Revision is expected to have a clean Last Call. Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
> On Nov 8, 2019, at 20:13, Brian Dickson wrote: > > > > > More anecdotal stuff is at https://ianix.com/pub/dnssec-outages.html which > lumps together information about TLD failures (now very rare), sites with > failures (becoming increasingly uncommon and having smaller impact), and > durations (typically a week or less on average, but again, this is anecdotal > not statistical.) I have on a few occasions explained to the people running this site that they were wrong to blame dnssec. Some listed events were generic outages wrongly blamed on dnssec. No corrections were ever made. The side is extremely subjectively anti-dnssec. > > > YMMV, of course. But, fear of rampant validation failures is entirely > misplaced at this point. Enough validation is being done, that such failures > need to be considered the responsibility of the signers, not the validators. Exactly, and why I quoted 8.8.8.8, 1.1.1.1 and 9.9.9.9. So many people are behind dnssec validators that validation failure would lead to a quick outage notification by tools or humans. Paul___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
stephen> It seems odd that you're telling someone what they ought not be stephen> worried about. Wouldn't it be better to be convincing that stephen> there's nothing to worry about? (E.g. via stats.) It's a few years out of date but this has actually improved. I was on the DNS team at comcast. I've confirmed that this is still more or less what they see. For 500-600 billion queries per day, 1-2 dozen DNSSEC related failures per month (modulo a few folks in .mil or .gov that have NTAs for long standing failures). That's with validation on all queries. That's in the below noise range. I wish I had packet drop rates in that range. ;) ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
On Fri, Nov 8, 2019 at 4:18 PM Stephen Farrell wrote: > > Hi Paul, > > On 08/11/2019 23:11, Paul Wouters wrote: > >> I will also need to monitor the added load on the servers, although > >> I don't expect it to be a problem. > > That’s not an issue. > > > >> I realize that not everyone agrees with this level of > >> caution/fear/lack-of-backbone (I am sure there are other > >> descriptions people would prefer). > > It’s far too late for that level of concern by you. > It seems odd that you're telling someone what they > ought not be worried about. Wouldn't it be better > to be convincing that there's nothing to worry about? > (E.g. via stats.) > I was curious as to whether there are any easy-to-find stats or other information on validation failures. (Short summary: not a lot, not detailed, mostly anecdotal or summary information.) The closest thing to stats I could find were: https://www.theregister.co.uk/2018/02/28/dutch_name_authority_dnssec_validation_errors_can_be_eliminated/ The relevant information was that "The rate of validation error is now 30 per million DNSSEC lookups." I'd say that is low enough to not worry. More anecdotal stuff is at https://ianix.com/pub/dnssec-outages.html which lumps together information about TLD failures (now very rare), sites with failures (becoming increasingly uncommon and having smaller impact), and durations (typically a week or less on average, but again, this is anecdotal not statistical.) My view is the pendulum is swinging in the other direction, i.e. that the next push needs to come (and will come) from the signing of domains rather than validating by resolvers, for leading aggregate DNSSEC uptake. The support for DNSSEC signing in software, including management of automated unattended signing, has drastically improved, to the point where IMHO you would have to try to find software or operators that don't do things to facilitate reliable signing. YMMV, of course. But, fear of rampant validation failures is entirely misplaced at this point. Enough validation is being done, that such failures need to be considered the responsibility of the signers, not the validators. Sign, by all means, but expect that resolvers will validate, and take appropriate measures to monitor and alert on failures. Brian ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
Hi Paul, On 08/11/2019 23:11, Paul Wouters wrote: >> I will also need to monitor the added load on the servers, although >> I don't expect it to be a problem. > That’s not an issue. > >> I realize that not everyone agrees with this level of >> caution/fear/lack-of-backbone (I am sure there are other >> descriptions people would prefer). > It’s far too late for that level of concern by you. It seems odd that you're telling someone what they ought not be worried about. Wouldn't it be better to be convincing that there's nothing to worry about? (E.g. via stats.) S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
> On Nov 8, 2019, at 17:06, Bob Harold wrote: > > > I hate to admit it, and this is a little off topic, but my resolvers are not > (yet) validating. Then your resolvers’ configuration is years out of date. All resolvers these days ship with validation enabled. > Is there a setting that will attempt to validate, and log if it fails, but > still answer the users? At that point, everyone using 8.8.8.8 or 9.9.9.9 or 1.1.1.1 or any other non-opendns resolver would not be able to access that domain. Why would you want to override that? > I hear that there are occasional sites that fail validation, and would like > to know what will break if and when I begin to validate. Nothing that the vast majority of users would already not be able to see. > I will also need to monitor the added load on the servers, although I don't > expect it to be a problem. That’s not an issue. > I realize that not everyone agrees with this level of > caution/fear/lack-of-backbone (I am sure there are other descriptions people > would prefer). It’s far too late for that level of concern by you. Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
On Fri, Nov 8, 2019 at 4:37 PM Paul Wouters wrote: > On Wed, 6 Nov 2019, Paul Hoffman wrote: > > > Given that we are (still supposedly) talking about requirements and not > solutions, I would be unhappy with a requirement that prevents a resolver > that is not validating > > Why would a _resolver_ not be validating ? > > I understand the reasons for web applications that do not want to do > validating, though I disagree with those. But for actual DNS resolvers, > running as DNS caching server on either laptop or in an enterprise, I > see no valid reason why it should not be validating at this point. > > > Any protocol we develop for ADoT capability discovery should prevent > downgrade attacks but should also work fine for resolvers that do not > validate. > > I strongly disagree. Resolvers towards Authoritative servers are core > infrastructure, and that core should have no problems using the latest > DNS RFC's. > > Paul > I hate to admit it, and this is a little off topic, but my resolvers are not (yet) validating. Is there a setting that will attempt to validate, and log if it fails, but still answer the users? I hear that there are occasional sites that fail validation, and would like to know what will break if and when I begin to validate. I will also need to monitor the added load on the servers, although I don't expect it to be a problem. I realize that not everyone agrees with this level of caution/fear/lack-of-backbone (I am sure there are other descriptions people would prefer). -- Bob Harold ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] [Ext] Threat Model
On Wed, 6 Nov 2019, Paul Hoffman wrote: Given that we are (still supposedly) talking about requirements and not solutions, I would be unhappy with a requirement that prevents a resolver that is not validating Why would a _resolver_ not be validating ? I understand the reasons for web applications that do not want to do validating, though I disagree with those. But for actual DNS resolvers, running as DNS caching server on either laptop or in an enterprise, I see no valid reason why it should not be validating at this point. Any protocol we develop for ADoT capability discovery should prevent downgrade attacks but should also work fine for resolvers that do not validate. I strongly disagree. Resolvers towards Authoritative servers are core infrastructure, and that core should have no problems using the latest DNS RFC's. Paul ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
