[ The kicker about DNSSEC is in the dnsviz links, enjoy ;) TLDR: As long as the very big providers don't demand DNSSEC / DANE, why bother as a small network (just, be prepared to deploy when it starts affecting spam scoring or your search rankings), but small networks do benefit unlike the large providers with direct peerings. ]
> On 20210602, at 16:57, Scott Morizot <tmori...@gmail.com> wrote: [..] > My large organization [..] > I know our Internet email team [..] You are hitting it right on the head as I noted in my previous comment: you have multiple (and then possibly even >10) people working on just those separate subjects of DNS and email. Many many shops do not have that luxury, where the email and DNS person is the same person, maybe there are 2 people, but that is heaven already. DNSSEC just becomes really scary for smaller teams, or for teams that are small, as it is keys to the kingdom when that fails, and you can't rely on an external helper to then run and help you when you need the help. And the benefits do not really always outweigh the fragility chances... Now, in reality, it all should not really matter: the email market, where DANE should be prevalently used, is dominated by a few duo-ish-opolies of really large mail providers and then there are a bunch of smaller ones. And these have those large teams and could do DNSSEC and if they want DANE indeed just fine, you would think. If those market 'leaders' decide to enforce yet another new standard, and they pick DANE, if you want to either receive or send email to them, things get implemented really quickly everywhere, as you'll have to. (in the same way that we have SPF/DKIM/DMARC/ARC/STARTTTLS/MTA-STS/etc etc) But lets check the leaders with many great engineers on staff, what they think of this DNSSEC thing (and thus also DANE): https://dnsviz.net/d/gmail.com/dnssec/ <https://dnsviz.net/d/gmail.com/dnssec/> https://dnsviz.net/d/google.com/dnssec/ <https://dnsviz.net/d/google.com/dnssec/> https://dnsviz.net/d/microsoft.com/dnssec/ <https://dnsviz.net/d/microsoft.com/dnssec/> (along with 0x20 errors at my time of test) https://dnsviz.net/d/outlook.com/dnssec/ <https://dnsviz.net/d/outlook.com/dnssec/> https://dnsviz.net/d/icloud.com/dnssec/ <https://dnsviz.net/d/icloud.com/dnssec/> https://dnsviz.net/d/aol.com/dnssec/ <https://dnsviz.net/d/aol.com/dnssec/> (no UDP over IPv6) https://dnsviz.net/d/facebook.com/dnssec/ <https://dnsviz.net/d/facebook.com/dnssec/> One outlier: https://dnsviz.net/d/comcast.com/dnssec/ <https://dnsviz.net/d/comcast.com/dnssec/> (but various RRSIG issues, due to alg 5) seems your team has to be really big to dare to enable DNSSEC ;) Though, I would not be surprised if they simply don't care about DNSSEC, as they have direct links to most networks, thus spoofing DNS becomes a rarer option, and that the larger responses are considered to slow things down, thus they won't want to enable it because of performance reasons (gotta get those ads quicker to the eyeball before they dismiss it). Thus yes, for a smaller network it is likely a good idea to DNSSEC, because your packets will transit multiple links that might change bits, but for the very very big, where you mostly peer directly with most networks, DNSSEC is not really going to bring you much in terms of authentication of data. And with the move to DoT/DoH and centralised DNS Recursor services, they really don't care about that as TLS solves many (not all, eg auth) of the 'man-in-the-middle' attacks. But I am also sure that these large networks can simply flip a switch and enable it easily if they really wanted to. Greets, Jeroen (who has the majority of domains under my control DNSSEC signed, but... not all; need to do the DANE part though still)
