DNS Security TXT

Casey Ellis has been a friend for quite some time now, for his sins, we stay in touch and every once in a while we do a ‘big catch up’  you know that kind of friend, you’re still there supporting each other on the socials but not really ‘chatting chatting’, until you do … like that.

So we catch up the other day and we got to the point of using DNS TXT records to hold security contact signposting, either an email or a URL to a security page that would then carry them to the conversation they’re looking to have about security and that organisation, a bug a leak a whatever, anyway next thing I know Casey’s got me bombing around a google document where we’re cutting out its key requirements, what are nice to haves and what are creeping in on the principles

The principle is this:

‘A method to hold security contact signposting from an authoritative position.’

The next bit gets pedantic, but what do you expect?

There are lots of ways to store information in DNS Records and some of the feedback we see in week one is ‘why not this or that’  let’s go:

• Why not a subdomain?
• Why not in Whois?
• Why not Security.txt?
• Why not SOA?
• Why TXT at the root?

Why not subdomains:

A subdomain is a decent idea, but we figured that we want the message to be as parental as possible, this allows the principle signpost to be right at the root, it may be that there are granular TXT records in other departments that reside in subdomains but that’s a deviation from Draft0.

Why not Whois:

Whois would have been a good place for it too, if not for whois privacy features and fractured laws around privacy and protection of information stored in whois.

Why not Security.txt:

Security.txt is a great piece of work, and feel a little bad stepping next to that as a movement to achieve the same goal. we believe that the DNS record is a little more useful for a few reasons, and explaining those we really don’t want to diminish the value of security.txt – IMO Security.txt has the best utility when those involved in placing the security.txt file on the webserver(s) are either technically sound or can influence engineering teams to prioritise placing it, this might be easy or difficult depending on what service is being presented to the internet (API/Web/everything else), it’s not to say that it is impossible, security.txt has great traction, and that shows us that there is great intent to make sure security contact information is available, where security.txt is quite feature-rich in its offerings, we want to boil our outcome down to ‘how to reach security and how to be reached as security’

Why not SOA (Start of Authority)

It might have been a good place, had this been considered when it was DNS SOA was defined, but strictly speaking the DNS contact space in the SOA is specifically for administration.

Why TXT at the Root:

Quite simply, It’s the first place it can be. it’s authoritative, and it’s parental to the other services, programs and systems that fall under it.

There are concerns that too many TXT records may impact downstream systems, we aren’t proposing War and Peace, just a few parameters and values, perfectly acceptable as per the RFC. – if that’s a concern, I would imagine there are some verification records that you could remove, but that’s not a security task, that’s for the domain name administrators.

So far, we have a mix of comments mostly positive lightbulb moments, and some that need explaining and some that are fair but mostly around ‘you could do it this way too’ but the main principle needed a path to be chosen, and I think we’ve got it right.

If you like the idea, think it could be improved, believe it’s fatally flawed or want to know more you can join in here

• https://dnssecuritytxt.org
• https://github.com/disclose/dnssecuritytxt
• https://twitter.com/DnsSecuritytxt

This project sits under Disclose.io a responsible disclosure and safe harbour project https://disclose.io

Any traction given to the project is welcome, the only way this get’s off the ground is if it’s value is understood or people in the right place get visibility of the idea, next up... getting the RFC