UTXO Domain Name System (UTXO-DNS): A Distributed Domain Name System Based on the Blockchain UTXO Model

1.3.1. Key Terms

This document uses the following key terms:¶

1.3.2. Protocol Terms

This protocol uses the following ABNF syntax to define domain name formats:¶

domain-label      = 1*16(ALPHA / DIGIT / UTF8-char)
domain-name       = domain-label *("." domain-label)
utxo-domain       = domain-name ".utxo"
regional-domain   = domain-name ".utxo" "." region-code
region-code       = 2ALPHA  ; ISO 3166-1 alpha-2

Where UTF8-char refers to UTF-8 encoded characters conforming to RFC 3629.¶

2.1.1. Protocol Stack

The UTXO-DNS protocol stack is as follows:¶

Application:   HTTP/HTTPS, SMTP, other application protocols
               |
UTXO-DNS:      Domain Name Resolution Protocol
               |
Transport:     JUPC/TCP, JUPC/UDP
               |
Network:       JUPC/IP
               |
Data Link:     Ethernet, Wi-Fi, 5G, etc.

2.2.1. Syntax Definition

UTXO-DNS-name = global-domain / regional-domain

global-domain = label *("." label) ".utxo"
regional-domain = label *("." label) ".utxo" "." region-label
region-label = 2*63(ALPHA)

label = let-dig [*61(let-dig-hyp) let-dig]
let-dig = ALPHA / DIGIT
let-dig-hyp = ALPHA / DIGIT / "-"

idn-label = *(ALPHA / DIGIT / other-utf8)
other-utf8 = UTF8-char  ; Unicode characters conforming to IDNA2008

2.2.2. Domain Classification

Example: jmbc.user.utxo
Structure: [organization].[namespace].utxo

Example: jmbc.user.utxo.hk
Structure: [organization].[namespace].utxo.[region-code]
Region code: follows ISO 3166-1 alpha-2 standard

4.1.1. A Record (IPv4 Address)

Type value: 1¶

Data format: 32-bit IPv4 address in network byte order¶

Example: 192.0.2.1¶

4.1.2. AAAA Record (IPv6 Address)

Type value: 28¶

Data format: 128-bit IPv6 address in network byte order¶

Example: 2001:0db8:85a3:0000:0000:8a2e:0370:7334¶

4.1.3. CNAME Record (Canonical Name)

Type value: 5¶

Data format: Canonical domain name using DNS name compression¶

Example: www.jmbc.user.utxo¶

4.1.4. TXT Record (Text Information)

Type value: 16¶

Data format: One or more character strings, each up to 255 characters¶

Example: "v=spf1 include:_spf.jmbc.utxo ~all"¶

4.2.1. JMBC Record (Digital Currency Address)

Type value: 257 (experimental)¶

Data format:¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Version(1)  |  Address Type |        Address Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                            |
+                      JMBC Address (variable)                 +
|                                                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.2. CBDC Record (Central Bank Digital Currency Address)

Type value: 258 (experimental)¶

Data format:¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Version(1)  |   CBDC Type   |         Country Code          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


|                         Address Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                             |
+                      CBDC Address (variable)                 +
|                                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.3. DID Record (Decentralized Identifier)

Type value: 259 (experimental)¶

Data format: JSON-LD representation of a W3C DID document¶

Example:¶

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:utxo:jmbc.user.utxo",
  "verificationMethod": [...],
  "authentication": [...]
}

5.1.1. Detailed Registration Steps

1. The client sends a domain registration request to the resolver contract, containing the desired domain name and registration period.¶

2. The resolver contract checks whether the domain name is available (not registered and not on the reserved list).¶

3. If available, the resolver contract returns the registration fee and payment address.¶

4. The client sends a transaction containing JMBC payment to the specified address.¶

5. After verifying the payment, the resolver contract creates a domain UTXO record on the blockchain.¶

6. The client receives the transaction hash of the successful registration as a receipt.¶

5.2.1. Recursive Resolution Flow

The recursive resolution flow is as follows:¶

Client                         Recursive Resolver               Authoritative Resolver
|----------Query Request------->|                                                  |
|                               |-------On-chain Query------------------------------------->|
|                               |<-----Resolution+Proof-------------------------------------|
|<-----Response+Proof-----------|                                                 |
|                                                                           |
|-----Verify Proof (optional)--->|                                                  |

5.2.2. Iterative Resolution Flow

The iterative resolution flow is as follows:¶

Client                          Local Resolver                  Root Resolver   Authoritative Resolver
   |--------Query Request------->|                                  |                                 |
   |                             |--------Query Root Resolver------->|                                 |
   |                             |<-----Return Auth Resolver Addr  |                                |
   |                             |--------Query Auth Resolver------->|------------------------------------------------>|
   |                             |<-----Resolution+Proof--------------|<------------------------------------------------|
   |<-----Response+Proof---------|                                 |                                 |

6.1.1. Attack Types

UTXO-DNS faces the following types of attacks:¶

• Domain Hijacking: an attacker attempts to illegitimately gain control of a domain.¶

• Cache Poisoning: polluting resolver caches to return false records.¶

• Man?in?the?Middle Attacks: intercepting and modifying DNS queries/responses.¶

• DDoS Attacks: denial?of?service attacks against resolution services.¶

• Sybil Attacks: creating many fake nodes to influence the network.¶

• Private Key Leakage: theft of a domain owner?s private key leading to domain theft.¶

• Smart Contract Vulnerabilities: security flaws in resolver contracts.¶

6.2.1. Cryptographic Guarantees

UTXO-DNS employs the following cryptographic mechanisms:¶

1. Digital Signatures: all domain operations require the owner?s signature, using ECDSA (secp256k1) or EdDSA (Ed25519).¶

2. Merkle Proofs: on?chain proofs of record existence and validity.¶

3. Zero?Knowledge Proofs: optional identity privacy protection using zk?SNARKs or zk?STARKs.¶

4. Post?Quantum Algorithms: support for migration to post?quantum cryptography (PQC), including lattice?based signature schemes.¶

6.2.2. Operational Security

Operational security mechanisms include:¶

1. Timelocks: delays for sensitive operations (e.g., ownership transfer), default 24 hours.¶

2. Multi?signature: important domains can be configured with multi?sig control, requiring m?of?n signatures.¶

3. Emergency Recovery: recovery mechanism for lost private keys via social recovery or custodial services.¶

4. Sybil Attack Mitigation: registration limits and staking requirements; new registrations must stake JMBC.¶

5. Rate Limiting: rate limiting on frequent operations to prevent abuse.¶

6.3.1. Privacy Threats

Privacy threats in UTXO-DNS include:¶

• Query Monitoring: attackers monitoring DNS queries to analyze user behaviour.¶

• Ownership Correlation: linking real identities to users via domain ownership.¶

• Transaction Graph Analysis: analysing blockchain transaction graphs to infer user relationships.¶

• Metadata Leakage: metadata exposed during resolution leaking user information.¶

6.3.2. Privacy?Enhancing Technologies

UTXO-DNS adopts the following privacy?enhancing technologies:¶

1. Encrypted Queries: support for Oblivious DNS over JUPC (ODoJ) using HPKE for end?to?end encryption.¶

2. Differential Privacy: adding Laplace noise to query statistics to protect aggregate privacy.¶

3. Ephemeral Identifiers: support for short?lived domains with automatic expiration for privacy.¶

4. Anonymous Credentials: anonymous proof of domain ownership using CL signatures or BBS+ signatures.¶

5. CoinJoin Techniques: transactions using CoinJoin or similar techniques to enhance privacy.¶

7.1.1. DNS Parameters Registry

Assign the following values in the "Resource Record (RR) TYPEs" sub?registry of the "DNS Parameters" registry:¶

7.1.2. Port Numbers Registry

Assign the following ports in the "Service Name and Transport Protocol Port Number" registry:¶

7.2.1. UTXO-DNS Error Codes Registry

Create a "UTXO-DNS Error Codes" registry with the following initial values:¶

The registration policy for this registry shall be "Standards Action".¶

7.2.2. UTXO-DNS Flags Registry

Create a "UTXO-DNS Flags" registry to record flag definitions in UTXO-DNS messages.¶

The registration policy for this registry shall be "Expert Review".¶

8.1.1. Patent Disclosure Obligations

According to RFC 8179, all entities participating in the development of this standard must:¶

1. Early Disclosure: disclose known essential patents in a timely manner during the standardisation process.¶

2. Licensing Commitment: commit to license essential patents on reasonable and non?discriminatory (RAND) terms.¶

3. Transparency: publicly disclose patent holdings to avoid patent ambush.¶

8.1.2. CoCa. Foundation Patent Commitment

The CoCa. Foundation hereby declares that:¶

For any patented technology essential to the implementation of this specification, the CoCa. Foundation commits to grant royalty?free licenses to all implementers, with licensing terms conforming to the IETF RAND principles.¶

9.1.1. Compatibility with Legacy DNS

UTXO-DNS is designed with compatibility with legacy DNS in mind:¶

1. Protocol Compatibility: uses a query?response model similar to traditional DNS.¶

2. Record Type Compatibility: supports traditional DNS record types (A, AAAA, CNAME, TXT, etc.).¶

3. Extension Mechanism: uses EDNS(0) extension mechanisms for compatibility.¶

4. Proxy Gateway: provides a proxy gateway from legacy DNS to UTXO-DNS.¶

9.1.2. Compatibility with ENS

Differences between UTXO-DNS and the Ethereum Name Service (ENS):¶

UTXO-DNS plans to provide a bidirectional bridge with ENS, allowing domain migration between the two systems.¶

9.2.1. Blockchain Performance

UTXO-DNS adopts the following strategies to mitigate blockchain performance limitations:¶

1. Layered Storage: only ownership proofs and critical metadata are stored on?chain; resolution records are stored off?chain.¶

2. State Channels: high?frequency updates are handled via state channels and settled periodically on the main chain.¶

3. Batch Processing: multiple operations are packed into a single transaction to reduce on?chain load.¶

4. Cache Optimisation: extensive use of caching to reduce on?chain queries.¶

5. Sidechain Scaling: sidechains handle resolution queries while the main chain handles ownership transfers.¶

9.2.2. Resolution Performance

Domain name resolution performance optimisations:¶

1. Local Caching: clients and resolvers implement multi?level caching.¶

2. Prefetching: intelligent prefetching based on access patterns.¶

3. Parallel Queries: query multiple resolvers in parallel, using the fastest response.¶

4. Proof Batching: batch verification of Merkle proofs.¶