DDns: Endpoint-aware DNS resolution beyond IP addresses

DDns Protocol

Map static names to dynamic network addresses.

The simplest connection model on the Internet is straightforward: know the target endpoint's name and send a communication request directly to it. This is the experience that DHttp is designed to provide. However, once the target endpoint's name is known, how can the system further discover its network-reachable address? Because an endpoint's network address cannot be represented by a single IP address alone, the DNS protocol must be extended to support name resolution for DHttp.

Introduction to DNS

Since the inception of the Internet, an IP address has carried two kinds of information: identity and location. As an identifier, however, an IP address is inherently limited:

- Lack of semantics: An IP address is an opaque numerical string and carries no human-readable meaning.

- Scarcity and gradual IPv6 adoption: The IPv4 address space has long been exhausted and cannot provide a unique public address for every endpoint, while IPv6 is still being adopted gradually.

- Address volatility: An IP address changes over time or by location, so it cannot satisfy the requirement that an identity remain stable.

That is why domain names and the DNS protocol emerged. Domain names provide three core capabilities:

- Stability: Even if the network address changes, the name remains stable. This is a critical foundation for identity.

- Memorability: Compared with an opaque numeric address, a name is much easier to remember and can also convey meaning.

- Resolvability: A stable name can be used as the lookup key for querying its corresponding network-reachable address.

The Limits of DNS

Conventional DNS host-address resolution relies primarily on A and AAAA resource records, which resolve names only to bare IP addresses. Consequently, the practical ability to use a name as a reachable service address remains largely reserved for cloud hosts with static public IP addresses. This resembles an early feudal society where names were a luxury of the nobility, leaving ordinary endpoints without an equal right to be named and reached. Furthermore, because cloud hosts usually expose services on well-known ports, A and AAAA records do not include transport-layer port information. This creates an architectural barrier for ordinary endpoints. Most ordinary endpoints reside inside local private networks behind NAT or move across mobile networks, making bare IP records insufficient for reaching them. To make DNS services equally available to all endpoints, a new DNS resource record type must be introduced.

DDns Extension

Once a traditional client endpoint gains peer-to-peer (P2P) communication capability, its architectural status shifts: it is no longer merely an outbound initiator, but a network-reachable endpoint. However, this network-reachable address cannot be described by a simple IP address. A and AAAA records are not enough; more information is required. Following the DQuic ep-&EP pair model, describing an endpoint address requires two transport addresses, each consisting of an IP address and a port:

- The publicly mapped transport address of ep.

- The public transport address of the public delegate endpoint EP.

enum EndpointAddr {

Direct {

addr: SocketAddr,

},

Mediate {

agent: SocketAddr,

outer: SocketAddr,

},

}

The address above is the network address of an internal endpoint. It contains two transport addresses, forming a DHttp endpoint address with two key advantages:

- Arbitrary port support: Including the port supports scenarios where endpoints use arbitrary or dynamically assigned ports, which is especially suitable for ordinary endpoints.

- Delegate-assisted global reachability: Internal endpoints includes the address of a public delegate endpoint, making it globally routable even while they remain inside a private network.

Encoding this address information with a combination of SRV and TXT records would be cumbersome and operationally complex. A better approach is to extend the DNS protocol with an Endpoint Address Record (E record), allowing ordinary endpoints to have DNS-resolvable names as well. The record resolves to the DHttp endpoint address described above, making DNS services equally available to ordinary endpoints.

E Records

An E record means an Endpoint Address Record. It uses 266 as its RTYPE identifier and has the following format:

+--------+--------+--------+----...-----+

| rtype = 266 | flags | rdata |

+--------+--------+--------+----...-----+

Unlike A records or AAAA records, which provide only a single IP address, an E record provides a public IP address and port. The port is included because every endpoint may expose a different public port. An E record also carries additional options indicated by the flags field.

flags is an 8-bit bitmap in which:

- Bit 1 indicates the address family: 0for IPv4 and1for IPv6.

- Bit 2 indicates whether the address is primary or backup: 1means primary and0means backup. This is useful when multiple devices cooperate under the same name.

- Bit 3 indicates whether one name corresponds to multiple hosts, which is suitable for multi-host stateless clusters such as Web services. 1means multiple devices, and in that case the E record includes a device index.

- Bit 4 indicates whether NAT traversal is required. 1means it is required, and the E record then includes the public delegate endpoint address.

- Bit 5 indicates whether endpoint load information is carried for scheduling. 0means not included and1means included.

- Bits 6 and 7 are reserved.

- Bit 8 indicates whether a signature is included. 1means the E record carries a signature generated with the publishing endpoint's private key, helping prevent DNS spoofing and tampering.

Self-Reporting

Traditional A records and AAAA records must first be configured in a DNS management console with the target IP address. This requires operational updates and introduces the risk of manual configuration errors. E records are different. They require no DNS management console maintenance. Publication and updates are initiated by the endpoint itself. The endpoint probes its own network-reachable address whenever it is online. Once it discovers that address, it reports it automatically, which eliminates operational mistakes. At the same time, the endpoint signs the E record content with its own private key, helping prevent spoofing and tampering.

The only things that must be configured correctly are the device identity key and certificate, the primary or backup role of the device, and, when multiple devices share the same name, a unique device index.

Multi-Address Endpoints

In real-world networks, many devices have more than one IP address. For example, a mobile phone may have both a cellular network and a Wi-Fi network, and each network may have both an IPv4 address and an IPv6 address. Each IP address family on each network interface corresponds to one address record, so a single endpoint can have multiple address records.

The Relationship Between Names, Endpoints, and E Records:

One name can correspond to multiple endpoints, as is common for stateless Web server clusters. One endpoint can also have multiple address records, such as one IPv4 record and one IPv6 record. In traditional DNS, the association between an endpoint and its multiple address records is not preserved. That is unfriendly to QUIC and prevents QUIC from fully using multipath transport to establish more robust connections. The E record extension solves these problems. First, under the same name, each endpoint can have its own resolution records through indexing, making scheduling easier. Then, records with the same index can have multiple address records, allowing QUIC to use multipath transport when establishing a connection.

If a name is used by only one endpoint, then all address records correspond to that endpoint. These address records can be used for multipath handshakes in QUIC, improving QUIC connection quality. However, if one name is used across multiple endpoints, it becomes necessary to distinguish which address records belong to the same endpoint. That is exactly why bits 2 and 3 in the E record flags field exist. They make it possible to identify multiple related address records for the same target endpoint, so a multipath handshake can be used to establish a QUIC connection.

Isolation in the Namespace

To avoid conflicts with traditional DNS domain names, all DHttp names are registered under the dhttp.net subdomain.

For convenience, .dhttp.net can be abbreviated as ~, for example:

- home domain: .home.dhttp.net, abbreviated as.home~

- robot domain: .robot.dhttp.net, abbreviated as.robot~

- service domain: .svc.dhttp.net, abbreviated as.svc~

- car domain: .car.dhttp.net, abbreviated as.car~

Traditional DNS domain names do not usually end with real-world surnames, because there are too many surnames and maintaining them would be too costly. One surname would require one organization, which is not flexible enough. In DDns, however, surnames can appear in the tail domain, making names closer to real-world naming patterns.

DNS Resolution

Because E records are an extension of the DNS protocol, they can also integrate with existing DNS-related protocols such as mDNS and HTTP DNS, both of which can support E records with little implementation difficulty. However, E records are not yet an Internet standard, and traditional DNS systems do not understand them. As a result, E records are currently usable only between DHttp protocol endpoints, while traditional domain names still use traditional DNS resolution.

mDNS First

The E record extension also applies to mDNS. If the target endpoint is on the same local network, the E record resolved through mDNS takes priority. If the E record of the target name can be discovered through mDNS, then internal-network communication can be used directly, which is both efficient and secure.

When using mDNS, the

.dhttp.netdomain is mapped to the._dhttp.localdomain to adapt to the mDNS protocol.

Local Name:

The standalone name dhttp.local has a special meaning. It is for local use only and represents localhost.

HTTP DNS

The HTTP DNS service is responsible for registering and querying E records for DHttp names. The resolver is also responsible for validating that the name is legitimate and verifying the record-content signature. This helps authenticate record publishers and reduces the risk of identity spoofing and record tampering.

Decentralized DNS

In the future, DDns will ultimately run on a DHT-based distributed key-value (KV) database. Each DHT node will store part of the name resolution records and cache DNS records for popular names to speed up DDns resolution. At that point, DDns will be able to operate in a fully decentralized way. There will no longer be large-scale failures caused by DNS misconfiguration or DNS outages. DNS will no longer be a single point of failure, and the Internet will become highly resilient.

System DNS

For names outside the DHttp domain namespace, the system DNS resolver uses gethostbyname or getaddrinfo to resolve them, ensuring smooth access to the traditional network.

Name Lookup Tools

Online Lookup

gmutils Tool

You can use the genmeta-nslookup tool to inspect the resolution result of a name:

genmeta nslookup bob.lee~

# Output:

# Name: bob.lee:

# H3 DNS Resolver(https://ddns.genmeta.net/)

# Address: 1.12.74.4:20004-45.248.109.11:5072