Dnssecuritytxt: new security best practice or impractical good idea

by mrahier96

Share

Dnssecuritytxt: new security best practice or impractical good idea

by mrahier96

by mrahier96

If you are casually browsing for ways to improve your cyber security posture, you might not have come across dnssecuritytxt, and it’s understandable because it’s not very famous. But we took a look at it and wanted to share our opinion with you.

Security.txt and dnssecuritytxt

A few years ago, a concept called security.txt became popular in the online community after giants such as Google, Facebook or Dropbox started implementing it. This concept was nothing more than a .txt file that was placed in the /.well-known/ directory of a website. Its contents? Information about who to contact in case a bug is found, what the security policy of the company is, how to encrypt the proof of vulnerabilities before sending them over, and even a job page for those who might be interested. You can read this great article which goes more into the details of security.txt or you can visit our implementation of it to see what it looks like from the URL below:

A great initiative indeed, provided there is a web server on that domain. But what happens if phishing emails start flying around from this other domain name you’re only using for emails? Or if you start seeing SSL certificates get created for this same domain? How about seeing it in some shady Pastebin across the internet? Enter … dnssecuritytxt

(Note: If you are serious about monitoring activity related to your data online, don’t wait for others to let you know. Let us actively do that for you! Have you heard about EyeDeep?)

What does dnssecuritytxt do?

Dnssecuritytxt comes to address the exact problem above, which is the absence of a web application behind a potentially compromised domain. It uses DNS, so it will work for all your domains.

It is based on TXT records and there are two of them as follows:

The first one is security_contact. This should be either an email address (don’t forget the mailto: prefix) or a URL to a specific report page, such as https://domain.com/report-security-issue.

The second record is security_policy. This field should define the security policy of the company. It is useful to let the finders know what to do and what to expect after submitting the issue. In our case it is the rfc2350 document.

The TXT records can be added at the apex (root) of the domain, but they can also be put in the _security subdomain.

So why choose one over the other?

If one does not want to overload the root zone, the subdomain approach is better, but less common. People don’t know this initiative that well (yet), so putting the information in the _security subdomain may not be giving enough visibility.

In practice

Theory is nice, but it is not useful unless applied.

For this article, the top 10000 most accessed domain in the world, according to majestic million were tested. A short bash script based on the dig command was used to iterate over all these domains and check whether they implement dnssecuritytxt or not. It does so by using the dig command to query the TXT DNS records and then the grep command to search for either security_contact or security_policy

The results were quite unexpected, as there was only one domain in the Top 10000 that implements it, and the winner is … ethereum.org. Congratulations to you!!!

In the case of ethereum.org, they have two fields for each item, which is neither explicitly allowed nor forbidden in the documentation. One could only infer what Ethereum wanted to do here, but most probably they are hoping to be contacted via multiple channels, and people or crawlers to follow rules in multiple documents.

One out of 10000 is really not a lot, but it’s better than nothing, isn’t it? Further research uncovered other less popular domains using it such as disclose.io or shodan.io so we’re definitely not alone.

It should be noted that this initiative was first made public in March 2021, a bit more than a year ago, and is currently still a draft, so the lack of mainstream coverage makes all the more sense.

Final thoughts

We’ve talked about the dnssecuritytxt initiative, we compared it to the older more popular security.txt initiative and we saw how popular it is in today’s online landscape.

Verdict? From our opinion this initiative is good, as it takes a great concept like security.txt and pushes it even further. Everyone knows DNS, everyone uses DNS, everyone does DNS. The lack of global implementation should not be discouraging, as long as the idea is good, and it is.

So why not be one of the first ones to implement it?

Contact our experts !

Author

Razvan Ursu

References

Top