RFC Proposal: Permanent Domain Burn Mechanism for Security and Brand Protection

gistfile1.md

⚠️ Disclaimer
This document is a casual RFC-style concept draft, shared publicly via Gist.
It reflects a spontaneous idea and is not intended as a serious or complete proposal.
Please don't take it too seriously — feedback and fun discussion are welcome!

1. Introduction

This document proposes a mechanism to allow domain name holders to permanently deactivate ("burn") a domain name, making it unavailable for future registration by any party. The goal is to address security, privacy, and brand protection concerns arising from domain name reuse after abandonment or expiration.

2. Background

In the current DNS and gTLD ecosystem, domain names that expire are eventually released back into the available pool for registration. This process poses multiple risks:

• Security risks: Email addresses and services tied to abandoned domains may be reactivated by malicious actors.
• Brand dilution: Former company or product names can be re-registered by third parties, potentially causing confusion or reputational harm.
• Link rot and hijacking: Legacy URLs may be reused for phishing, malware, or misinformation campaigns.

While some registries maintain reserved lists, there is no user-driven, systematic method for intentionally retiring a domain.

3. Proposal: Domain Burn Mechanism

3.1 Terminology

• Burn: The act of permanently deactivating a domain name such that it cannot be re-registered by anyone.
• Burned Domain: A domain name that has been successfully deactivated and blacklisted from future use.
• Registry: The authoritative operator of a top-level domain (TLD).

3.2 Specification

3.2.1 Eligibility

Any domain name registrant may request a burn of their currently owned domain.

3.2.2 Burn Request Procedure

• The registrant initiates a burn request via their registrar.
• The registrar verifies ownership and confirms the irreversible nature of the operation.
• The registrant pays a one-time burn fee (amount determined by the TLD operator; e.g., $100 USD for .jp, $200 USD for .com) to the registry to process and store the burn record.

3.2.3 Burn Execution

• Upon confirmation, the registry:

  • Flags the domain as "permanently deactivated."
  • Excludes the domain from all future registration processes.
  • Publishes the domain in a public "burned domain registry."

3.2.4 Persistence

• Burned domains are retained indefinitely in a non-reusable state.
• Exception mechanisms (e.g., court order) may exist but should be narrowly scoped.

4. Use Cases

4.1 Brand Retirement

A company retiring a product may wish to burn its associated domain to prevent impersonation or confusion.

4.2 Preventing Email Reuse

Security-conscious individuals or organizations may burn old domains to prevent unintended reception of password reset emails.

4.3 Public Infrastructure

Governments or NGOs may burn domains used for time-sensitive campaigns or events.

5. Security Considerations

• Domains burned through this mechanism cannot be resurrected by mistake.
• Malicious use of burn (e.g., to block a competitor’s domain) must be prevented through ownership checks.

6. Future Extensions

6.1 Time-Limited Burns

Support for burning a domain for a limited time period (e.g., 50 or 100 years), after which the domain may become available again if not renewed or extended.

6.2 Transparency and Verifiability

Integration with DNSSEC or blockchain-based transparency logs to provide tamper-proof records of burn events. This ensures that the domain's status as "burned" is verifiable and immutable.

6.3 Burn Receipts and NFTs

Registrants may receive cryptographic receipts or NFTs representing the burn event. These can serve as proof of deactivation and may have archival or symbolic value.

7. Response Handling for Burned Domains

To clearly communicate the burned status of a domain, appropriate responses must be defined across various layers of internet infrastructure:

7.1 DNS Level

• Return NXDOMAIN (non-existent domain) with DNSSEC signing to confirm authenticity.
• In the future, consider EDNS extension to include a BURNED status flag for disambiguation from ordinary expired domains.

7.2 WHOIS/RDAP

• Indicate status with a field such as Domain Status: burned (clientBurned).

• Optional fields:

  • Registry Expiry Date: never
  • Remark: This domain has been permanently retired and cannot be registered again.

• RDAP example:

{
  "domainName": "example.com",
  "status": ["burned"],
  "remark": "This domain has been permanently retired and cannot be registered again."
}

7.3 HTTPS/HTTP Access

• Ideally, DNS resolution should fail (NXDOMAIN), resulting in standard browser error.
• If DNS resolves for informational purposes, return HTTP status 410 Gone with a burn notice.

7.4 API Response for Programmatic Access

• Provide an API endpoint for burn verification:

{
  "domain": "example.com",
  "status": "burned",
  "reason": "burned by registrant on 2025-07-01",
  "unavailableUntil": "permanently"
}

These responses help ensure that both human users and automated systems understand the domain is permanently deactivated.

8. Conclusion

This RFC outlines a user-driven, registry-supported domain burn mechanism that addresses a growing need for stronger domain lifecycle security and brand protection. We invite registries, registrars, and security experts to provide feedback and consider pilot implementations.

---