The state of DNS security records 2020

Not quite the third year running, but a third edition at least. This years state of DNS security records survey has seen a few changes – so is a bit of a transition report. I’ve dropped all of my self generated lists, except for DoH providers, in favour of more robust lists. I’ve also got a new generation of my domain quality tool in the works. This report was produced using the new version of the tool as it produces more reliable results, captured more data and is a tad more efficient allowing me to increase my sample size.

TLDR: Summary

The adoption rates of security related records provisioned continues to stagnate, though I suspect the drops from 2017 may be artefacts of improved methodology and larger sample size. Comparing just to last year any gains made are marginal at best. Despite all the attention DNS security has got this year, deployment of DNS based security remains in the doldrums. The average score for this year based on 7,003 unique domains has increased to a lofty 2.93/10 up by 0.51 from last year.Not what could be called a massive improvement. Within this years increased survey data deployment rates of everything except DMARC records have fallen, though in many cases that fall has been from not much to even less. Fundamentally either the measures relying on these DNS record types are not seen as providing any significant benefit or the cost of adoption is too high for most organizations to consider them. If the former then they need to be deprecated quickly to allow resources to be better used elsewhere, if the latter then the security industry needs to work to make adoption easier and more affordable.

Methodology

The basic methodology for this survey hasn’t changed, I run all of the data sets through the Domain security check and see what it finds. AS with previous years I look for IPv6, SPF, DMARC, CAA, DNSSEC and DKIM records and what SPF and DMARC policies are published. I check for these records as they are recommended in various good practice guides such as NCSC: Protecting Parked Domains and NCSC: email security and anti-spoofing for example.

Data sets

Trying to use reputable data sets for my test the base data was taken from the following sources:

• Alexa top 50 (50)
• Cyber security hot 150 – this used to be the Cyber security 500 (150)
• ICANN accredited registrars (664)
• Domain state top 100 registrars (100)
• Tranco top sites list (200)
• DoH providers – this is a list I maintain and publish as a RPZ feed details of which are discussed in an earlier article (90).
• NS domains – this list is generated as part of the survey and contains all of the domains returned in NS records for the domains in the other data sets. (2297)

In future I intend to drop the Alexa top 50 as it’s too much effort on my budget. Instead I’ll use the Tranco list for both a top 50 and a top 200. It seems likely that there may be significant variation between the top 50 domains and the next 150 or more – so it would be interesting to look at the top 50 separately.

New RR types and additional checks

This year I’ve also started looking at TLSA/DANE records and SVCB/HTTPS records for domains that publish a “www.” record. They are not included in any of the charts as at present the up take is so low as to be invisible compared to anything else. As it impacts on the survey I’ve also started checking for wild card CNAME and apex CNAME records, which are also won’t be included in any graphs for similar reasons. Please not I do actually mean “APEX CNAMEs” which contravene the RFCs not any sort of new fangled apex alias.

Findings

Really not a lot has changed from last year, mainly things have got marginally worse. There’s really only one highlight and even that is suspect. DMARC has seen a rise amongst security vendors (but that may be due to the reduced data set: the Cyber security 500 is now the Cyber Security hot 150). Similarly the slight improvements in the security stance of ICANN accredited registrars may be due to the further consolidation of that market as the number has dropped from 1,148 last year to 664 this year. Despite the slight improvements amongst ICANN registrars compared to last year, their results are still embarrassing seeing equivalent or worse levels of deployment compared to the full data set average. The similarly poor performance of the name server domains rather indicates that despite continuing industry focus on DNS security, the security stance of DNS infrastructure remains disturbingly weak ( e.g. just 7.4% DNSSEC deployment). DKIM may not have collapsed as much as the data suggest as the presence of DKIM records can only ever be inferred and changes to DNS server software may cause issues with that.

To end on a note of positivity there has at least been a significant increase in the deployment of CAA & DNSSEC records amongst DoH providers. Which is just as well as the DoH security model is very heavily dependent on you being able to trust they are who they say they are.

In terms of actual deployment across the board things have either worsened or remained stagnant. However a lot of that may be due to changes in the lists used and improvements in data collection, larger data sets are likely to produce worse results. Unfortunately comparing static domain lists isn’t I think useful as companies wax and wane and a static list won’t be representative of the general state of things. However even where a direct year on year comparison is possible ( Alexa top 50, ICANN, top 100 registrars) the numbers aren’t encouraging if you look at the percentage changes.

Whilst there isn’t much good news, we can at least take some comfort in the knowledge that the majority (just) of companies checked have at least published SPF policies of some sort and a reasonable amount of them are at hard fail.

The story isn’t so good when it comes to DMARC with not publishing anything still being the most popular choice for everyone outside of the top 200 domains (Alexa and Tranco) and security vendors . Where DMARC policies are published they tend to be at “reject” which is good. I suspect this is in part due to the cost/effort involved in both generating and receiving DMARC reports. Whilst there are some free DMARC reporting options there aren’t many and for enterprises they don’t tend to provide enough details to be comfortable to lock down a domain. As a note for further work it would be interesting to look at domains with MX records compared to those without.

New record types and bad behaviour

Before I come to any conclusions a brief word about the new draft record types and other incidental findings. Whilst checking for records wild-card CNAMEs cause a bit more work as they need to be checked in case they’re actually relevant for the record type being sort. Thankfully wild-card CNAMEs are remarkably unpopular (despite it seems every Domain registrar & hosting company using them by default). Of the total data set only 18% of surveyed domains published wild-card CNAMEs, with similar levels across all data sets. Surprisingly there where a very few (29) domains which had a CNAME published at the domain apex. Worryingly this included: 4 ICANN registrars, 1 of the Alexa top 50 and 5 of the NS server domains.

After feedback from last years survey I started checking for TSLA/DNAE records where the domain had a “www.” address and whilst I was at it checking for SVCB/HTTPS records seemed a sensible use of time even though they’re still draft records. Neither record type has got a huge amount of traction at this time, but interestingly the draft SVCB/HTTPS has a greater uptake than TSLA/DANE 6.6% of the full set compared to 1.1%. However neither RR type has seen any adoption by the Alexa top 50. Rather adoption is strongest amongst DNS related firms ( ICANN (5%) and top 100 registrars (10%) ) and the Cyber Security 150 (16%). The only group with significant adoption of TSLA/DANE are the DoH providers with an 8.2% adoption rate.

Wrapping it up

To end on a “high” note whilst there hasn’t been any improvement of the adoption of these various security record types, the firms that have adopted them seem to be slowly improving. There are now an entire 10 domains that score 9 or above, and a massive 358 that have got all of DNSSEC,CAA,SPF, DKIM and DMARC in place in some form or other (out of 3,551) so that’s something.

If these records and the processes that make use of them do actually add value, something needs to be done to lower the cost of adoption because at the moment they’re going nowhere. Whilst the new security related records currently in draft do tackle different problems I struggle to see the value of adding ever more security related RRs into DNS when even quite long established records aren’t being adopted.
As is so often the case on the internet the benefits of adopting more secure policies are magnified the more widely they’re adopted, and realistically none of these are that widely adopted. If these records are of use work needs to be done to make it easier for people to make use of them – if they’re not adding sufficient value then we need to drop them and move on to something that does.

Updates and corrections Following discussions about this article I discovered an issue with how I was checking DNSSEC records. This error resulted in an under counting of DNSSEC records. The error has been resolved and this article updated to reflect the correct count.
The corrections are as follows: