Cloudflare 1.1.1.1 DoH JSON 變了怎麼辦？先避免硬編碼 data 格式

先確認是資料格式差異，不是 DNS 查詢失敗#

先保留 HTTP 狀態、JSON 的 Status、record type 和 data，不要只記錄最後的解析例外：

1
curl -fsS \
2
  -H 'accept: application/dns-json' \
3
  'https://cloudflare-dns.com/dns-query?name=cloudflare.com&type=HTTPS'

成功 response 仍然可能是 JSON，例如：

1
{
2
  "Status": 0,
3
  "Answer": [
4
    {
5
      "name": "cloudflare.com",
6
      "type": 65,
7
      "TTL": 300,
8
      "data": "1 . alpn=h3,h2 ipv4hint=..."
9
    }
10
  ]
11
}

這裡要分開看三個層次：

1. HTTP 是否成功，例如 200。
2. DNS response 的 Status 是否代表查詢成功。
3. 你的程式是否能依 type 解讀 data。

前兩層都成功，第三層仍可能因格式差異失敗。用 type 而不是只看文字內容判斷 record 類型，才能把問題定位在解析邏輯。

Cloudflare 這次改了哪些 data 格式#

官方公告列出三組變更：

• CAA、NAPTR、RP、IPSECKEY、SVCB、HTTPS、TLSA、SSHFP、OPENPGPKEY 等額外 record，可能從 RFC 3597 的泛用十六進位格式改成標準 presentation format。
• RRSIG、DS、CDS、DNSKEY、CDNSKEY 的 DNSSEC algorithm identifier 改用數字，例如 RSASHA256 對應 8；DS digest type 也改用數字，例如 SHA-256 對應 2。
• HINFO 的 character-string 會個別加上引號，避免值內有空白時產生歧義。

另外，Cloudflare 明確提醒 rollout 期間可能同時拿到新舊格式。因此只替一個 fixture 加判斷，並不能保證其他 record type 已經完成遷移。

解析程式要依 record type 分流#

如果你的需求只是列出 DNS 查詢結果，至少先保留型別與原始資料，讓日後能回放問題：

1
function normalizeAnswers(payload) {
2
  return (payload.Answer ?? []).map((record) => ({
3
    name: record.name,
4
    type: record.type,
5
    ttl: record.TTL,
6
    data: record.data,
7
  }));
8
}

接著依 type 對應到 DNS library 或自己的 parser。不要寫成「只要把 data 用空白切開，固定取第 2、3 欄」；SVCB、HTTPS、NAPTR 和 DNSSEC record 的欄位規則不同，呈現格式也可能在 rollout 中改變。

可以把測試拆成以下幾組：

若你不需要把 record 內容轉成自己的結構，最安全的選擇是把 data 視為供顯示或記錄的文字，不要再對它做沒有規格依據的二次解析。

重要用途改用 DoH wireformat#

Cloudflare 文件將 JSON 定位為方便查詢的格式，並指出關鍵用途應使用符合 RFC 1035 的 DNS wireformat。wireformat 的請求不是把 name、type 放在 JSON 裡，而是先由 DNS library 產生二進位 query：

1
# <base64url-encoded-dns-query> 要由 DNS library 產生
2
curl -fsS \
3
  -H 'accept: application/dns-message' \
4
  'https://cloudflare-dns.com/dns-query?dns=<base64url-encoded-dns-query>' \
5
  --output response.bin

若使用 POST，則將二進位 query 放在 request body，並使用 content-type: application/dns-message。回應也要交給支援 DNS wireformat 的 library 解碼，不要把 binary response 當 JSON 讀取。

這個分流適合：

• DNSSEC 驗證或稽核。
• 需要穩定欄位結構的監控與資料管線。
• 不希望被特定 resolver 的 JSON 顯示習慣綁住的服務。

使用 wireformat 不代表所有錯誤都消失；你仍要處理 HTTP 400、413、415、504，以及 DNS response code。

一個可回滾的遷移流程#

不要直接把 production parser 改成「接受任何字串」。可以按這個順序處理：

1. 把目前 JSON response、查詢參數、HTTP status 和查核日期存成 fixture。
2. 依 type 補上 CAA、SVCB、HTTPS、DNSSEC 的新舊資料案例。
3. 對只需要穩定結構的流程，改評估 wireformat。
4. 先在 shadow 或測試流程同時執行新舊 parser，記錄差異但不改主流程。
5. 確認監控能區分「DNS 查詢失敗」和「解析器拒絕未知格式」後，再切換 production。

結論是：Cloudflare 1.1.1.1 的 DoH JSON 仍可用，但 data 不應被當成固定 schema。查詢型工具可以保留 JSON 並依 record type 驗證；關鍵資料管線則應使用 wireformat，或至少把格式差異納入測試與可觀測性。

常見問題#