DNS over HTTPS, or DoH, carries ordinary DNS queries inside HTTPS exchanges. It is useful when an agent application needs authenticated communication with a selected DNS resolver, but encrypted transport is not permission to choose any resolver. A safe agent has an explicit policy for which resolver may answer which namespace, how its identity is authenticated, what to do with private company names, how long results remain valid, and what happens during failure. That policy is the subject of this guide.
The distinction matters because an agent may read a web page, call an API, or launch a workflow on another machine. Before any of those actions reach their destination, a hostname often has to become an address. A wrong answer, a policy leak, or a stale cached answer can redirect a task, break a deadline, or expose an internal service name. Transport encryption solves one part of that problem; application authorization, DNS integrity and operational policy solve others.
Contents
The short answer: what a resolver policy does
— The five actors in one lookup
— A lookup trace that can be audited
What RFC 8484 actually specifies
— GET versus POST is an operational choice
— Do not confuse HTTP status with DNS status
Resolver identity is a control plane decision
— TLS to a resolver and TLS to a service are different
Bootstrap before a resolver can resolve itself
Discovery is not arbitrary trust
Split DNS is where real deployments get difficult
— An illustrated namespace policy
Hand-check the cost of a split-DNS leak
Caching has two clocks, not one
— Hand-checked TTL and Age arithmetic
— The hidden denominator in cache-hit reports
DNSSEC and DoH answer different questions
— Keep origin security after DNS resolution
Timeouts and fallback are policy choices
An agent tool should never rewrite resolver policy
Designing a resolver-policy record
How to test both protocol and policy
— How to measure policy quality
A classroom analogy without losing the mechanism
Changed-context transfer: an agent moves between networks
— Explained arithmetic in the transfer case
Diagnostic failures and specific repairs
— An operator’s recovery order
Limitations and cases this mechanism cannot solve
FAQ: Does DoH make a model’s research private?
— FAQ: Should the system retry NXDOMAIN elsewhere?
— FAQ: Is DNSSEC required to use DoH?
— FAQ: Can a website tell the agent which DoH resolver to use?
Verified reader pathways in the eduKate library
The short answer: what a resolver policy does
A model is not the resolver
The language model that plans a task normally does not perform DNS resolution by itself. The runtime, operating system, proxy, container platform, gateway or browser stack usually resolves names. Sometimes several of these layers cache answers. A prompt saying “use the safe resolver” changes nothing unless a trusted component translates policy into configuration and enforces it. A diagnostic must identify that component, not merely attribute the result to “the AI.”
Present-day agent systems can prepare network requests, consult tools and act under delegated authority. The title of this series does not mean that artificial superintelligence has been built or deployed. The engineering here applies to software agents regardless of how capable a model becomes. Treat the resolver as security-sensitive infrastructure, and treat model output as untrusted task material that must never override the configured network boundary.
The five actors in one lookup
A useful lookup diagram contains five boxes: the user or calling service, the agent runtime, its DNS client, the configured resolver, and the authoritative sources from which the resolver assembles answers. The client may send a question such as an A or AAAA lookup to a DoH endpoint over HTTPS. The resolver may answer from cache or perform additional resolution. None of that requires sending the user’s private task context as text; the DNS name is enough to request an address record.
Separate the identity of the HTTPS resolver endpoint from the identity of the eventual website. An authenticated connection to a resolver proves whom the client is asking, subject to normal TLS validation. It does not prove that the destination address is safe, that its website certificate will match the name, or that its response is authorized to receive credentials. These later checks belong to network egress and application protocols.
A lookup trace that can be audited
For each attempted connection, retain a trace containing the original requested hostname, the policy rule selected, the resolver endpoint identifier, the query type, the cache decision, and the result category. Also retain the decision to allow or deny the downstream connection. Do not write secrets, cookies or complete private document contents into this trace. Use suitable retention limits and access controls because hostnames can reveal commercially or personally sensitive activities.
If a program tries to contact api.example.test, a representative trace might say: public namespace, configured resolver P1, A record requested, cache miss, validated HTTPS transport, answer accepted under policy, subsequent HTTPS destination certificate checked independently. If the domain is payroll.corp.example, the trace should instead show the internal route or an explicit block. These are illustrative labels, not real observed production events. The audit objective is to reconstruct why an action was possible, not merely whether it succeeded.
What RFC 8484 actually specifies
RFC 8484, published in October 2018, defines how one DNS query and one DNS response map onto an HTTP exchange secured with HTTPS. Its defined media type is application/dns-message, which carries DNS wire-format messages. DoH does not invent an alternative domain-name grammar. DNS names, record types, response codes and normal DNS semantics remain relevant while the transport changes.
A server implementing RFC 8484 must support both GET and POST. With POST, the client sends the DNS message in the HTTP request body and advertises its media type. With GET, the DNS query is placed in the URL using base64url encoding of the DNS message, not a plain hostname string. The request and response can be encrypted in transit, but query metadata is still visible to the selected resolver. “Encrypted” is therefore not a synonym for “no party can see the name.”
GET versus POST is an operational choice
A GET request is attractive where HTTP caching can reuse a response for the same encoded query and the caching semantics have been engineered correctly. POST is often more compact because it avoids the URL encoding overhead and places the DNS message in the body. The standard requires server support for both, but application policy can choose an allowed method depending on the endpoint and threat model.
Neither method makes a request safe by itself. A GET URL may be recorded by intermediaries or application logging, while POST traffic may still be visible to the endpoint and its infrastructure. A production configuration should forbid logging query-string contents where unnecessary, set cache instructions deliberately, and verify that diagnostics record only the minimum identifiers needed. Do not assume GET means public data or POST means secret data: both require appropriate handling.
Do not confuse HTTP status with DNS status
An HTTP success response can contain a DNS message reporting an unsuccessful DNS lookup. The transport layer and DNS application layer have different status spaces. An HTTP 200 response may mean the DoH exchange itself succeeded even when the DNS response code says that the name does not exist. Conversely, an HTTP 503 may mean the resolver service cannot complete the transport exchange before the DNS question is answered.
An agent that sees any HTTP 200 and declares the target reachable is wrong. A correct parser checks the HTTP layer, confirms the expected media type, parses the DNS message, examines the DNS response code, and only then considers the returned records. Errors should be classified before retrying; repeatedly retrying an authoritative negative answer is different from retrying a transient unavailable resolver.
Resolver identity is a control plane decision
RFC 8484 requires a client to use a configured URI template when selecting its DoH service. It does not authorize switching to an unfamiliar endpoint because a model suggested it, a web page supplied it, or an unsolicited response advertised it. The configured endpoint must be reached with proper HTTPS server identity validation. That is what prevents a DNS lookup from becoming a model-directed exfiltration channel.
Give each resolver profile an identifier, approved endpoint URI template, trusted certificate-validation configuration, allowed namespaces, applicable tenants, and fallback rule. The profile is a centrally reviewed configuration record, not arbitrary text in a retrieved document. Keep the trust store and change process under operator control. A new resolver is a security change because it can see query names and influence which addresses the client uses.
TLS to a resolver and TLS to a service are different
Imagine a client authenticates resolver R over HTTPS, receives an address for api.vendor.example, and then connects to that address. The first TLS handshake authenticates resolver R. A later TLS handshake must independently authenticate the service name api.vendor.example. Reusing the first decision as authorization for the second endpoint would be an identity-confusion error, especially if an attacker can influence DNS data.
Transport authentication also cannot decide whether the application should call that service. A finance agent might be permitted to resolve a public help site but forbidden from transmitting employee records to it. DNS policy, egress allowlists, OAuth scopes, service identity and user consent are separate checks. Building these as composable layers is safer than asking one mechanism to guarantee everything.
Bootstrap before a resolver can resolve itself
A DoH endpoint usually has a hostname. That creates a first-lookup problem: how does a client discover the resolver’s address before the resolver is working? RFC 8484 discusses bootstrap methods, including configuration supplied ahead of time or use of another resolution route while preserving HTTPS identity checks. An implementation must explicitly document its approved approach.
Do not make an unauthenticated emergency lookup an invisible permanent fallback. A bootstrap route can reveal the resolver hostname and, if badly implemented, invite redirection. A sensible design uses an operator-managed bootstrap address or narrowly scoped system resolver process, still validating the configured HTTPS hostname. Separate “we know an address to try” from “we trust the endpoint reached there.” On bootstrap failure, fail according to application policy rather than silently picking the first working public resolver.
The bootstrap deadlock test
Consider an agent container that has only one DoH endpoint, doh.example.net, but it has no cached address for that endpoint. Suppose its lookup of doh.example.net itself is routed back into the unavailable DoH connection. Nothing can start. A second possible cycle occurs when certificate status checking invokes network retrieval that itself depends on DNS resolution. These are topology and dependency failures, not model reasoning failures.
Draw a dependency graph on paper. If the resolver’s identity check requires a service that depends on the same resolver before the resolver is reachable, there is a cycle. Test startup with an empty cache, expired certificate material, and the primary route down. Any fallback must preserve trust and privacy policy rather than hiding the cycle behind a permissive bypass.
Discovery is not arbitrary trust
RFC 9462, published in 2023, describes Discovery of Designated Resolvers. It allows clients in specified circumstances to discover encrypted resolver configuration related to an existing unencrypted resolver, using DNS records and validation steps. The mechanism is explicitly narrower than “follow any DNS advertisement.” The designated resolver must be validated according to the specification before a client treats it as the encrypted counterpart.
An on-path attacker may block discovery messages or the encrypted connection, causing the client to miss a secure upgrade. This downgrade possibility cannot be wished away. Record whether an encrypted resolver was configured statically, discovered and validated, unavailable, or deliberately bypassed under written policy. If a product offers an encrypted DNS setting, determine which mode it implements and what its failure behavior is; do not infer a guarantee merely from a toggle label.
Split DNS is where real deployments get difficult
An organization may publish payroll.corp.example only through its internal DNS. A public resolver asked about that name might return no data, a different answer, or a response that violates the intended information boundary. RFC 8484 notes that resolver choice influences answers in split DNS environments. A client that replaces its operating system’s enterprise resolver with a global DoH endpoint can quietly break otherwise functioning applications.
Make namespace selection explicit. A rule can route corp.example to an internal policy-controlled resolver and public names to a reviewed public DoH endpoint. It must handle suffix boundaries precisely. A careless string comparison that treats evilcorp.example as inside corp.example permits a spoofed domain to inherit internal routing. Canonicalize the hostname, check label boundaries, and reject ambiguous or malformed names before selecting a route.
An illustrated namespace policy
Use the following synthetic policy for teaching: names ending in the whole-label suffix .corp.example use internal resolver I; approved public names use encrypted resolver P; malformed names are denied; names presented as bare IP literals do not require DNS resolution but still need destination-policy checks. The table can also include tenant-specific names whose delegation requires a separate mapping.
Now try payroll.corp.example, corp.example, corp.example.attacker.test, and PAYROLL.CORP.EXAMPLE. The first two select I when rules include the apex. The third must not select I because it has additional labels after the protected suffix. The fourth should normalize to the first before matching. The expected outcomes should be specified in automated tests, not left to human intuition or model interpretation.
Hand-check the cost of a split-DNS leak
Suppose a hypothetical batch contains 200 name lookups from an internal reporting workflow. Exactly 16 names belong to the private suffix, while 184 names are public. If a naive “send everything to public DoH” configuration is applied, then 16 of 200 lookups, or 8%, are routed to the wrong resolver. That is a routing exposure rate, not a statistical estimate of confirmed data theft; the resolver may receive a name even if it returns no useful address.
If policy correctly routes all 16 internal lookups to I and all 184 public lookups to P, the misroute count in this test batch is 0 of 200, or 0%. This does not prove the policy flawless: a different suffix, search-domain expansion, application-level DNS library, or direct-IP connection may evade the test. The denominator and environment must be recorded for an honest pass result.
Caching has two clocks, not one
A DoH response may pass through an HTTP cache and a DNS cache. RFC 8484 requires assigned HTTP freshness lifetime to be no longer than the smallest TTL in the Answer section. A resolver cannot safely advertise a ten-minute HTTP freshness lifetime for a response whose answer contains a record expiring in thirty seconds. Clients also have to account for the HTTP Age field when determining usable DNS TTL.
This is why “we cached it” is not enough information. Audit both the DNS TTL remaining and the age of the HTTP response. Some responses are not cacheable under a particular implementation or policy. Some contain negative answers governed by appropriate negative caching rules. The precise behavior must follow applicable DNS and HTTP semantics; a general-purpose web cache must not become an unreviewed authority for stale endpoint mappings.
Hand-checked TTL and Age arithmetic
Assume a synthetic DoH response contains answer-section TTL values of 30, 600 and 300 seconds. The minimum is 30 seconds, so the server’s assigned HTTP freshness lifetime cannot exceed 30 seconds under the applicable RFC 8484 rule. If the HTTP response arrives at a client with Age: 12, there can be at most 18 seconds of freshness remaining from that 30-second HTTP cache lifetime, before accounting for any additional processing time.
For a different record with a stated remaining TTL of 600 seconds and HTTP Age of 250 seconds, the simple remaining-lifetime arithmetic gives 350 seconds, not 600. Do not use that latter record as permission to ignore the minimum-TTL rule for a whole multi-record response. These examples answer different questions: one limits an entire HTTP response; the other illustrates age adjustment of a record’s time budget.
The hidden denominator in cache-hit reports
Imagine 400 DNS lookup requests enter a client in one minute. If 150 are served legitimately from fresh cache entries, the cache-hit fraction is 150 divided by 400, or 37.5%. The other 250 requests may require upstream resolution, giving an upstream fraction of 62.5%. Those counts describe requests, not unique domain names, and they say nothing by themselves about correctness.
Now suppose ten of the 150 cache hits were stale due to a TTL bug. A naive dashboard still reports 37.5% cache hits, but 10 of 400 total requests, or 2.5%, received stale cache results in that interval. Optimizing the hit rate without freshness checks can produce a deceptively better-looking performance chart while making agent tool failures harder to reproduce.
DNSSEC and DoH answer different questions
DoH authenticates and encrypts communication between a client and the selected resolver under HTTPS. DNSSEC can provide validation of DNS data through DNS-specific trust chains where properly deployed. RFC 8484 explicitly says the mechanisms are independent and compatible. A secure channel to an untrustworthy resolver does not magically validate every DNS record that resolver provides.
If the agent runtime needs assurance of DNS data integrity, specify who performs DNSSEC validation, which trust anchor is used, how failures are reported, and whether the client accepts the resolver’s assertion or independently validates data. A DNSSEC validation failure should not silently turn into “use the same answer without checking.” Nor should a system assume that a DNSSEC-authenticated name grants permission to transmit private documents to the corresponding service.
Keep origin security after DNS resolution
Suppose the resolver returns two address records for the same hostname. The network stack may select one based on connectivity and policy. The next connection still needs the correct hostname for TLS verification and, where necessary, an application-level authorization decision. DNS resolution does not certify the destination’s business purpose or make HTTP redirects safe. Those concerns have their own control points.
An agent that follows a web link supplied by an untrusted tool must also guard against server-side request forgery, private-address targets and redirect-based escapes. Treat DNS rebinding and time-of-check/time-of-use gaps as possible hazards in designs where resolved addresses are used to apply an egress decision. Authorization should be enforced close to the actual connection, and checked again if the destination changes.
Timeouts and fallback are policy choices
A resolver can fail because of transport interruption, DNS timeout, failed TLS validation, HTTP service error, malformed DNS response, or authoritative DNS response with a negative answer. These failure categories are not interchangeable. A system that treats a negative answer as if it were a transport timeout may keep hammering the same name or choose another resolver that returns an inconsistent view.
A fallback rule must state whether a second configured resolver is allowed for that namespace and tenant, and whether it preserves equivalent privacy and trust. An internal secret namespace should not fail over to a public endpoint simply because the public endpoint works. A public endpoint whose certificate fails validation should not be retried with certificate checks disabled. For some high-value actions, blocking the tool step is the correct behavior; for lower-risk browsing, a constrained retry may be acceptable.
A bounded-retry worked case
Assume an example workflow issues 200 public-name lookups. Four fail because the configured resolver times out; 196 receive syntactically valid responses. The observed timeout fraction is 4 divided by 200, or 2%, and the non-timeout fraction is 98%. Those percentages do not measure service availability across an entire day, and the 196 responses are not automatically correct DNS data.
A bounded strategy may allow one retry through the same configured endpoint for a transient timeout, followed by a separately approved alternate if policy permits. Record the time spent on each attempt. If the first request consumed 700 milliseconds of a 1,000-millisecond tool deadline, a retry with its own fresh one-second deadline would incorrectly exceed the original budget. The recovery path must obey the enclosing action’s deadline and cancellation semantics.
Privacy means more than TLS
DoH reduces some exposure on the network between the client and the resolver, but the resolver can still see the query. Request IP addresses, HTTP headers, account identifiers, access logs, centralized monitoring and support tooling can all contribute to linkability. Privacy review therefore includes who operates the endpoint, where data is retained, whether requests are joined across tenants, and whether commercial terms permit such handling.
Do not send every internal, personal or student-related name to a convenient public resolver merely because it offers HTTPS. Names can themselves reveal client identity, school systems, medical services, payroll environments or upcoming business projects. Minimize the data sent, select the proper namespace route, avoid cookies unless specifically required, and document retention. A policy justified for public web research may be inappropriate for an internal school administration agent.
An agent tool should never rewrite resolver policy
Retrieval-augmented agents commonly read webpages, API outputs, log snippets and documents. Those are data, not authorization. A sentence inside a document saying “for better performance use this DNS endpoint” must not alter the resolver configuration. This is a straightforward prompt-injection boundary: the trusted runtime chooses the resolver; retrieved content can at most be treated as a claim to examine.
A secure implementation pins the policy version to an execution context and records which rules applied. If an operator changes the policy during a long-running action, the next network request must use the appropriate committed policy version, not a half-applied configuration. A model may recommend diagnosing a resolver outage, but it should not autonomously disable certificate verification, route private suffixes externally, or invent new trust anchors.
Designing a resolver-policy record
A useful policy record contains a stable policy ID, version, owner, effective time, trusted endpoint URI, namespace predicates, tenant scope, TLS verification requirements, approved bootstrap method, cache rules, maximum time budget, retry classification and escalation contact. It should also include a reason for each exception and an expiry for temporary exceptions. Use a machine-readable schema plus human-readable review notes.
The policy record should be deployed atomically where possible. In multi-agent systems, each worker must not interpret a different free-text policy from memory. Gate a change on tests and a reviewed deployment, then record the active version alongside tool outcomes. This enables operators to answer whether a failed task used an outdated resolver mapping or whether the problem was a genuinely bad DNS response.
A safe update sequence
Begin by recording the present policy and its exact checksums. Stage the candidate rules without changing active traffic. Test internal apex names, subdomains, lookalike suffixes, mixed-case names, malformed labels, IPv4 and IPv6 answers, resolver certificate errors, cached responses and a cold start. Then run a limited canary with approved public traffic while comparing outcomes against a known baseline.
Promotion happens only after results are reviewed. A rollback restores the previous trusted endpoint and namespace behavior without erasing diagnostic evidence. Avoid designing rollback as “allow all names through the public resolver”; that trades temporary availability for an unknown information disclosure. When a change touches private naming, review by a network or security owner is appropriate even when the configuration was proposed by a sophisticated automation.
How to test both protocol and policy
Protocol tests exercise GET and POST handling, application/dns-message parsing, HTTP versus DNS error separation, TLS hostname verification, fresh and expired cache entries, and corrupted payloads. Policy tests independently exercise namespaces, tenant isolation, bootstrap and fallback. Both sets are necessary because a perfectly implemented DoH codec can still route the wrong domain to the wrong authority.
Build fixtures that are deterministic and private. An example fixture maps test.company.invalid to a controlled internal resolver in a test environment and deliberately makes the public resolver return a different result. The acceptance criterion should be the selected resolver and final deny/allow decision, not only the text of the DNS answer. Do not use real internal names in public test fixtures, tutorials or screenshots.
How to measure policy quality
Report the number of names evaluated, the number classified into each namespace, wrong-route counts, TLS-validation failures, stale-hit counts, timeout counts, cache hits, and blocked unapproved fallback attempts. Record denominators. A rate without a numerator and denominator makes comparison misleading: three wrong routes out of 30 tests is 10%, while three out of 3,000 is 0.1%, but neither rate excuses an actual sensitive-name leak.
For production, measure the impact of policy changes with privacy-preserving aggregates and targeted synthetic probes rather than retaining every real lookup forever. Investigate spikes in refusal or fallback categories, especially after new network software is deployed. The goal is to discover whether an agent can reach intended services without silently crossing a trust boundary, not to celebrate an isolated latency number.
A classroom analogy without losing the mechanism
Imagine a school office that receives sealed envelopes requesting directions. The clerk sending the envelope over a protected courier route resembles a DoH client using HTTPS. The office that opens the envelope resembles the resolver: the route is private from casual observers, but that office still learns the question. Checking that the courier delivered it to the correct office resembles TLS identity verification.
Now add two address books: one for publicly listed shops and another for private school rooms. Even a perfectly protected courier cannot make it correct to send the private room names to the public directory. Split DNS is the rule choosing the right address book. This analogy helps learners see why encryption, identity, data accuracy and permission are distinct. The real protocol involves DNS records, caches and TLS rather than paper, so use the analogy as a scaffold, not as technical proof.
Changed-context transfer: an agent moves between networks
A tutoring organization deploys a research agent in an office where three naming namespaces work: public internet domains, a private staff suffix, and a temporary event network. The agent later moves into a third-party cloud environment. Public DoH continues to function, but the private suffix stops resolving and the event network is unavailable. A developer proposes making every failed internal name fall back to a free public resolver. What should the operator do?
The correct answer begins by classifying names, not by adding retries. The public namespace can continue through the approved DoH endpoint. The staff suffix requires a trusted internal path or must be blocked until a suitable secure connection exists. The event network needs explicit access policy or remains unavailable. Testing the move should include whether the cloud egress gateway enforces the same classifications. Sending private names to a public resolver would change disclosure policy, not merely fix connectivity.
Explained arithmetic in the transfer case
Suppose the relocated agent attempts 120 lookups during a controlled test: 90 public, 20 staff-only and 10 event-specific. If only the public resolver is configured, a permissive fallback would expose 30 names to an unapproved endpoint, which is 30/120 = 25% of attempted lookups. The correct privacy-safe configuration can complete the 90 approved public lookups and block the 30 unresolved private or special lookups. Its task-completion fraction is 90/120 = 75% in that synthetic test.
Do not call the 75% a “failure of encryption.” Encryption may have worked exactly as designed for all 90 public lookups. The missing capability is authorized routing for two additional namespaces. Once an internal gateway is available, rerun the same fixture and record the new result rather than quietly weakening confidentiality to raise an aggregate success percentage.
Diagnostic failures and specific repairs
If a resolver works for public sites but fails for private names, inspect split-horizon rules and search suffixes before touching TLS. If the error is a TLS hostname mismatch, check endpoint configuration, certificate validity and trust paths; never suppress validation. If a name resolves but the application cannot connect, separate address selection, firewall policy, destination TLS and authorization. If a name resolves inconsistently, compare the queried resolver, qtype and cached state.
If a cache seems “too fast” yet serves wrong addresses, inspect TTL and Age calculations. If a cold container cannot start, examine the DoH bootstrap chain. If some tenants see others’ internal namespaces, inspect routing predicates and shared cache partitioning. Each failure has an evidence-based next action. Generic instructions such as “clear everything and retry” can erase the conditions needed to diagnose the bug and can produce a brief false sense of improvement.
An operator’s recovery order
Use this order for a failing task: preserve the exact attempted hostname and timestamp in a protected trace; identify the active namespace rule; identify the DoH endpoint; verify TLS identity; distinguish HTTP failure from DNS response status; inspect authoritative versus cached results; compare against a controlled fixture; check the downstream connection; and only then change one policy variable. Record before-and-after behavior with the same test cases.
If two teams have different observations, compare their resolver views and local caches rather than assuming one team’s measurement invalidates the other. The two clients may legitimately receive different answers due to geography, load balancing or split DNS. Document whether those differences are expected under policy. A reproducible explanation is a better repair artifact than a screenshot of one successful ping.
Limitations and cases this mechanism cannot solve
DoH is not a substitute for DNSSEC validation, a trusted service certificate, access-control rules, confidential application payloads, or endpoint malware protection. It does not prevent the configured resolver from observing names. It does not automatically make all DNS decisions correct or guarantee the absence of traffic metadata leakage. It cannot decide which remote API an agent should be authorized to contact.
Group policy also creates trade-offs. A private resolver can become unavailable; more specific namespace rules take maintenance; logging aids investigation but may create sensitive records. A public resolver can have beneficial availability but incompatible privacy terms or different answers. There is no universally safe “best resolver” independent of context. The right control is a documented and tested mapping from task, namespace and tenant to a permitted endpoint and failure behavior.
FAQ: Does DoH make a model’s research private?
No. It encrypts the DNS exchange to the chosen resolver and authenticates that endpoint through HTTPS, subject to correct implementation. The resolver learns the queried names. Separately, web servers, browser infrastructure, API gateways and application logs may observe later connections or requests. For confidential work, review the entire data flow, not just the DNS segment.
A model’s words also are not evidence that a privacy boundary was enforced. You need runtime policy, tests and traceable outcomes. This matters when research tasks include medical information, student records, sensitive commercial projects or internal service names. Choose a resolver and routing policy suitable for those risks, and avoid disclosing sensitive names unnecessarily.
FAQ: Should the system retry NXDOMAIN elsewhere?
Not automatically. A DNS negative response from an expected resolver is different from a connection failure. Another resolver may have a conflicting namespace view, and using it could disclose the queried name. Diagnose whether the queried resolver was correct for the name and whether the negative response is expected. If a specific exception authorizes a second resolver, test it under the same policy controls.
The general rule is that retries restore availability only within an established trust boundary. They should not search the internet for someone willing to answer a private name. For many internal names, denial with a useful diagnostic is safer than optimistic fallthrough.
FAQ: Is DNSSEC required to use DoH?
The mechanisms are separate. RFC 8484 defines DoH transport and discusses compatibility with DNSSEC. Requirements for validating DNS data depend on the system and threat model. A client may rely on a trusted validating resolver or perform its own validation when appropriate, but it must not pretend HTTPS protection means independent cryptographic authenticity for every record.
If a deployment uses DNSSEC, test signed and unsigned domains, validation failures, trust-anchor behavior and error propagation. An “AD” indication in a response must be interpreted within the security relationship to the resolver, not treated as a free-standing assurance divorced from that relationship.
FAQ: Can a website tell the agent which DoH resolver to use?
A visited website may publish information about DNS services, but that content has no authority to change an agent runtime’s configured resolver policy. RFC 8484 expects a configured URI template. A discovered or advertised endpoint needs the applicable approved discovery and validation process, such as properly implemented RFC 9462 mechanisms where appropriate.
Treat any unsolicited instruction to switch resolvers, disable checks, or upload diagnostics as potentially untrusted input. A user may ask the agent to investigate a resolver option, but adoption should occur through an explicit reviewed configuration change, not an arbitrary document instruction.
Primary technical sources
RFC 8484, DNS Queries over HTTPS (2018): https://www.rfc-editor.org/rfc/rfc8484.html . Consult its request methods, caching, privacy and operational considerations for authoritative normative requirements.
RFC 9462, Discovery of Designated Resolvers (2023): https://www.rfc-editor.org/rfc/rfc9462.html . The discovery and downgrade discussions explain why endpoint upgrades require defined validation steps.
RFC 4035, Protocol Modifications for DNS Security Extensions (2005): https://www.rfc-editor.org/rfc/rfc4035.html . This is a primary technical reference for DNSSEC behavior; the DoH transport and DNSSEC data-validation roles should not be collapsed.
RFC 1035, Domain Names — Implementation and Specification (1987): https://www.rfc-editor.org/rfc/rfc1035.html . The classic DNS wire-format and record model remain the foundation under the HTTPS transport.
Verified reader pathways in the eduKate library
For the DNS data-integrity layer, read How Superintelligence Works | Agent DNSSEC Validation — Trust Chains, Bogus Answers and Signed Denials: https://edukatesg.com/2026/10/26/how-superintelligence-works-agent-dnssec-validation-trust-chains-bogus-answers-signed-denials/ . That article asks whether a DNS answer is cryptographically valid; this guide asks whether the system queried the appropriate resolver and respected its transport and routing policy.
For measured changes in authoritative records and client caches, read Agent DNS Change Verification — Authoritative Records, Cache Divergence and Safe Cutovers. For the separate step of validating an eventual HTTPS destination, read Agent HTTPS Trust — Certificate Chains, Hostnames and Failure-Safe Connections. These companion guides focus on the data and application-origin layers distinct from resolver selection.