DNSセキュリティ強化ガイド｜DoH・DoT・DNSSECで名前解決を保護する実践設定

社内のPCが突然、見覚えのないサイトに誘導される。ユーザーは正しいURLを入力しているのに、通信が知らない第三者に盗み見られている。そんな攻撃の多くが、DNSという「インターネットの電話帳」を狙ったものです。

DNSはドメイン名をIPアドレスに変換する仕組みで、あらゆるWeb通信の起点になります。ところがDNSの通信はデフォルトでは平文（暗号化なし）であり、改ざん・傍受・なりすましのリスクにさらされています。

この記事では、DNS通信を保護する3つの技術——DNS over HTTPS（DoH）、DNS over TLS（DoT）、DNSSEC——について、仕組みの解説から企業ネットワークへの実装手順まで、現場目線で解説します。社内のDNS通信を今日から守るための実践的なガイドとして活用してください。

DNSとは？なぜセキュリティ対策が必要なのか

DNS（Domain Name System）は、「www.example.com」のようなドメイン名を「203.0.113.1」のようなIPアドレスに変換するシステムです。私たちがURLをブラウザに入力するたびに、裏側でDNS問い合わせが発生しています。

問題は、従来のDNS通信がポート53番のUDPで平文のまま流れることです。これは1983年のプロトコル設計当時からほぼ変わっていません。暗号化がないため、同じネットワーク上の攻撃者や通信経路上のプロバイダ・悪意ある第三者が「どのサイトにアクセスしているか」を丸ごと把握できます。

インフラエンジニアの視点から言えば、「SSHは鍵認証で固めているのに、そのSSH接続先を調べるDNS問い合わせが平文で流れている」という皮肉な状況が生まれています。HTTPSでWebを暗号化しながら、どのサイトに接続しようとしているかはDNSで筒抜け——これが今のインターネットの現実です。

中小企業の情シスにとっても他人事ではありません。取引先との通信先ドメイン、社内で使っているSaaSの情報、さらには社員の業務外利用まで、DNSログには組織の行動パターンがそのまま記録されています。

DNS通信を狙った攻撃手法（敵を知る）

防御策を選ぶ前に、DNSを悪用した主な攻撃パターンを把握しておきましょう。

1. DNSキャッシュポイズニング

DNSリゾルバ（問い合わせを中継するサーバー）のキャッシュに偽の情報を書き込む攻撃です。利用者が正しいURLを入力しても、偽のIPアドレスに誘導されフィッシングサイトに接続させられます。2008年にセキュリティ研究者のDan Kaminsky氏が大規模な脆弱性として発表して以来、リゾルバのランダムポート対応などで対策が進みましたが、根本的な解決にはDNSSECによる署名検証が必要です。

2. DNSハイジャック

ルーターや端末のDNS設定そのものを書き換え、攻撃者が管理する偽DNSサーバーに問い合わせを向ける攻撃です。マルウェア感染やルーターへの不正アクセスによって発生します。攻撃者は名前解決の結果を自由に操作できるため、ほぼあらゆるサービスになりすますことが可能になります。社内ルーターのデフォルトパスワード未変更が原因となるケースが後を絶ちません。

3. DNS通信の傍受（盗聴）

暗号化されていないDNS問い合わせは、経路上のすべての機器で読み取れます。個人のプライバシー問題だけでなく、企業の場合は「どの取引先と通信しているか」「どのクラウドサービスを使っているか」が外部に漏れるリスクがあります。公衆Wi-FiやISPレベルでの傍受も技術的には容易です。

4. DNSトンネリング

マルウェアがDNS問い合わせを悪用してC2（コマンド＆コントロール）サーバーと通信する手法です。多くのファイアウォールがポート443や80を制限しても、ポート53のDNSは通過させることが多く、攻撃者に悪用されます。異常に多いDNS問い合わせや、不審な長いサブドメイン名が特徴です。

3つの防御技術——DoH・DoT・DNSSECの仕組み

DNS over HTTPS（DoH）

DoHは、DNS問い合わせをHTTPS（ポート443）のトラフィックに乗せて暗号化する技術です（RFC 8484で標準化）。

最大のメリットは、既存のHTTPS通信と区別がつかないため、ファイアウォールやプロキシをバイパスしやすい点です。また、ブラウザ単位で設定でき、OS全体の設定を変えずに利用できます。Firefox・Chrome・Edgeはいずれもブラウザ内でDoHを設定できます。

企業利用での注意点として、社内プロキシ経由で通信を管理している環境では、DoHによってDNS問い合わせが直接外部に出てしまうと、通信管理の抜け穴になりかねません。「全端末を社内DNSリゾルバ（DoH対応）に向ける」設計が企業では基本です。

DNS over TLS（DoT）

DoTは、DNS問い合わせをTLS（ポート853）で暗号化する技術です（RFC 7858で標準化）。

HTTPSとは別のポートを使うため「DNS通信かどうか」はネットワーク機器から識別できますが、中身は暗号化されています。企業ネットワークではポート853を明示的に許可する必要があります。Linuxのsystemd-resolvedやAndnroid（バージョン9以降）など、OSレベルでネイティブ対応しているケースが多く、サーバー・インフラ側での設定に向いています。

DNSSEC

DNSSECは通信の暗号化ではなく、DNSレコードのデジタル署名による「改ざん検証」技術です（RFC 4033～4035）。

権威DNSサーバーがレコードに署名し、利用者側のリゾルバがその署名を検証することで「応答が本物のゾーン管理者から来たか」を確認します。キャッシュポイズニング対策として有効ですが、設定が複雑なことと、署名鍵の定期ローテーション運用が必要な点に注意が必要です。

重要なのは、DoH・DoTとDNSSECは補完関係にあることです。DoH/DoTは「通信経路の暗号化」、DNSSECは「応答内容の正当性検証」——2つを組み合わせることで、より堅牢なDNSセキュリティが実現します。

企業ネットワークでのDNSセキュリティ設定実践

1. LinuxサーバーでのDoT設定（systemd-resolved）

まず現在のリゾルバ設定を確認します。

# 現在の設定確認
resolvectl status

# systemd-resolved の設定ファイルを編集
vi /etc/systemd/resolved.conf

設定ファイルに以下を記述します。

[Resolve]
# DoT対応パブリックDNS（Cloudflare）に変更
# 社内に独自リゾルバがある場合はそのIPを指定すること
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
FallbackDNS=1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google

# DNSSECの検証を有効化（auto = 利用可能なら有効）
DNSSEC=yes

# DNS over TLSを有効化（yes = 強制、opportunistic = 可能なら有効）
DNSOverTLS=yes

設定を反映してステータスを確認します。

# 設定を反映
systemctl restart systemd-resolved

# DoTとDNSSECの有効化を確認
resolvectl status | grep -E "DNS Server|DNSSEC|DNS over TLS"

# 名前解決の動作テスト
resolvectl query www.google.com

注意: 社内に独自DNSサーバーがある環境では、パブリックDNSではなく社内リゾルバのIPを指定してください。その場合は社内リゾルバ自体をDoT対応にする（後述のUnbound設定が有効）設計が必要です。

2. UnboundでプライベートDNSリゾルバを構築する

社内に独自のDNSリゾルバを置くことで、クエリログの記録・不審ドメインのブロック・DoTのトンネル経由でのアップストリーム問い合わせが可能になります。

# Unboundのインストール（RHEL/AlmaLinux系）
dnf install -y unbound

# 信頼アンカーファイルの初期化（DNSSEC用）
unbound-anchor -a /var/lib/unbound/root.key

/etc/unbound/unbound.conf の主要設定部分です。

server:
    # ローカルネットワークからの問い合わせのみ受け付ける
    interface: 0.0.0.0
    port: 53
    access-control: 192.168.0.0/16 allow
    access-control: 127.0.0.0/8 allow
    access-control: 0.0.0.0/0 refuse

    # DNSSECの検証アンカーファイル
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # クエリログを有効化（不審な問い合わせの監視用）
    log-queries: yes
    logfile: "/var/log/unbound/unbound.log"

# アップストリームをDoT経由でCloudflareに転送
forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com

# Unboundの起動と自動起動設定
systemctl enable --now unbound

# 動作確認
unbound-control status
dig @127.0.0.1 www.example.com +dnssec

3. ブラウザのDoH設定（Chrome・Firefox）

端末レベルでDoHを設定する場合の手順です。社内リゾルバがある場合はそのURLを指定します。

# Chromeのポリシー設定（Linuxの場合 /etc/opt/chrome/policies/managed/ に配置）
# managed_policy.json
{
  "DnsOverHttpsMode": "secure",
  "DnsOverHttpsTemplates": "https://1.1.1.1/dns-query"
}

# 社内UnboundサーバーがDoH対応の場合（例: 192.168.1.10）
{
  "DnsOverHttpsMode": "secure",
  "DnsOverHttpsTemplates": "https://192.168.1.10/dns-query"
}

中小企業でも今日からできること

設定作業に時間を割けない場合でも、リスクを大幅に下げられる対策があります。

・ルーターのDNSをCloudflare 1.1.1.1に変更する: DoH・DoT対応の無料パブリックDNSです。ルーター管理画面のDNS設定を1.1.1.1（プライマリ）、1.0.0.1（セカンダリ）に変えるだけでISP経由の盗聴リスクが軽減します。
・ルーターのファームウェアを最新に保つ: 古いルーターはDNSハイジャック攻撃の標的です。管理画面へのアクセスをローカルのみに制限し、デフォルトパスワードを必ず変更してください。
・社内DNSサーバーのクエリログを有効化する: Windows Server DNSやBINDでクエリログを取得し、社内端末が不審なドメインを問い合わせていないか週次で確認します。DNSトンネリングや感染端末の早期発見に有効です。
・重要サーバーだけでもDoTを設定する: 全端末の設定変更は難しくても、DBサーバーやファイルサーバーなど重要なLinuxサーバーへのsystemd-resolved DoT設定は比較的容易に実装できます。
・外部DNSサービスの保護機能を活用する: Cloudflare Gateway（無料プランあり）やGoogle Cloud DNS等には、フィッシングサイト・マルウェアドメインの自動ブロック機能が備わっています。

よくある誤解と注意点

【誤解1】「DoHを使えば完全に安全」

DoHはDNS通信の傍受は防げますが、DNSSECなしでは応答の改ざんは検知できません。また、DoHはエンドポイントのDNS通信を暗号化しますが、その後のTCP接続先（IPアドレス）はネットワーク機器に見えています。完全な匿名性を保証するものではないことを理解した上で導入してください。

【誤解2】「DNSSEC対応ドメインなら安心」

DNSSECはゾーン管理者が署名を適切に維持していなければ意味がありません。署名の有効期限切れや鍵ローテーションのミスで、DNSSEC検証が有効なリゾルバがDNSエラーを返す事故が実際に起きています。自社ドメインにDNSSECを導入する場合は、署名更新の自動化と定期的な動作監視が必須です。

【誤解3】「社内でDoHを許可すると管理できなくなる」

エンドユーザーのブラウザがDoHを自動的に有効化し、社内プロキシをバイパスするケースが増えています。Firefoxは特定の条件下でCanary Domain（use-application-dns.net）が解決できない場合は自動でDoHをオフにする仕組みがあります。社内DNSにこのCanary Domainの解決をブロックするか、グループポリシーでDoHのアップストリームを社内リゾルバに向ける設定が有効です。

【注意】DNSoverHTTPS強制とポート853遮断の副作用

外部への直接DoT通信（ポート853）を遮断することで、端末が社内リゾルバ経由での通信を強制できます。ただし、ポート853を遮断すると一部のIoT機器やモバイルデバイスが名前解決に失敗するケースがあるため、影響範囲を事前に確認してから実施してください。

本記事のまとめ

DNS通信のセキュリティは「暗号化」と「改ざん検証」の2軸で考えることが重要です。DoH・DoTで通信経路を守り、DNSSECで応答の正当性を検証する——この組み合わせが現時点での堅牢な設計です。

中小企業の場合、まずルーターのDNSをCloudflare 1.1.1.1に変え、重要なLinuxサーバーではsystemd-resolvedでDoTを有効化するところから始めましょう。「全部いちどに完璧に」ではなく、着手できる箇所から段階的に積み上げることが、現場では一番続く対策です。

LinuxサーバーのFirewallやネットワーク制御の詳細については、姉妹サイトLinuxMaster.JPの関連記事も参照してください。