Weighted DNS

Expanded Definition

Weighted DNS is a traffic distribution technique, not a load-balancing guarantee. It lets operators assign relative weights to records for the same hostname so resolvers and recursive caches gradually expose users or services to different endpoints. That makes it useful for controlled change, regional failover experiments, canary releases, and comparing the behaviour of two production paths under similar demand.

The important boundary is that weighted DNS influences where clients are sent, but it does not control what happens after resolution. Health checks, client-side retry logic, caching behaviour, and any upstream routing layers can all distort the intended split. In practice, the observed traffic mix may differ from the configured weights, especially at low request volumes or where resolvers cache answers aggressively.

Industry guidance is consistent on the core idea, but implementations vary across DNS providers and traffic managers. For identity and machine-to-machine services, that variability matters because a hostname can represent a production endpoint, an API gateway, or a controller that multiple non-human identities depend on.

Examples and Use Cases

Practitioners use weighted DNS when they want partial exposure rather than a full cutover. It is common in release engineering, resilience testing, and infrastructure migration because it gives teams a reversible way to observe production behaviour before committing fully.

• Sending 10% of lookups to a new API endpoint while the remaining traffic stays on the established service.
• Shifting a small portion of traffic to a regional backup to observe latency, error rates, or certificate behaviour.
• Splitting access between old and new controller endpoints during a migration window so rollback remains simple.
• Comparing two backend stacks under live conditions without changing the application hostname.

One practical tradeoff is that DNS-based traffic shaping is coarse. It is easier to operate than application-aware routing, but it can be less precise when session stickiness, cached answers, or long-lived connections matter. That makes it best suited to gradual transitions rather than fine-grained request steering.

Security Implications

Misunderstanding weighted DNS can create a false sense of control. Teams may believe they are sending a tightly bounded fraction of traffic to a new target, while caches, health probes, and client behaviour produce a different exposure pattern. If the destination is under-tested, that gap can turn a small rollout into a broader service incident.

Security issues also appear when the hostname fronting a sensitive service is repointed without a clear inventory of dependent systems. Non-human clients often retry aggressively, pin assumptions about endpoint stability, or use stored DNS answers longer than expected. A partial routing change can therefore surface broken authentication flows, certificate mismatch errors, or upstream allowlist failures long before a human notices.

The practitioner observation to watch is simple: the configured weight is not the same as the realised traffic share. That distinction becomes especially important when many machine identities, service accounts, or automation jobs rely on the same name and expect stable resolution.

Domain and Governance Relevance

In identity-heavy environments, weighted DNS is part of change governance as much as network routing. It affects how quickly machine-to-machine dependencies see new endpoints, how safely a service can be migrated, and how much trust is placed in a shared hostname as a stable control point. For NHI-driven systems, the hostname may be the entry point through which API keys, tokens, and service certificates reach the target.

That means ownership matters. Teams need clarity on who can change weights, who validates the resulting behaviour, and who is accountable when a partial shift exposes hidden coupling. Weighted DNS is therefore useful not only for release staging but also for proving whether non-human consumers can tolerate endpoint churn without losing availability or access continuity.

When used well, it reduces blast radius. When used casually, it can hide dependency sprawl because many services continue to resolve the same name while silently depending on different backends.

Related resources from NHI Mgmt Group

• What breaks when internal DNS names are preserved but access governance is not updated?
• Why do DNS and edge configuration changes create IAM and security risk?
• What breaks when DNS resolver bugs affect an identity-aware proxy?
• How should teams control high-risk DNS changes in Route53?