security_contact
Required. Publish one or more absolute reporting URIs.
Proposed standard · Internet-Draft in preparation
Publish vulnerability reporting contacts and policy links in DNS—before a researcher connects to a service.
Domain-scoped. Transport-independent. Freshness built in.
_security.example.com. 3600 IN TXT
"security_contact=mailto:[email protected]"
_security.example.com. 3600 IN TXT
"security_policy=https://example.com/security"
_security.example.com. 3600 IN TXT
"security_expires=2027-01-01T00:00:00Z"
Reference programs
Five significant programs from the disclose.io directory. Reference examples—not claims of DNS Security TXT deployment.
Publish
Set a contact, optionally link a policy, and state when the information expires.
Required. Publish one or more absolute reporting URIs.
Optional. Point to the applicable HTTPS policy.
Required exactly once. Expired information is not used.
Discovery
The application determines the domain whose security information it needs.
_securityResolve the TXT RRset at _security.<domain>. No automatic apex fallback.
Parse known fields, check expiration, honor DNSSEC, and surface inconsistencies.
DNS Security TXT supplies a domain-scoped default. RFC 9116 remains the host-specific HTTP mechanism. Publishers should keep both consistent.
Why DNS
Security contact discovery should not depend on an application being online, correctly routed, or even HTTP-based.
DNS gives the domain operator a clear place to publish reporting information.
One RRset can describe the default for services associated with a domain.
security_expires prevents stale contacts from living forever.
Clients can find a contact without assuming a working website or web stack.
disclose.io ecosystem
Open, vendor-neutral infrastructure for getting security reports to the right place.
Resolve an asset to its owner and best security contact.
Open lookup DirectorySearch 27,000+ vulnerability disclosure and bounty programs.
Open directory FrameworkPractical language for authorization, safe harbor, and disclosure.
Read frameworkFAQ
The Internet-Draft is normative. This page stays deliberately practical.
No. DNS Security TXT provides domain-scoped discovery, including for non-HTTP services. RFC 9116 remains useful for host-specific information.
No. A contact record is not permission to test. Any authorization, safe harbor, or rules of engagement must be explicit in the applicable policy.
Stale contacts can lose or misdirect sensitive reports. Exactly one RFC 3339 timestamp states when the entire RRset stops being usable.
No for normative deployments. The proposed standard uses _security.<domain>. Apex records are legacy migration material only.
Unsigned records remain useful for discovery, but DNSSEC is recommended. A DNSSEC result of Bogus must not be used.
Open standard
The proposal is being prepared as an individual IETF Internet-Draft. Technical review and implementation feedback are welcome.