HTTPDNS

Reading time: 10 minute Word count: 2077

Network DNS HTTP HTTPDNS

System DNS may be good enough most of the time, but mobile and large-scale businesses still keep pulling name resolution back into the application. They are not reinventing a slower wheel. They are taking the resolution control point back.

Once a business starts caring about carrier-path interference, local access steering, canary routing, cross-network consistency, and resolution observability, the system resolver’s “it can return an address” answer is no longer always enough. HTTPDNS appears because many applications do not really want one standard DNS query. They want an address decision they can control themselves.

This article follows DNS and DNS pollution, and focuses on a different engineering tradeoff: why some systems are willing to turn resolution into an application-side HTTP request just to take back the power over who to ask, what to return, how long to cache, and when to fall back. DoH and DoT are related, but only as comparison boundaries, not as the main topic.

HTTPDNS is not about replacing DNS packets with HTTP packets. It is about moving the control point of name resolution from the operating system and network side back to the application and business infrastructure side

Why It Appears

The classic DNS division of labor is:

The application hands the name to the operating system
The operating system sends the query to the configured local resolver
The resolver walks the recursive chain and gets a result

But mobile and large-scale business requirements are often bigger than “get me one IP address”:

The business wants to know which resolution path the user actually went through
The business wants to control different regions, carriers, and client versions to different addresses
The business wants to bypass clear-text DNS interference in some networks
The business wants to bind scheduling, canary rollout, disaster recovery, and resolution results into the same backend policy

For the application, the blind spots are serious:

The system may know which recursive resolver was used, but the application often does not
The application may not know whether the answer came from local cache, ISP cache, or path injection
The same domain may resolve differently on different networks, and the application can only accept it passively

What It Changes

HTTPDNS does not change the namespace, delegation hierarchy, or authoritative system of DNS. example.com is still example.com, and the authoritative servers are still the same set of authorities. What changes is the application’s entry point for obtaining resolution results.

HTTPDNS is usually not a single standardized protocol like DoH or DoT. It is more like an engineering pattern. Different vendors and businesses may use different request formats, authentication methods, response structures, and scheduling logic, but they all share the same core idea: the application asks a business-controlled resolution service for an address result over HTTP.

The traditional path looks like:

App -> OS Resolver -> Local/ISP Recursive -> Authoritative

The HTTPDNS path looks more like:

App -> HTTPDNS Service (over HTTP/HTTPS) -> Recursive / Authoritative / Scheduling Logic

The application talks directly to a resolution service controlled by the business. That service can:

Do recursive resolution itself
Use its own cache
Combine region, carrier, and client identity into scheduling
Return business-defined TTL, priority, and backup addresses

The key change is not the protocol format. It is the boundary of responsibility:

System DNS means “resolve according to system configuration”
HTTPDNS means “return addresses according to business policy”

The Main Path for One HTTPDNS Query

Many implementations follow a path like this:

The application prepares to access a business domain
The application first sends an HTTP or HTTPS request to the HTTPDNS service
The HTTPDNS service returns one or more addresses based on the domain, the client source, the network, and its own policy
The application caches the result locally according to TTL or policy
The application connects directly to the returned address, while keeping the original domain name for upper-layer protocols

A simplified version looks like this:

App
  -> HTTPDNS API: name=api.example.com

HTTPDNS Service
  -> internal resolver / cache / scheduling
  -> App: 203.0.113.10, 203.0.113.11, ttl=60

App
  -> 203.0.113.10:443
  Host / SNI = api.example.com

HTTPDNS returns “which addresses to connect to”, not “delete the name from the system”. The name still matters because:

HTTPS certificate validation still depends on the domain
Upper-layer routing and virtual hosting still often split by Host or SNI
Business logs, configuration, and access control are still often organized by domain name

Why Many Businesses Prefer to Manage It Themselves

Because they want control, not just availability

System DNS is more like shared infrastructure. It aims to work for most programs on the device. HTTPDNS services often care more about business optimality.

What they want to solve is often not “can this name be resolved”, but “which address should this user connect to right now, and who should decide that?”

For example, a CDN business may really care about:

Which edge node is best for the current user
Which clients should be steered away during a degraded datacenter event
Whether different client versions should receive different address sets

Because they want to escape system and network black boxes

Once the application hands resolution to the operating system, it often no longer knows how many cache layers, forwarders, and policies sit in the middle. HTTPDNS at least pulls the first hop into the business-controlled scope:

The application knows which service it asked
The server knows who asked, what it asked for, and what it returned
Both sides can log, observe, and canary in a unified way

That is also why HTTPDNS often appears together with mobile telemetry, scheduling systems, and disaster-recovery platforms. It is not an isolated resolution optimization. It is part of the business control path.

Because it can bypass the most common clear-text DNS interference point

If pollution or hijacking mostly happens on the traditional UDP 53 path, moving the lookup to an HTTPS request to an HTTPDNS service makes it harder for the middle of the network to observe and forge the classic DNS query in the old way.

That does not mean HTTPDNS is automatically secure. It only means it avoids the most commonly interfered-with default path.

Why It Looks Like a Detour but Often Cannot Be Avoided

If the problem is DNS, why go use HTTP

Because many businesses are really missing:

An application-friendly request interface
A service that can be managed alongside authentication, observability, and scheduling systems
A controllable transport path that does not depend on local UDP 53

HTTP is easier for application developers to integrate with and easier to reuse with existing gateways, authentication, logging, and release systems. It does not look like a natural extension of standard DNS, but it is often more convenient for business infrastructure.

If the system already resolves names, why have the application do it again

Because the two resolution services are for different targets.

System DNS serves general-purpose programs on the device
HTTPDNS serves the business’s own address selection

Once the business wants to own scheduling and fallback, this application-side step is very hard to avoid.

If the IP is already returned, why can’t the client just connect to the IP

This is one of the easiest places to oversimplify HTTPDNS. Many people imagine it as “resolve to an IP and then connect to that IP”. For HTTPS, it is not that simple.

The client usually still needs to keep the original domain name for:

SNI in the TLS handshake
Hostname matching during certificate validation
Host or :authority in the HTTP request

Without the original name, many modern sites cannot complete HTTPS correctly. That is exactly why HTTPDNS is about replacing the address acquisition method, not the fact that the name still participates in connection semantics.

If it is meant to be more stable, why does it introduce a first-hop dependency

The application has to ask HTTPDNS before it knows which address to connect to next. That creates a new startup dependency:

The HTTPDNS service itself must already be reachable
There must be a fallback strategy if the first lookup fails
If the local cache is too short, first-hop pressure grows; if it is too long, scheduling converges too slowly

It moves part of the uncertainty from the system DNS black box to the business-owned resolution infrastructure.

What It Costs

Caching becomes more complex

System DNS already has a layered cache model: application, local machine, recursive resolver, upstream recursive resolver. Once HTTPDNS is introduced, the application adds another business cache on top.

Then you have to decide things like:

Is the TTL from the server authoritative, trimmed, or business-policy-based
After local cache expiry, do you refresh synchronously, asynchronously, or keep using the stale value briefly
When system DNS and HTTPDNS disagree, which one wins

This complexity used to be more of an operating-system and recursive-resolver concern. With HTTPDNS, much of it becomes application-owned semantics.

Fallback paths become more complex

HTTPDNS service unreachable, empty result, expired result, client network change: all of these require fallback design:

Fall back to system DNS
Fall back to the last cached value
Fall back to built-in backup domains or backup addresses

Fallback is necessary, but it also makes behavior harder to predict. During troubleshooting, you must know whether the current connection came from a fresh HTTPDNS result, an old cache entry, or a fallback to system DNS.

Address and scheduling results become harder to keep stable over time

HTTPDNS is valuable partly because of dynamic policy, but dynamic policy means results depend more on context:

The same user may get a different address after switching networks
The same domain may hit different nodes at different times
The same client version and an older client version may be assigned to different clusters

That is very useful for scheduling. It also makes “why am I connecting to this IP?” much harder to answer. Without enough observability, the control you gained can degrade into another black box.

It Is Not the Same as DoH, DoT, or DNSSEC

The difference from DoH / DoT

DoH and DoT mainly solve “how DNS queries are transported”. They place standard DNS requests into a protected transport and usually keep the standard DNS role split and semantics.

HTTPDNS is more about “who makes the address decision on behalf of the application”.

DoH / DoT focus on transport protection
HTTPDNS focuses on control-point transfer

More concretely, a DoH response is usually still a standard DNS semantic result. An HTTPDNS response often already contains business-shaped address sets that may include scheduling, canarying, priority, and fallback policy.

The two can coexist. An HTTPDNS service can absolutely use DoH, DoT, or traditional recursion internally to fetch upstream data.

The difference from DNSSEC

DNSSEC solves “whether this DNS data can be verified”. Its focus is answer authenticity and integrity. HTTPDNS does not directly provide that standardized verification semantics. It depends more on the trustworthiness of the business service itself and on transport protection.

So HTTPDNS is not a replacement for DNSSEC. It is just a different, business-controlled resolution path.

What Engineering Should Actually Think About It Today

HTTPDNS is best understood as a business resolution control plane, not as a “more advanced DNS protocol”. When deciding whether to adopt it, start by asking:

Does the business really need to control the resolution result itself instead of accepting the system default?
Can the business maintain a resolution service that is highly available, observable, and able to fall back?
After control is pulled back in, is there actually a team that can carry the complexity of certificates, caching, scheduling, and fallback?

For implementation and troubleshooting, the key is not “is it based on HTTP?”. The key is to keep these three things separate:

Who decided the current address
Whether that decision was a fresh result or a cache result
Which fallback path the client actually used when something failed

Once you keep those three things apart, HTTPDNS stops looking like “just DNS with another transport shell” and returns to its real place: an engineering redistribution of who owns the resolution decision.