A standard allowing organizations to nominate security contact points and policies via DNS TXT records.
This proposal was first made public on March 25, 2021 and is is currently a draft. We welcome comments and feedback! To make suggestions please submit a PR via Github or submit a ticket. Thanks for your interest!
Find us on Twitter: https://twitter.com/dnssecuritytxt.
When people find security issues in Internet-facing systems, the correct channel to report security issues isn’t always clear. The relevant vulnerability reporting and disclosure policy for the system isn’t always apparent. The DNS Security TXT standard extends the work done by security.txt to simplify answering this question by taking advantage of DNS, arguably the most ubiquitous system on the Internet.
When deployed, it provides security researchers, Internauts, and concerned Internet citizens with clear and authoritative direction towards the correct channels for reporting security issues and the governing policies set out by an organization for all systems under a domain.
It is common practice to use DNS TXT to establish authorization from a domain. A typical example is when a company shows domain ownership to a third-party SaaS platform by placing a TXT record in their DNS zone.
DNS records speak on behalf of the organization and not just an individual server or application owner. Pairing security reporting and policy information with the authoritative nature of DNS creates confidence in the information provided.
This attribute of DNS TXT records makes them a suitable place to confirm, on behalf of the organization, good-faith towards security reports or authorization for testing (this permission to authorize is a core enabler for safe harbor for security researchers), and clear instructions about where security issues should be sent.
Management of DNS records is centralized, making these records simple to deploy, update, maintain, and remove if required. It also eliminates reliance on individual owners to deploy and maintain separate files.
DNS is core to the Internet’s operation, and interrogating DNS is a fundamental footprinting activity in penetration tests, automated scans, and fee-form security research, meaning the correct contact details and policy information are less likely to be missed
Just as security.txt can be deployed into either the root or the .well-known directory of a webserver, DNS Security TXT can be deployed to either the apex of a domain, or under a specially created _security.domain.com subdomain. This approach allows organizations to decide the approach that suits them best.
|Direct email reporting contact||domain.com||TXT||“security_contact=mailto:firstname.lastname@example.org”|
|Direct web form reporting contact||domain.com||TXT||“security_contact=https://domain.com/report-security-issue”|
|3rd party web form reporting contact||domain.com||TXT||“security_contact=https://bugcrowd.com/domain/report”|
|Direct policy URL||.domain.com||TXT||“security_policy=https://domain.com/security-policy”|
|3rd party web form reporting URL||domain.com||TXT||“security_policy=https://bugcrowd.com/domain”|
|Direct email reporting contact||_security.domain.com||TXT||“security_contact=mailto:email@example.com”|
|Direct web form reporting contact||_security.domain.com||TXT||“security_contact=https://domain.com/report-security-issue”|
|3rd party web form reporting contact||_security.domain.com||TXT||“security_contact=https://bugcrowd.com/domain/report”|
|Direct policy URL||_security.domain.com||TXT||“security_policy=https://domain.com/security-policy”|
|3rd party web form reporting URL||_security.domain.com||TXT||“security_policy=https://bugcrowd.com/domain”|
Is this a replacement for security.txt?
Is this giving anyone permission to hack my organization?
Can I deploy this on a subdomain?
Who in my organization do I need to engage with to get these records in place?
Will adding an email address expose me to spam bots?
How do I put these entries into my DNS?
Created with <3 by John Carroll and Casey Ellis for The disclose.io Project.