draft-guorong-utxo-dns-02


Internet-Draft                                            G. Tian
Intended status: Experimental                              
Expires: 28 April 2027                                 CoCa Foundation
                                                         25 Oct 2026

       UTXO Domain Name System (UTXO6-DNS): Data RR for 
                  Cryptographic Endpoint Discovery

Abstract

   This document specifies a new DNS Data Resource Record (RRTYPE 260) 
   for transporting opaque cryptographic pointers. The RDATA contains 
   a CBOR-encoded endpoint identifier and an optional Verifiable Random 
   Function (VRF) proof. This document prohibits apex usage and 
   mandates the _utxo prefix.

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 28 April 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

   Application-layer protocols require DNS to resolve a domain name to a
   cryptographic endpoint (e.g., an IPv6 IID). This document defines a
   lightweight Data RR to act as a pointer.

   The DNS layer only transports the pointer. The CBOR payload is opaque
   to the resolver. No identity, compliance, or application-layer
   semantics are defined here.

2.  Why Not TXT?

   TXT was evaluated and rejected due to two practical engineering
   constraints:

   1. String Reassembly Failures: DNS TXT records are transmitted as an
      array of 255-byte <character-string>s. Clients must concatenate
      them to reconstruct the payload. If a middlebox (e.g., firewall,
      SPF/DKIM filter) modifies, truncates, or drops these chunks, the
      cryptographic proof is corrupted.

   2. Security Policy Isolation: TXT is a shared semantic space heavily
      used for SPF, DKIM, and domain verifications. Enterprise gateways
      cannot easily distinguish a cryptographic pointer from an email
      policy. A dedicated TYPE 260 allows network operators to apply
      explicit allow/deny rules to UTXO records without breaking
      standard TXT traffic.

3.  RDATA Format

   The UTXO RR has the following RDATA structure:

       +--------------------+-------------------+
       | Endpoint ID (CBOR) | VRF Proof (opt)   |
       +--------------------+-------------------+

   Endpoint Identifier: A CBOR-encoded byte string. It typically embeds
   an IPv6 IID or a short DID reference. The DNS treats this as opaque
   binary data.

   VRF Proof: OPTIONAL. A byte string containing a proof (RFC 9381)
   for offline verification.

   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. Total typical size is ~100 bytes.

4.  Naming and Apex Restrictions

4.1.  Apex Prohibition

   The UTXO RR MUST NOT be placed at the zone apex. While CNAMEs are
   prohibited at the apex (per RFC 1034), placing arbitrary business
   records at the apex can collide with future standard records (e.g.,
   SVCB, HTTPS) or zone-level delegation mechanisms.

   All UTXO records MUST be placed under an explicit prefix subdomain
   (e.g., _utxo) to ensure strict namespace isolation and allow zone
   administrators to delegate UTXO resolution independently of the
   primary zone infrastructure.

4.2.  Mandatory Prefix and Examples

   All UTXO records MUST be placed under the _utxo prefix.

   Valid Example:
   _utxo.example.test.     3600 IN UTXO \# 24 ( 82A1F6... )

   Valid Example (Agent-specific):
   _utxo.agent01.example.test. 3600 IN UTXO \# 104 ( 82A1F6... 58A0... )

   Invalid Example (Apex):
   example.test.           3600 IN UTXO ...

4.3.  Granularity

   Granularity is handled via explicit subdomains (e.g.,
   _utxo.alice.example.test), not wildcard matching. The DNS layer does
   not interpret subdomain labels as identity.

5.  Resolver Behavior and RFC 3597

   Per RFC 3597, resolvers that do not implement this specification MUST
   treat TYPE 260 as an unknown type. The RDATA is stored and forwarded
   as unstructured binary data. The UTXO RR introduces no new protocol
   state, no additional section processing, and no assumptions about
   wildcards or DNAME.

6.  Security Considerations

   Cache Poisoning: Constrained to 512 bytes.

   Middlebox Interference: A dedicated RRTYPE avoids TXT-specific
   string manipulation.

   Proof Verification: Resolvers do not validate the VRF proof. Clients
   MUST validate the CBOR structure and VRF proof.

7.  IANA Considerations

   Requesting one new Data RRTYPE:

   Mnemonic: UTXO
   Code: 260
   Type: Data RR
   Reference: This document
   Assignment Policy: Expert Review (RFC 6895)

8.  Appendix A: Changes from -01

   - Removed PRN compliance and vLEI logic from DNS payload.
   - Added Section 2: Rationale against TXT.
   - Added Section 4.1: Apex prohibition.
   - Updated examples to use _utxo prefix.
   - Hard-capped RDATA at 512 bytes.

Authors' Addresses

   Guorong Tian
   CoCa Foundation
   Email: foundation@utxocp.cn