latency based routing becomes difficult when teams manage addresses, identity, policy, and service state in separate places. The immediate task may appear narrow, but the operating risk usually comes from stale evidence, unclear ownership, and changes that are not verified end to end.
This article examines using measured path delay as one input to DNS-based global traffic steering. It follows the editorial questions raised by the referenced Infoblox article while keeping every product statement inside verified ZDNS DNS, DHCP, IPAM, GSLB, and NACS capabilities.
The objective is a repeatable operating model. It should work during ordinary provisioning, urgent troubleshooting, infrastructure failure, migration, and recovery, without relying on unsupported guarantees or transferring another vendor's features to ZDNS.
Latency Is an Input, Not a Promise
Latency-based routing uses measured delay to influence where new DNS-guided connections go. It cannot guarantee application response time because resolver caching, network variation, server load, and application dependencies continue after the answer is returned.
ZDNS GSLB supports this stage within the verified ZDNS product boundary. Capture ownership, scope, source, and timestamp as part of the record. A value without provenance can look authoritative long after the underlying system has changed.
The evidence should let an operator explain what was intended and which live observations support the current state. For latency based routing, that traceability is more useful than a broad feature claim because it shows whether the system can support daily operations and difficult recovery conditions.
Define the User-Critical Destination
Define destinations, user populations, capacity, business priority, and the transaction that matters. A path to a listening port may be fast while the application behind it is slow or unavailable.
ZDNS DNS supports this stage within the verified ZDNS product boundary. Test the behavior with representative production conditions rather than a clean demonstration dataset. Include incomplete evidence, conflicting records, and an interrupted dependency.
The test passes only when the discrepancy is visible, assigned, corrected, and reflected back into the governed record. For latency based routing, that traceability is more useful than a broad feature claim because it shows whether the system can support daily operations and difficult recovery conditions.
Measure from Representative Locations
Place probes where they represent actual users and carrier paths. A measurement from one data center cannot describe every region. Record probe source, interval, timeout, and the distribution rather than relying on one sample.
ZDNS IPAM supports this stage within the verified ZDNS product boundary. Apply least privilege to administrators, service accounts, and delegated teams. Broad access may make a pilot easy but creates an unsafe long-term operating model.
The design is acceptable when a delegated team can complete its work without gaining access to unrelated scopes or controls. For latency based routing, that traceability is more useful than a broad feature claim because it shows whether the system can support daily operations and difficult recovery conditions.
Separate Network Delay from Application Readiness
Separate network round-trip delay from transport, TLS, HTTP, and transaction readiness. Eligibility should use an appropriate health test; latency should rank destinations only after they can serve the request.
ZDNS GSLB supports this stage within the verified ZDNS product boundary. Define how the workflow fails and recovers. Stale data, timed-out requests, unreachable enforcement points, and partially completed changes need visible states and owned responses.
The recovery result must be checked from a representative client path, not inferred from a management screen. For latency based routing, that traceability is more useful than a broad feature claim because it shows whether the system can support daily operations and difficult recovery conditions.
Build Health Eligibility Before Ranking
Remove failed or maintenance destinations before comparing delay. A fast unhealthy site is not a valid answer. Define behavior when probe infrastructure itself is uncertain so every destination is not removed accidentally.
ZDNS DNS supports this stage within the verified ZDNS product boundary. Preserve history so operators can reconstruct the state at the time of an incident. Current state alone is insufficient when addresses, devices, users, and destinations change.
Historical queries must return the device, lease, policy, or destination associated with the event time rather than today's holder. For latency based routing, that traceability is more useful than a broad feature claim because it shows whether the system can support daily operations and difficult recovery conditions.
Use Stable Thresholds and Hysteresis
Use smoothing, thresholds, consecutive observations, and hysteresis. Switch only when the improvement is meaningful and sustained, then require stability before switching back. This prevents routing oscillation around tiny measurement changes.
ZDNS IPAM supports this stage within the verified ZDNS product boundary. Use staged rollout and explicit rollback criteria. The first production wave should be small enough to observe yet realistic enough to expose dependencies.
A rollback must restore both service behavior and the shared management record without leaving duplicate or stale objects. For latency based routing, that traceability is more useful than a broad feature claim because it shows whether the system can support daily operations and difficult recovery conditions.
Publish the Authoritative DNS Answer
Authoritative DNS converts the selected destination into an address or alias. Delegation, zones, records, access controls, logging, and DNSSEC must remain correct while routing policy changes.
ZDNS GSLB supports this stage within the verified ZDNS product boundary. Measure the consumer outcome. A successful server process or API response does not prove that the client received the intended address, access, name, or application destination.
Monitoring should distinguish healthy, degraded, stale, unknown, and intentionally excluded states. For latency based routing, that traceability is more useful than a broad feature claim because it shows whether the system can support daily operations and difficult recovery conditions.
Account for Resolver and Client Caching
Recursive resolvers and clients cache answers, so traffic transitions gradually. Measure actual changes from representative resolver paths and retain enough capacity at old and new destinations during the overlap.
ZDNS DNS supports this stage within the verified ZDNS product boundary. Separate policy intent from implementation detail. This keeps the design understandable when sites, network equipment, or service endpoints change.
Operators need a concise answer to why this result occurred and which rule or data source was decisive. For latency based routing, that traceability is more useful than a broad feature claim because it shows whether the system can support daily operations and difficult recovery conditions.
Protect Capacity and Business Priority
Latency ranking must respect capacity, maintenance, contractual, and recovery constraints. A slightly faster destination should not receive traffic beyond its safe load or override a protected standby policy.
ZDNS IPAM supports this stage within the verified ZDNS product boundary. Turn exceptions into a queue with an owner and deadline. Hiding unknown or conflicting state only makes the next change less reliable.
Capacity, security, and continuity constraints should remain effective while the preferred path is unavailable. For latency based routing, that traceability is more useful than a broad feature claim because it shows whether the system can support daily operations and difficult recovery conditions.
Verify the User Outcome and Recovery
Correlate probe state, authoritative answers, resolver observations, new connections, and application success. Restoration should return traffic gradually after sustained health rather than immediately chasing the lowest measurement.
ZDNS GSLB supports this stage within the verified ZDNS product boundary. Review the workflow after recovery as well as failure. A service is not fully restored until temporary overrides are removed and normal policy is verified.
The final review should produce an updated runbook, ownership decision, or policy correction rather than only a successful test report. For latency based routing, that traceability is more useful than a broad feature claim because it shows whether the system can support daily operations and difficult recovery conditions.
Operational Acceptance Checklist
- Probe from networks that represent actual users.
- Exclude unhealthy destinations before comparing delay.
- Require a meaningful improvement before switching.
- Preserve capacity and maintenance constraints.
- Measure resolver, connection, and application results.
Run the checklist with representative networks and retain evidence. Record the policy or data version, relevant timestamps, source systems, expected outcome, actual outcome, and recovery action. Repeat after material network, application, or integration changes.
Conclusion
Latency-Based Routing: Measure the Path Before You Change the DNS Answer is ultimately an operations discipline. Reliable results depend on accurate context, explicit ownership, bounded permissions, current evidence, explainable decisions, verified actions, and practiced recovery.
ZDNS GSLB provides relevant infrastructure capabilities for this work and connects naturally with the other ZDNS DDI, traffic-management, or access-management products linked above. A successful deployment makes uncertainty visible and turns exceptions into owned work instead of hiding them behind a dashboard.