How to Diagnose Stale DNS During a Proxy Gateway Rollover

A proxy gateway hostname can point to a new address while a running workload continues using the old route. The usual explanation is not one cache but several: authoritative DNS, a recursive resolver, the operating system, the application runtime, the HTTP client and an already-open connection pool can each preserve state for a different period.

This guide gives operations teams a controlled method for residential proxy, rotating proxy, data collection, market research and ad-verification workloads. The objective is to identify the layer holding stale state, prove that the new gateway works, and prevent an unsafe direct fallback during the change.

Recognize the three different failures

Do not treat every name-resolution error as “stale DNS.” Separate:

1. Positive-cache staleness: an older A or AAAA address is still returned or reused.
2. Negative-cache persistence: an earlier NXDOMAIN or no-data answer remains cached after the record is restored.
3. Connection reuse: DNS is fresh, but the client keeps an established TCP, TLS or HTTP/2 connection to the previous address.

These cases require different fixes. Restarting every worker may hide the real cause and create a retry surge.

Map every resolution and reuse layer

For the proxy gateway hostname, record:

• authoritative A, AAAA and CNAME records and their TTLs;
• recursive resolver used by the workload;
• container, virtual machine or host resolver configuration;
• runtime API used for resolution;
• client-library DNS cache policy;
• connection-pool idle and maximum ages;
• proxy session lifetime and sticky-session rules;
• load balancer or gateway health behavior.

Node.js dns.lookup() normally uses operating-system name-resolution facilities, while dns.resolve*() performs network DNS queries and does not use the same configuration path. A diagnostic that uses one API may therefore disagree with the application using the other.

libcurl keeps its own in-memory DNS cache. Its documented default cache timeout is 60 seconds, and that timeout is independent of DNS-record TTL. Current libcurl versions cache authoritative “name does not exist” failures for part of that interval, while transient or local resolver failures are handled differently. Record the client version before interpreting a test.

Establish a before-change baseline

Run a small authorized canary from every production region before the rollover. Capture only sanitized evidence:

timestamp
workload_region
resolver_alias
gateway_hostname_alias
answer_family
answer_set_hash
dns_lookup_ms
new_connection_or_reuse
connected_gateway_alias
proxy_auth_result
observed_exit_market
request_result

Do not log proxy passwords, tokens, cookies, customer identifiers or complete sensitive destination URLs.

Validate A and AAAA separately. A successful IPv4 test does not prove the IPv6 path, and address-order changes can alter which family a runtime tries first.

Perform the rollover in controlled stages

1. Lower the authoritative TTL early

Reduce TTL far enough in advance for the previous TTL to expire across normal resolvers. Confirm the new value from multiple production regions. Changing the TTL at the same moment as the address does not shorten entries already cached under the old value.

2. Add the new address before removing the old one

Where the architecture permits, overlap old and new healthy gateways. Verify proxy authentication, TLS hostname validation, allowed methods, bandwidth, exit selection and logging on the new gateway before shifting all traffic.

3. Test a pinned connection without changing DNS

Use a safe client mechanism that binds the gateway hostname and port to the new address for one canary. Preserve the hostname for TLS and proxy authentication; do not replace it with a raw address in production configuration. A pinned test isolates gateway readiness from resolver behavior.

4. Compare fresh processes and warm processes

Run the same request from:

• a new process with no application cache;
• a warm process with an existing DNS cache;
• a warm process with connection reuse disabled for the canary;
• the normal production pool.

If only the production pool reaches the old address, inspect connection lifetime before flushing DNS.

5. Remove the old address only after evidence converges

Require the expected answer set, successful new connections, correct proxy egress and stable application results across all required regions. Keep an explicit rollback window.

Diagnose negative caching

An NXDOMAIN event deserves a separate timeline. RFC 2308 defines negative caching using information from the zone’s SOA record. A record recreated immediately after an authoritative negative answer may remain invisible to some clients until the negative cache expires.

For a negative-cache incident:

1. confirm whether the authoritative answer was NXDOMAIN, no-data, timeout or local failure;
2. inspect the SOA values used for the negative-cache lifetime;
3. query the production recursive resolver, not only a public diagnostic resolver;
4. compare a fresh resolver path with the affected application path;
5. avoid tight retry loops while the negative entry is valid;
6. verify recovery after the expected expiry time.

Do not convert every lookup failure into an address rotation. A transient resolver outage and an authoritative missing name are different operational signals.

Keep the proxy fail-closed

During DNS failure, a proxy-required workload must not silently remove its proxy setting or connect directly to the destination. Test that:

• unresolved proxy names stop the job or enter a bounded queue;
• stale addresses cannot bypass proxy authentication;
• fallback gateways are explicitly approved and independently tested;
• NO_PROXY rules do not expand during recovery;
• retries have exponential backoff, jitter and a total budget;
• queued work has an expiry time and spend limit.

Measure first-attempt success separately from eventual success. A 100% final success rate can conceal minutes of stale routing and excessive retries.

Use a decision table

Acceptance checklist

• [ ] The same gateway hostname remains valid for TLS and authentication.
• [ ] Old and new A and AAAA sets are documented.
• [ ] Authoritative and recursive answers agree after the planned window.
• [ ] Fresh and warm application processes are tested.
• [ ] New connections and reused connections are distinguished.
• [ ] The new gateway passes authentication and exit-market checks.
• [ ] Direct fallback is blocked.
• [ ] Retry and queue budgets prevent a recovery storm.
• [ ] Logs contain no credentials or sensitive URLs.
• [ ] The old gateway is removed only after regional evidence converges.
• [ ] Rollback criteria and owner are recorded.

For related controls, review the 98IP guides on proxy failover recovery drills, SOCKS5 remote DNS testing, and validating proxy provider SLAs.

FAQ

Should the application DNS cache exactly follow record TTL?

Not necessarily. Client libraries and operating systems may implement separate cache policies. Document the actual behavior of the production stack instead of assuming the authoritative TTL controls every layer.

Is flushing DNS enough?

No. An established connection can continue using the old gateway after DNS is fresh. Test with connection reuse disabled, then drain pools gradually if reuse is the cause.

Should we set DNS caching to zero?

Usually not as a blanket fix. Disabling caching can increase resolver load and latency. Choose a bounded cache and connection lifetime that matches the rollover objective, then verify it under load.

Can we switch the proxy hostname to a raw IP address?

That can break TLS hostname validation, gateway routing and operational flexibility. Use a controlled pinning mechanism for diagnostics while preserving the expected hostname.

Compliance note

Use proxies only for lawful, authorized workloads. Respect destination terms, robots instructions, access controls, privacy obligations and rate limits. DNS changes, alternate gateways and retries must not be used to evade an access decision. Retain only the diagnostic data needed for reliability and compliance.

Internal research basis: curl project documentation for DNS cache timeout; Node.js DNS documentation; IETF RFC 2308 on negative DNS caching. Source URLs are retained only in the internal operations record.