draft-guorong-utxo-dns-03 Internet Engineering Task Force (IETF) G. Tian Internet-Draft CoCa Foundation Intended status: Experimental 31 October 2026 Expires: 4 May 2027 UTXO6-DNS: Resolving Payment Endpoints via Private-use RRTYPE and Prefix Isolation draft-guorong-utxo-dns-03 Abstract This document specifies the _utxo application namespace for DNS. It defines how wallet clients and TEE (Trusted Execution Environment) applications resolve verifiable payment endpoints and blockchain UTXO (Unspent Transaction Output) references using DNS. To avoid exacerbating public RRTYPE space congestion and DNS-layer transparent parsing, this document utilizes the RFC 3597 Private-use space (QTYPE 65400). The DNS protocol does not parse the payload. Application semantics are isolated strictly via the _utxo underscore prefix in the owner name, while the RDATA consists of a purely opaque CBOR-encoded byte stream. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 1. Introduction Traditional DNS maps domain names to IP addresses, answering the "where" question for network routing. Modern payment scenarios require a domain name to resolve to verifiable cryptographic endpoints (e.g., blockchain addresses), identity proofs, and compliance metadata. Earlier versions of this document (draft-guorong-utxo-dns-01 and -02) proposed a dedicated UTXO RRTYPE. Following rigorous feedback from the IANA Expert Review team and the DNS community, it was concluded that creating application-specific RRTYPEs is inefficient and pollutes the DNS namespace. Instead, this document leverages the native DNS mechanism of underscore prefixes (as defined in RFC 8552) to isolate application semantics. The _utxo prefix indicates that the queried record contains a CBOR-encoded payload structured according to this specification. 2. Why Not TXT? While the TXT RRTYPE's wire format is indeed binary-safe (comprising an array of s with length prefixes), it is rejected for this application due to structural and namespace constraints: 1. Lack of Type Discrimination: TXT records are heavily used for various purposes (SPF, DKIM, domain verification). Using TXT for cryptographic endpoints requires out-of-band conventions to distinguish our payload from standard text records. 2. Presentation Format Overhead: While the wire format supports binary, the presentation format (zone files, standard DNS debugging tools) requires escaping binary octets (e.g., \DDD). This makes manual configuration and debugging highly error-prone. 3. Array of Strings: TXT RDATA is an array of multiple strings. Clients parsing it would have to concatenate and handle chunking, adding unnecessary application-layer complexity. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 4. The _utxo Application Namespace Applications wishing to resolve UTXO-based payment endpoints MUST query the _utxo prefixed owner name. For example, for a domain merchant.utxo, the client MUST query: _utxo.merchant.utxo This prefix-based querying allows resolvers and clients to filter records natively without needing to inspect or parse the RDATA payload. 4.1. Apex Prohibition The _utxo prefix and the associated records MUST NOT be placed directly at the zone apex. This is not due to CNAME processing (which is inherently prohibited at the apex by DNS standards). Instead, the apex must be reserved for mandatory zone infrastructure records (such as SOA, NS, DNSKEY). Placing opaque application payloads at the apex violates the architectural principle of namespace isolation. All application- specific data MUST be strictly segregated under the _utxo prefix subdomain. 5. DNS Resource Record Format (RDATA) The resource record used for deployment prior to formal RRTYPE allocation is the RFC 3597 Private-use space (QTYPE 65400). If a generic RRTYPE (e.g., BINARY or CONTAINER) is later allocated by IANA, implementations SHOULD migrate to it. The RDATA MUST be treated as a purely opaque byte stream by DNS servers and resolvers. Per [RFC3597], DNS servers MUST store, cache, and forward this record without interpreting its content. 5.1. Payload Encoding The RDATA payload MUST be encoded using the Concise Binary Object Representation (CBOR) [RFC8949]. Because the RDATA contains no internal DNS-level type indicator, clients MUST rely on the _utxo prefix to know that they must decode the RDATA as a CBOR map containing the following logical fields: o v (Version): Schema version. o utxo: The blockchain UTXO reference (txid and vout). o ep: The payment endpoint (e.g., blockchain address, IBAN). o proof: Optional cryptographic proofs (e.g., VRF proof, TEE attestation). o vlei: Optional vLEI DID reference for legal entity compliance. Payload Size Constraint: The total RDATA length MUST NOT exceed 512 bytes. A typical CBOR endpoint is 16-24 bytes, and a VRF proof is ~80 bytes. 5.2. Examples A query for _utxo.merchant.utxo IN TYPE65400 might return an opaque CBOR payload. Using the dig utility with the Private-use RRTYPE code: dig _utxo.merchant.utxo IN TYPE65400 +short The output is a raw hexadecimal stream representing the CBOR data. Valid Example (Prefix-isolated): _utxo.example.test. 3600 IN TYPE65400 \# 24 ( 82A1F6... ) Valid Example (Agent-specific): _utxo.agent01.example.test. 3600 IN TYPE65400 \# 104 ( 82A1F6... 58A0... ) Invalid Example (Apex placement): example.test. 3600 IN TYPE65400 ... 6. Resolver Behavior and RFC 3597 Per RFC 3597, resolvers that do not implement this specification MUST treat the Private-use QTYPE 65400 as an unknown type. The RDATA is stored and forwarded as unstructured binary data. The UTXO application introduces no new protocol state, no additional section processing, and no assumptions about wildcards or DNAME. 7. Client Resolution and Verification Because the DNS protocol does not validate the payload, all security and verification logic is placed in the endpoint client (wallet/ TEE): 1. The client sends a DNS query for _utxo. with the QTYPE set to 65400. 2. The client receives the opaque RDATA. 3. The client decodes the RDATA as CBOR. 4. The client verifies the cryptographic proofs within the CBOR payload (e.g., checking the VRF proof against the UTXO owner key). 5. The client utilizes the extracted endpoint to construct the payment. 8. Security Considerations Cache Poisoning: Constrained to 512 bytes. Middlebox Interference: A dedicated Private-use RRTYPE avoids TXT- specific string manipulation. Proof Verification: Resolvers do not validate the VRF proof. Clients MUST validate the CBOR structure and VRF proof. DNS is a cleartext protocol by default. Clients SHOULD use DNS-over- HTTPS (DoH) or DNS-over-TLS (DoT) to prevent tampering and eavesdropping on the payload. The DNSSEC extension (RFC 4033) authenticates the DNS zone data but does not verify the cryptographic integrity of the CBOR payload. Clients MUST independently verify the VRF proofs or TEE attestations embedded within the CBOR payload before initiating any payment. Fork and Rollback Resistance: In the event of a blockchain reorganization, the DNS layer remains unaffected as it only transports the opaque payload. The TEE client establishes deterministic finality by verifying the VRF proof and maintaining a local monotonic nonce state, rejecting any rollback-induced replay attempts regardless of the underlying chain state. 9. IANA Considerations This document does not request a new RRTYPE from IANA. To avoid public RRTYPE space congestion, this specification utilizes the RFC 3597 Private-use space (QTYPE 65400). No new IANA subregistry is requested for the CBOR schema, as schema versioning is handled internally within the CBOR map via the "v" field. If a generic binary RRTYPE is allocated by IANA in the future, implementers MAY transition to it. 10. Appendix A: Changes from -02 - Removed the dedicated UTXO RRTYPE (TYPE 260) request. - Adopted RFC 3597 Private-use space (QTYPE 65400). - Corrected Section 2: Removed incorrect statement regarding TXT wire format encoding. Clarified that TXT is rejected due to namespace collision and presentation format complexity. - Corrected Section 4.1: Removed incorrect CNAME rationale for Apex prohibition. Clarified that Apex is reserved for mandatory zone records. - RDATA is a purely opaque CBOR-encoded byte stream. - Retained the 512-byte payload size constraint. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records", RFC 8552, March 2019. [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 8949, December 2020. 11.2. Informative References [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. Author's Address Guorong Tian CoCa Foundation Email: foundation@utxocp.cn