This guide explains BIP 353 DNS Payment Instructions in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 353 is a Complete specification for publishing Bitcoin payment instructions in DNS TXT records. A payer can start with a human-readable identifier, retrieve a signed record and obtain a BIP21 URI containing an on-chain address, Lightning instruction or other compatible payment data.
- Why it matters: BIP 353 can make Bitcoin payment instructions easier to share, but its trust boundary is precise: a successfully DNSSEC-validated record supplies authenticated discovery, not proof of the recipient’s real-world identity or the payer’s intent.
- Current position: BIP 353 is a Complete specification for publishing Bitcoin payment instructions in DNS TXT records.
What this means in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of a mempool as one node’s waiting room for valid transactions that have not yet entered a block. Different nodes can have different waiting rooms, and the contents can change from one second to the next.
Key terms in plain English
- BIP
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Consensus
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Node
- A computer running Bitcoin software that checks data and communicates with other peers.
Status and purpose
BIP 353 is Complete, Specification, at the Applications layer. It standardises discovery of payment instructions and does not make a DNS name a Bitcoin consensus identity.
Record location
For an identifier such as user at domain, the lookup is formed beneath user._bitcoin-payment.domain. The result is a single TXT resource record whose character strings are joined before parsing.
DNSSEC requirement
The wallet must perform DNSSEC validation and reject unsigned, bogus or insecure answers. Ordinary encrypted DNS transport alone authenticates neither the zone owner nor the returned record.
BIP21 payload
The TXT data carries a BIP21 URI. Wallets should parse only supported parameters, honour required-parameter semantics, and present the final payment method and amount for confirmation.
Aliases
CNAME and DNAME indirection can be followed only when the alias records and the final answer are all validly DNSSEC-signed. Loop, depth and cross-zone failures need explicit handling.
Preference and compatibility
When an explicit address, public key or direct BIP21 URI is already supplied, wallets must prefer that direct instruction. DNS discovery should not silently replace a more explicit destination.
Names and privacy
International domain names are handled in their ASCII punycode form. Lookups can disclose whom a payer is trying to pay, and predictable labels can permit enumeration, so resolvers, caches and publishing practices need privacy review. Build a revision-pinned evidence pack on an isolated node, wallet or protocol harness.
Frequently asked questions
What is BIP 353 DNS Payment Instructions?
BIP 353 is a Complete specification for publishing Bitcoin payment instructions in DNS TXT records. A payer can start with a human-readable identifier, retrieve a signed record and obtain a BIP21 URI containing an on-chain address, Lightning instruction or other compatible payment data.
Is BIP 353 DNS Payment Instructions active or supported today?
BIP 353 is a Complete specification for publishing Bitcoin payment instructions in DNS TXT records.
Why does BIP 353 DNS Payment Instructions matter?
BIP 353 can make Bitcoin payment instructions easier to share, but its trust boundary is precise: a successfully DNSSEC-validated record supplies authenticated discovery, not proof of the recipient’s real-world identity or the payer’s intent.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
BIP 353 can make Bitcoin payment instructions easier to share, but its trust boundary is precise: a successfully DNSSEC-validated record supplies authenticated discovery, not proof of the recipient’s real-world identity or the payer’s intent.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
