Point of clarification, all OpenDNS/Cisco Umbrella resolvers do DNSSEC validation and enforcement for all production traffic[1]. Silent validation started almost a year ago. Active enforcement (SERVFAIL on validation failure) has been happening since March 10th. If you are seeing something that indicates otherwise, please reach out.
-- Brian [1] Somers presented on our then current DNSSEC story at DNS-OARC 32 in San Francisco - https://indico.dns-oarc.net/event/33/contributions/751/attachments/724/1228/20200201_DNSSEC_Recursive_Resolution_From_the_Ground_Up.pptx On 9/12/20, 15:27, "dns-privacy on behalf of Geoff Huston" <[email protected] on behalf of [email protected]> wrote: Paul and Paul (and the WG), > >> Primarily because that is only of value to resolvers that are validating, and that's the small minority of resolvers. > Whats “a resolver”? Is Google’s DNS service one resolver or hundreds? Of Cloudflare’s 1.1.1.1 farm? What about Chinanet’s service where thousands of IP addresses all act in remarkably similar ways? Frankly, any statement about “the majority of” or “the minority of” resolvers is a pretty meaningless statement from such a perspective. Is my recursive resolver at home that answers queries for just me equal in any way to Google’s service which is used by one quarter of the Internet’s users? Yeah they are both resolvers, but thats about it. > > Which of large resolver operators is not validating ? well we have a good idea of the answer to that question: Open DNS resolvers that do not perform DNSSEC validation: 114dns (VERY large in China) dnspai (again, big in China) onedns opendns (some instances of Opendns’s cloud, but by no means the entirety) > Which of the stock opensource resolvers is not validating with a default configuration ? I believe there are a few that require the local admin to enable it and the distro has it disabled by default. > > Arguably the only ones left not validating are phones and we are busy giving them DoH and DoT to servers that do that for them. um, not really. In the US the ISP resolvers that don't validate include AT&T, Cellco, T-Mobile, UUNET, Charter,... It's probably easier to list the major ISPs in the US that do DNSSEC validate : Comcast. In Canada the ISPs resolver systems that don't include BACOM, Rogers, Shaw,… Further afield, some of the extremely large ISP resolvers in India validate (Reliance Jio), but in China, not. > > I think your argument does not hold. I find it hard to agree with either assertion about the prevalence of use of DNSSEC validation here. The argument that DNSSEC is just a minority corner case does not hold water these days - 25% of the world’s users pass their queries through DNSSEC validating resolvers and will not get an answer if the validation fails. A further 10% of users also use DNSSEC validation and then fail over to non-validating resolvers in the event of validation failure. 1/3 of the total user base of today’s Internet use DNS recursive resolvers that perform DNSSEC validation. Thats not a small minority. There is a lot of DNSSEC validation out there for users and a lot of large resolver systems serving these users. But 2/3 of users do not use DNSSEC validating resolvers. So it's by means the default case for the DNS. But DNSSEC validation continues an upward trend and given the standard lifetime of IETF work (2 years and 17 days on average for a draft these days) then the numbers for DNSSEC use will only grow. Accordingly, I have far more sympathy with Paul Wouter’s assertion that bringing in yet another mechanism of opportunistic encryption is one more straw-like adornment to the DNS camel (to use my own interpretation of Paul W’s comments) while a TLSA record could perform the same role, obviating the need for opportunistic encryption to authoritative servers. regards, Geoff _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
