How to Test Negative DNS Cache Recovery in Proxy Clients

A failed lookup is not one condition. An authoritative answer that a name does not exist and a temporary resolver failure may look similar to an application, yet caching them the same way can extend a short incident into a long outage. Proxy routing adds another question: did resolution happen locally, at the proxy, or at an upstream resolver?

This guide builds a repeatable recovery test. It is informed by the curl 8.22.0 release note published September 2, 2026, which states that negative resolves are now cached only for authoritative answers. The test remains useful for any HTTP or SOCKS client that maintains DNS or connection state.

Define the outcomes before testing

Classify every attempt as one of four outcomes:

• positive answer followed by a connection attempt;
• authoritative negative answer under the resolver's policy;
• transient resolution failure, timeout, or unavailable resolver;
• successful recovery after the temporary condition is removed.

Do not label every resolver error as “DNS down.” Capture the result class, the component that performed resolution, whether a cached answer was used, and whether a network connection was attempted.

Identify who owns resolution

Write down the resolution boundary for each route:

1. direct request with local resolution;
2. HTTP proxy request using the origin hostname;
3. HTTP CONNECT tunnel using the target hostname;
4. SOCKS request that sends a hostname to the proxy;
5. SOCKS or HTTP request that sends an already resolved address.

The exact behavior depends on the client and proxy mode. Verify it from controlled logs rather than inferring it from the exit IP. A remote-DNS route may use a completely different cache from a local-DNS route.

For cache separation beyond DNS, use the proxy response cache isolation test. If the evidence needs escalation, package it with the proxy support escalation guide.

Build a controlled fixture

Use a domain and resolver environment your organization controls. Prepare:

• a stable hostname with a known address;
• a deliberately nonexistent hostname that receives an authoritative negative answer;
• a hostname whose resolution can be temporarily delayed or failed in a test resolver;
• a recovery step that restores the temporary hostname to a valid answer;
• one direct route and each approved proxy route under test.

Use a harmless endpoint that returns a small deterministic response. Keep request method, headers, proxy session, target, and timeout policy fixed. Change only the resolution condition or route.

Capture the right evidence

Give each case an ID and record:

• timestamp and monotonic elapsed time;
• client and resolver versions;
• direct, HTTP proxy, CONNECT, or SOCKS route;
• local or proxy-side resolution owner;
• queried hostname and test case class;
• resolver result class and cache hit or requery evidence;
• connection start, connect result, and destination class;
• proxy session identifier class, without credentials;
• retry count and backoff interval.

Never log proxy passwords, API tokens, cookies, customer hostnames, or full production payloads. Test fixtures should contain no personal or confidential data.

Run the baseline

Start with clean client and resolver state:

1. Resolve the stable hostname directly and confirm connection success.
2. Repeat through every proxy mode and confirm where resolution occurs.
3. Query the authoritative nonexistent hostname twice within a bounded window.
4. Confirm that the result remains a negative answer according to the documented resolver policy.
5. Query the temporary hostname while the test resolver is healthy and confirm success.

This baseline proves the fixture works before failure injection. It also exposes accidental route changes, stale addresses, and connection reuse that could hide a lookup.

Exercise transient failure and recovery

Temporarily make only the controlled resolver path unavailable or delayed. Do not interfere with public infrastructure.

1. Start a fresh client attempt to the temporary hostname.
2. Confirm that the result is classified as transient, not authoritative negative.
3. Restore the resolver and valid answer.
4. Retry after the application's normal bounded backoff.
5. Require a new lookup and successful connection without restarting unrelated infrastructure.
6. Repeat with the same proxy session, then with a fresh session.
7. Repeat for local-DNS and proxy-side-DNS modes.

The acceptance result is simple: a transient failure must not create a durable negative entry that blocks recovery after the resolver is healthy. An authoritative negative answer may be cached only according to the resolver and client policy you intend to operate.

Separate DNS cache from connection reuse

A pooled connection can make a request succeed without a new lookup. A stale connection can also fail after DNS has already recovered. Run three explicit variants:

• force a new connection while retaining DNS cache state;
• clear DNS state while retaining the normal connection pool;
• start a clean process with neither state retained.

Compare the variants rather than assuming a retry caused resolution. Pool keys should keep security and routing boundaries separate, including target authority, proxy route, TLS trust profile, and authenticated session class.

Test retries without creating a storm

Use a small, fixed number of attempts and exponential backoff with jitter. Cap concurrency. A temporary resolver incident should not trigger rapid proxy rotation or a wave of duplicate requests.

Track recovery time, queries per logical request, successful connections, and retry amplification. If changing the proxy exit makes the test “pass,” return to the stable route and find the actual cache owner; exit churn is not a DNS-cache fix.

Acceptance checklist

• [ ] Resolution ownership is known for every proxy mode.
• [ ] Positive, authoritative negative, and transient results are distinct.
• [ ] The test uses owned names and a controlled resolver.
• [ ] The stable positive control succeeds on every approved route.
• [ ] The authoritative negative case follows the intended cache policy.
• [ ] A transient failure is retried only with bounded backoff.
• [ ] Recovery causes a new lookup and successful connection.
• [ ] DNS cache and connection reuse are tested independently.
• [ ] Proxy rotation is not used to mask the result.
• [ ] Logs exclude credentials and production data.

FAQ

Is every negative DNS answer safe to cache?

No. The important distinction is whether the negative result is authoritative under the applicable resolver policy or merely a transient failure. Treating temporary failure as durable absence delays recovery.

Does a SOCKS proxy always resolve the hostname?

No. Some modes send the hostname to the proxy; others send an address resolved by the client. Confirm the configured mode and observe the controlled test.

Why did the recovered request succeed without a DNS query?

It may have reused an existing connection. Force a new connection and test DNS state separately before drawing a conclusion.

Should I clear every cache during an incident?

Not automatically. First identify whether the stale state belongs to the application, operating system, resolver, proxy, or connection pool. Broad cache clearing can hide the faulty boundary and increase load.

Source and responsible-use note

Internal research basis: curl project, curl 8.22.0 release announcement and changelog, published September 2, 2026. External research URLs are retained only in the internal operations record; this public article contains no external links.

Run these tests only on domains, resolvers, proxy routes, and endpoints you own or are authorized to assess. Respect provider limits, privacy requirements, robots policies, and organizational change controls.