Cloudflare Changed DoH JSON. What Else Is Parsing DNS as Text?

By Greg Nowak. Last updated 2026-08-12.

Cloudflare’s recent change to its DNS-over-HTTPS JSON responses is fairly narrow. The engineering problem it exposes is not.

On July 28, 2026, Cloudflare began rolling out breaking formatting changes for additional record types returned by the 1.1.1.1 DoH JSON endpoint. Old and new representations may coexist during the rollout. The same parser could see one shape in a test and another in production, even when the queries look much the same.

The obvious question is whether an application calls Cloudflare directly. The more useful question is where DNS answers are being treated as fixed-format text. That might be a certificate check, a monitoring rule, a provisioning job, an inventory process, a Bash pipeline, or a small Python utility nobody has touched for two years.

Readable JSON is still not a DNS schema

Cloudflare supports DoH through both JSON and standardized DNS wire-format request paths. JSON is attractive for understandable reasons: ordinary HTTP tools can fetch it, people can inspect it, and small scripts can use it without much setup.

The trap is assuming that every string inside that JSON is a permanent contract. DNS resource records have structures that depend on their type. Code that relies on fixed spacing, quoting, escaping, field order, or one generic textual representation is effectively inventing its own private protocol on top of the API.

RFC 3597 defines a generic textual encoding for unknown DNS resource-record types. Cloudflare says that some affected records previously used this generic format and are moving to improved display formats. The new output may be clearer to a person while still breaking code built around the old string.

Where to look	Warning sign	Practical repair
Bash pipelines	A field is selected by whitespace position	Use type-aware parsing and reject unfamiliar shapes
Python utilities	One regular expression handles every answer	Parse by record type and test against stored fixtures
Monitoring checks	Any string difference is treated as a DNS change	Validate and normalize record data before comparison
Critical automation	Human-readable JSON text is treated as a durable interface	Move to the standardized DNS wire format

A quick triage guide for consumers of Cloudflare’s DoH JSON responses.

This is easy to miss in routine health checks. The HTTPS request can succeed. JSON decoding can succeed. The program can still misunderstand the answer and pass the wrong value downstream.

Find every consumer before changing one parser

Searching a repository for the Cloudflare hostname is a useful start, but it will not produce a complete inventory. The endpoint may live in configuration, be assembled from variables, sit behind an internal helper, or be called from a scheduled container that is maintained elsewhere.

The review should include:

references to the 1.1.1.1 DoH JSON endpoint or its media type;
HTTP calls followed by extraction from JSON answer fields;
regular expressions, whitespace splitting, and positional access around DNS data;
jobs that pass DNS results into certificate, security, provisioning, or asset systems;
alerts and dashboards that compare raw answer strings.

For each consumer, note its owner, runtime, requested record types, parsing method, downstream action, and how a failure becomes visible. Priority should follow consequence. A broken report is inconvenient; an automatic access-control change based on a misread answer is a different class of problem.

Test the mixed-format period, not one fresh response

Cloudflare warned that both representations may appear during the rollout. Capturing one current response and turning it into a regression test is therefore not enough. Tests need representative fixtures for both accepted shapes and for every affected record type the integration actually consumes.

It helps to test the integration in three separate layers:

Transport: Did the HTTPS request complete with the expected status and content type?
Envelope: Can the response be decoded, and does it contain the required JSON members?
Meaning: Can each answer be interpreted according to its DNS record type and validated before use?

Keeping those checks separate prevents a misleading green result. A zero exit code proves that a command ran. A decoded object proves that the payload was valid JSON. Neither proves that the DNS data was understood correctly.

Add negative fixtures as well. The parser needs a deliberate response to an unknown type, an unfamiliar representation, a missing field, or ambiguous data. When automation can make consequential changes, a visible failure is generally safer than producing a value that looks plausible but is wrong.

Let the consequence determine the contract

Cloudflare recommends the standardized DNS wire format for critical use cases. Its DoH documentation separates the JSON and wire-format paths, while RFC 8484 defines the application/dns-message representation used to carry DNS messages over HTTPS.

This does not require every small diagnostic script to become a full wire-format client overnight. It does mean that the chosen representation should reflect the cost of getting an answer wrong.

Critical integrations: Prefer a mature DNS implementation that uses the standardized wire format.
Smaller internal tools: JSON can remain appropriate when parsing is type-aware, inputs are validated, both formats are covered by fixtures, and failures are observable.
Temporary diagnostics: Human-readable output is useful for inspection, but it should not quietly become a production dependency.

Cloudflare supports both GET and POST for DoH requests. Switching between them will not fix a dependency on presentation text. The architectural choice is whether the application consumes displayed JSON strings or standardized DNS messages.

Repair in controlled batches

Once the consumers are ranked, the work can proceed without a sweeping rewrite. Capture representative inputs, add fixtures for the old and new formats, replace positional string handling with record-aware logic, validate the normalized output, and deploy with monitoring. If an integration is moving to wire format, run the old and new implementations side by side long enough to compare their results before removing the JSON path.

Monitoring should distinguish request failures from decoding failures, unsupported representations, validation failures, and downstream rejections. Folding all of those into a single “DNS lookup failed” counter removes the evidence needed to diagnose a rollout problem.

Rollback deserves the same care. Reverting application code may not bring back Cloudflare’s previous response, especially while formats coexist. The dependable fallback is either a parser that accepts every documented transition shape or a tested move to the standardized representation.

Use this change to inspect the surrounding plumbing

The Cloudflare notice is a good reason to examine other infrastructure integrations that consume convenient text. Look for code whose interpretation changes when spacing, quoting, escaping, or presentation changes while the underlying data remains the same. That code is coupled to formatting rather than meaning.

A focused review can map the consumers, identify the paths with real operational consequences, preserve representative fixtures, and assign a proportionate repair to each one. Greg can help with that work across Bash, Python, monitoring, provisioning, and related API integrations, without turning every modest script into an architecture project.

The immediate job is to handle both Cloudflare response formats safely. The more valuable outcome is a clear view of which systems parse DNS as text, why they do it, and what they might do the next time that text changes.