2026年6月5日

DoH（DNS over HTTPS）と DNSSEC を併用する設定：検証するリゾルバの選び方と確認方法

DNS・名前解決

DoH と DNSSEC は守る範囲が違うため、併用すると互いの弱点を補えます。DoH は「端末とリゾルバの間の通信」を暗号化し、DNSSEC は「答えそのものが本物か」をドメインの持ち主の署名で確かめます。併用の要点は、DNSSEC を検証する DoH リゾルバを選ぶこと、端末側でその DoH を有効にすること、そして検証が本当に行われているかを確認することの3つです。この記事では、ブラウザ・OS・自前リゾルバの設定と、curl や dig を使った確認方法を説明します。

DoH と DNSSEC はそれぞれ何を守るのか

DNS の問い合わせは、端末 →（スタブ）→ リゾルバ →（反復問い合わせ）→ 権威 DNS という経路をたどります。

DoH（RFC 8484）: 端末とリゾルバの間を HTTPS で暗号化します。同じネットワーク上の第三者による盗み見や書き換えを防ぎますが、リゾルバが権威 DNS から受け取った答えが本物かどうかは保証しません。
DNSSEC: 権威 DNS の答えに署名を付け、リゾルバがルートからの信頼の連鎖をたどって検証します。改ざんされた答えは検証に失敗して捨てられますが、通信の中身は暗号化されません。

一般的な端末は自分では DNSSEC を検証せず、リゾルバの検証結果（応答の AD フラグ）を信頼します。従来の平文 DNS ではこの AD フラグ自体が途中で書き換えられるおそれがありましたが、DoH を使えばリゾルバまでの区間が保護されるため、リゾルバの検証結果をそのまま受け取れます。この組み合わせが「併用する意味」です。

なお、DNSSEC の恩恵を受けるには、問い合わせ先のドメインが署名されている必要があります。自分の WordPress サイトのドメインを訪問者に正しく届けたいなら、DoH の設定とは別に、自分のドメインで DNSSEC を有効にしておく必要があります。

DNSSEC を検証する DoH リゾルバを選ぶ

公開 DoH リゾルバの多くは DNSSEC を検証しています。代表的なものは次のとおりです（2026年10月現在）。提供条件やエンドポイントは変わることがあるため、各事業者の公式ドキュメントで確認してください。

Cloudflare（1.1.1.1）: https://cloudflare-dns.com/dns-query
Google Public DNS: https://dns.google/dns-query
Quad9: https://dns.quad9.net/dns-query

選ぶときは、検証の有無に加えて、ログの保存方針（プライバシーポリシー）、フィルタリングの有無、自分の地域からの応答速度も見ます。社内ネットワークでは、社内向けの名前が解決できなくなるため、会社のリゾルバ以外の DoH を勝手に使うと業務に支障が出ることがあります。管理者の方針に従ってください。

端末側で DoH を有効にする

画面の項目名はバージョンによって変わるため、目的で探してください。

Firefox: 設定の「プライバシーとセキュリティ」にある DNS over HTTPS の項目で保護レベルとプロバイダーを選びます。Firefox は既定の DoH を有効にする前に use-application-dns.net という確認用ドメインを問い合わせ、ネットワーク側が無効化を求めていれば従います。
Chrome / Edge: 設定のセキュリティ関連の項目に「セキュア DNS を使用する」に当たる設定があり、プロバイダーを選ぶか、独自の DoH の URL を入力します。
Windows 11: ネットワークアダプターの DNS サーバー設定で、対応している DNS サーバーの IP を指定すると DNS over HTTPS を選べます。
Linux（systemd-resolved）: DoH には対応しておらず、DNSOverTLS= による DoT と DNSSEC= による検証の設定が用意されています。DoH を使いたい場合は、後述のローカルプロキシを挟む方法があります。

ブラウザの DoH はそのブラウザだけに効き、OS の他のアプリには効きません。「ブラウザでは見えるのに、ターミナルの curl では違う IP が返る」といった差は、この違いから生じることがよくあります。

検証されているかを確認する

curl で JSON API を使う

Cloudflare と Google は、DoH と同じ仕組みで JSON 形式の応答を返す API を公開しています。応答の "AD": true が、リゾルバが DNSSEC の検証に成功した印です。

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A&do=1'

curl -s 'https://dns.google/resolve?name=example.com&type=A'

署名されていないドメインでは "AD": false になります。これはエラーではなく、「検証できる署名がない」という意味です。

dig の DoH 対応を使う

BIND 9.18 以降の dig は DoH での問い合わせに対応しています。

dig +https +dnssec @1.1.1.1 example.com A

flags に ad が付けば、DoH 経由で検証済みの答えを受け取れています。dig は既定では DoH サーバーの証明書を厳密に検証しないことがあるため、証明書の確認まで含めて試したい場合は、利用中の dig のマニュアルで関連オプションを確認してください。

検証失敗を確かめる

検証が働いていることは、わざと署名を壊したテスト用ドメイン（例: dnssec-failed.org。提供状況は変わることがあります）で確かめられます。検証するリゾルバなら SERVFAIL になり、ブラウザではページが開けません。開けてしまう場合は、DoH が無効になっているか、検証しないリゾルバを使っています。

自前の DoH リゾルバで併用する

社内や自宅で、DNSSEC を検証するリゾルバを DoH で提供したい場合は、Unbound が候補になります。比較的新しい Unbound は、HTTP/2 ライブラリ（libnghttp2）付きでビルドされていれば DoH で応答できます。ディストリビューションのパッケージがこの機能付きかどうかは、事前に確認してください。

server:
    interface: 0.0.0.0@443
    https-port: 443
    tls-service-key: "/etc/unbound/privkey.pem"
    tls-service-pem: "/etc/unbound/fullchain.pem"
    module-config: "validator iterator"
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    access-control: 192.0.2.0/24 allow
    access-control: 0.0.0.0/0 refuse

設定のポイントは次のとおりです。

証明書は端末から見たホスト名に対して発行されたものを使い、更新後に Unbound を再読み込みする処理を組み込みます。
access-control で利用できる範囲を絞り、誰でも使えるオープンリゾルバにしないようにします。
443 番を Web サーバーと共用する場合は、リバースプロキシで /dns-query だけを Unbound に渡す構成もあります。

設定を変えたら unbound-checkconf で構文を確かめ、前述の curl や dig で ad フラグを確認します。本番の名前解決を担うサーバーで試す前に、検証用のサーバーで動作を確かめてください。

つまずきやすい点

「DoH を使えば DNSSEC は不要」ではない: DoH はリゾルバまでの区間しか守らず、リゾルバが受け取った答えの真偽は DNSSEC でしか確かめられません。
「DNSSEC があれば DoH は不要」でもない: DNSSEC は暗号化しないため、どのサイトを調べたかは経路上から見えます。
時刻のずれ: 検証するリゾルバのサーバー時刻が大きくずれると、署名の有効期限の判定に失敗し、多くのドメインで SERVFAIL になります。NTP などで時刻を合わせておきます。

まとめ

DoH は端末とリゾルバの間の暗号化、DNSSEC は答えの真正性の検証で、守る範囲が異なる
併用には DNSSEC を検証する DoH リゾルバを選び、端末側（ブラウザ・OS）で DoH を有効にする
curl の JSON API の "AD": true や、dig +https の ad フラグで検証を確認する
自前で提供する場合は Unbound などで検証と DoH を両立し、アクセス範囲を絞る
自分のドメインを守るには、DoH とは別にドメイン側で DNSSEC を有効にする