0Pricing
Security+ Academy · レッスン

セキュアDNS:DNSSECとDNS over HTTPS(DoH)

DNSSECがDNSキャッシュポイズニングを防ぐ仕組みと、DNS over HTTPSおよびDNS over TLSがオンパスの監視者からクエリのプライバシーを守る仕組みを学びます。

「セキュアDNS:DNSSECとDNS over HTTPS(DoH)」はCoddyKit上の無料Security+ Academyレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはSecurity+ Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Security+ Academyコースには全4レッスンが含まれています。

DNSのセキュリティ上の課題

Domain Name System(DNS)は、人間が読みやすいドメイン名をIPアドレスに変換します。1980年代に設計されたDNSは、セキュリティを考慮せずに構築されました。クエリと応答はUDP/TCPの53番ポートを通じて平文で送信され、認証も行われません。このため、2つの大きな脆弱性が生じます。DNSキャッシュポイズニング(偽のDNS応答を注入し、ユーザーを悪意のあるサーバーへリダイレクトする攻撃)と、DNS盗聴(ユーザーがクエリしたドメインを観察することで、閲覧行動が明らかになること)です。これらには、DNSSECが偽造を防止し、DNS over HTTPS(DoH)が盗聴を防止するという2つの標準が対処します。

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

DNSキャッシュポイズニング(Kaminsky攻撃)は、DNSプロトコルに認証がないことを悪用します。リゾルバーは権威DNSサーバーにクエリを送信し、TTLの期間だけ応答をキャッシュします。攻撃者は、トランザクションID(16ビットで予測可能)と送信元ポート(RFC 5452以降、追加のエントロピーとして使用)を推測できれば、偽の応答を送信してリゾルバーにキャッシュさせることができます。その結果、そのリゾルバーにクエリするすべてのユーザーが攻撃者のサーバーへリダイレクトされます。いったんキャッシュが汚染されると、ユーザーが正しいドメインを入力しても偽のサーバーへ誘導されます。DNSSECはDNS応答にデジタル署名を付けることで、これを防止します。

# DNS cache poisoning simulation
# Attacker floods resolver with forged responses
# for the query 'A example.com?'

# Each response guesses a different transaction ID:
# ID=1234: example.com -> 198.51.100.1  (attacker IP)
# ID=1235: example.com -> 198.51.100.1
# ...
# ID=XXXX: example.com -> 198.51.100.1  (correct guess!)

# Resolver caches poisoned answer (TTL = 3600s)
# All users querying this resolver get attacker IP
# Users are redirected to phishing/malware server

DNSSEC:DNS Security Extensions

DNSSECはDNSレコードに暗号学的署名を追加し、リゾルバーが応答の送信元が正規のゾーン管理者であり、改ざんされていないことを検証できるようにします。DNSSECでは、RRSIG(リソースレコード署名。レコードセットに対する実際の署名)、DNSKEY(署名の検証に使用する公開鍵)、DS(Delegation Signer。親ゾーンと子ゾーンの鍵を関連付けるレコード)、NSEC/NSEC3(認証付き不存在証明。名前が存在しないことを証明)という新しいレコードタイプが導入されます。DNSSECは、ICANNによって署名されたルートゾーンからTLD、権威ゾーンへと続く信頼の連鎖を構築します。

# Verify DNSSEC signature on a domain
dig +dnssec example.com A
# Look for 'ad' (authenticated data) flag in response
# and the RRSIG record alongside the A record

# Query for DNSKEY record
dig DNSKEY example.com

# Query for DS record at parent zone
dig DS example.com @a.iana-servers.net

# Full DNSSEC chain validation check
dig +sigchase +trusted-key=/.../root.key example.com A

DNSSECの鍵タイプ:KSKとZSK

DNSSECでは、2種類の署名鍵を使用します。Zone Signing Key(ZSK)は個々のDNSレコードセット(RRSIG)に署名し、運用上の柔軟性を保つため頻繁に(毎月または四半期ごとに)ローテーションします。Key Signing Key(KSK)はDNSKEYレコードセットに署名し、ゾーンの信頼の起点を提供します。KSKを変更するたびに親ゾーンを新しいDSレコードで更新する必要があり、調整が必要となるため、KSKのローテーション頻度は低く(通常は年1回)します。KSKはZSKを検証し、ZSKはデータに署名します。この2層構造により、頻繁なZSKローテーションによるセキュリティと、KSKローテーションの頻度を抑えることによる運用負担の軽減を両立しています。

DNSSECの制限

DNSSECには重要な制限があります。DNSクエリは暗号化されません。DNSSECが行うのは応答への署名による完全性の確保だけです。そのため、盗聴者は偽の応答を作成できないものの、すべてのDNSクエリを確認できます。ゾーン列挙:不存在を証明するNSECレコードによって、攻撃者はゾーンをたどり、その中にあるすべてのドメイン名を列挙できます。NSEC3はハッシュ化した名前を使用してこの問題を軽減しますが、完全ではありません。運用の複雑さ:鍵管理、署名の有効期限、親ゾーンとの調整により、大きな運用負担が生じます。DNSSECの導入も依然として不完全です。多くのTLDやレジストラがサポートしていますが、導入していない組織も多数あります。

DNS over HTTPS(DoH)

DNS over HTTPS (DoH)は、HTTPS(RFC 8484)内でDNSクエリを暗号化し、ネットワーク上の監視者からクエリの内容を隠します。クエリは標準HTTPS URLでDoH対応リゾルバーに送信されるため、DNSトラフィックを他のHTTPSトラフィックと区別できないようにします。これにより、ISP、雇用主、経路上の攻撃者がユーザーの問い合わせ先ドメインを確認できなくなり、DNSSECに残るプライバシー上の問題に対処できます。ただし、DoHによって信頼の対象はネットワークのDNSリゾルバーからDoHプロバイダー(通常はGoogle 8.8.8.8、Cloudflare 1.1.1.1、または組織独自のDoHリゾルバー)へ移ります。現在では、ほとんどの主要ブラウザーがDoHを標準でサポートしています。

# DoH query using curl
curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

# DoH query via RFC 8484 (binary format)
curl -s -H 'Content-Type: application/dns-message' \
     -H 'Accept: application/dns-message' \
     --data-binary @query.bin \
     https://dns.google/dns-query

# Configure Firefox to use DoH
# about:config -> network.trr.uri
# Set to: https://mozilla.cloudflare-dns.com/dns-query

DNS over TLS(DoT)

DNS over TLS (DoT)(RFC 7858)は、HTTPSを介してトンネリングするのではなく、専用のTCPポート853上でTLSを使用してDNSクエリを暗号化します。DoTは、盗聴者からクエリの内容を隠すというDoHと同じプライバシー上の利点を提供しますが、ネットワーク管理者が識別してフィルタリングしやすいという違いがあります(ポート853とポート443の違い)。これは一長一短です。DoTは可視性が高く、企業ファイアウォールでブロックできますが、DoHは通常のHTTPSトラフィックにも影響を与えずにブロックすることが困難です。スタブリゾルバー(OSレベル)ではDoTが、ブラウザーではDoHがより一般的に使用されます。

# Test DoT connection using kdig
kdig -d @9.9.9.9 +tls-ca example.com A

# Test DoT using openssl
openssl s_client -connect 1.1.1.1:853
# Then type: query string in DNS wire format

# Configure systemd-resolved to use DoT (Linux)
# /etc/systemd/resolved.conf:
[Resolve]
DNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes

DoHとDoT:エンタープライズ環境での考慮事項

暗号化DNSは、DNSベースのフィルタリングやシンクホールに依存するエンタープライズ環境に課題をもたらします。ブラウザーが外部のDoHリゾルバーを使用すると、内部DNSの制御が回避されます。エンタープライズ環境での対策には、内部DoH/DoTリゾルバーを導入する(Cisco Umbrella、DoH対応のPi-holeなど)とともに、すべてのデバイスがそれを使用するように構成すること、ファイアウォールでポート443上の外部DoHリゾルバーのIPアドレスをブロックすること(Google 8.8.8.8、Cloudflare 1.1.1.1)、管理対象エンドポイントでブラウザーレベルのDoHを無効にするGroup Policy、ポート853上のDNS over TLSを傍受する透過プロキシルールなどがあります。目標は、暗号化DNSを完全にブロックすることなく、すべてのDNSを管理下のリゾルバー経由でルーティングすることです。

# Enterprise DoH bypass prevention
# Windows Group Policy:
# Computer Config > Admin Templates > Google Chrome
# 'DNS over HTTPS mode': Disabled
# 'DNS over HTTPS URI templates': <empty>

# Firewall: block known public DoH resolvers
iptables -I FORWARD -d 8.8.8.8 -p tcp --dport 443 -j DROP
iptables -I FORWARD -d 1.1.1.1 -p tcp --dport 443 -j DROP
iptables -I FORWARD -d 9.9.9.9 -p tcp --dport 443 -j DROP
iptables -I FORWARD -d 149.112.112.112 -p tcp --dport 443 -j DROP

# Redirect all DNS to corporate resolver
iptables -t nat -A PREROUTING -p udp --dport 53 \
  -j DNAT --to-destination 10.0.0.53:53

実践におけるDNSセキュリティ

完全なDNSセキュリティ戦略では、複数の制御を組み合わせます。DNSSECは、権威ゾーンに対してKSK/ZSKキーペアを使用した暗号署名を付加し、ドメインのキャッシュポイズニングを防ぎます。DNSベースのフィルタリング(Cisco Umbrella、Cloudflare Gateway)は、リゾルバーレベルで悪意のあるドメインをブロックします。管理下のリゾルバーへのDoH/DoTは、フィルタリングの可視性を失うことなくクエリのプライバシーを確保します。DNSロギングをSIEMに送信すると、脅威ハンティングのためにすべてのクエリを収集できます。DNSログからは、C2トラフィック、DNSトンネリングによるデータ窃取、マルウェアによるドメイン生成アルゴリズム(DGA)の活動を明らかにできます。DNSテレメトリは、利用可能なセキュリティデータソースの中でも特に価値の高いものの一つです。

DNSトンネリングの検出

DNSトンネリングは、DNSクエリとレスポンスにデータを埋め込み、データを窃取したり、他の送信トラフィックがブロックされているネットワークを介してC2チャネルを確立したりする手法です。iodine、DNScat、dnscat2などのツールは、サブドメインラベル(EXFILTRATEDDATA.evil.comへの問い合わせ)やTXTレコードにペイロードを埋め込みます。検出の手がかりには、異常に長いDNSクエリ名(100文字超)、単一ホストからの大量のクエリ、存在しない親ドメインへのクエリ、通常とは異なるレコードタイプ(TXT、NULL)、ドメインラベルのエントロピー分析(エンコードされたデータはシャノンエントロピーが高くなります)があります。DNSセキュリティ分析プラットフォームは、トンネリングのパターンを自動的に検出します。

# DNS tunneling detection indicators
# Flag queries with:
# 1. Query name > 100 characters
# 2. More than 50 queries/minute from single host
# 3. High-entropy domain labels (base64/hex patterns)
# 4. TXT or NULL record type queries (unusual)
# 5. Queries to domains with no web presence

# Example tunnel query (encoded payload)
# aGVsbG8gd29ybGQ.vGhpcyBpcyBkYXRh.evil-domain.com
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# Base64 encoded 'hello world this is data'

DNS Response Policy Zones(RPZ)

DNS Response Policy Zones (RPZ)を使用すると、DNSリゾルバーはDNSレスポンスにローカルな上書きポリシーを適用できます。これは、グローバルなDNSインフラストラクチャを変更せずに、リゾルバーレベルでローカルなシンクホールを作成する仕組みです。クライアントが既知の悪意のあるドメインを問い合わせると、RPZポリシーはNXDOMAIN、シンクホールIPアドレスへのリダイレクト、またはパススルーレスポンスを返します。RPZフィードは脅威インテリジェンスプロバイダー(Spamhaus、SURBL)から提供されており、BINDやUnboundのリゾルバーに直接インポートできます。RPZは、クライアント側の設定を必要とせず、ネットワーク上のすべてのデバイスに対してDNSレイヤーでフィルタリングを適用できる強力な防御ツールです。

# BIND RPZ configuration snippet
# /etc/named.conf
response-policy {
  zone 'rpz.spamhaus.net';
  zone 'local-blocklist.internal';
};

# RPZ zone file (local-blocklist.internal)
$ORIGIN local-blocklist.internal.
@  SOA  ns1.company.com. admin.company.com. 2024010101 3600 600 86400 300
botnet-c2.evil IN CNAME .   # NXDOMAIN response
phishing-site.com IN A 10.0.0.99  # Redirect to sinkhole

クイックチェック

このレッスンで扱ったCompTIA Security+(SY0-701)の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、DNSSECがKSK/ZSKキーペアを使用してDNSレコードに暗号署名を付加し、キャッシュポイズニングを防ぐ一方でクエリを暗号化しないこと、DNS over HTTPS (DoH)がHTTPS内でDNSクエリを暗号化して盗聴を防ぐ一方で、エンタープライズ環境でのフィルタリング回避リスクを生じさせること、そしてDNSトンネリングがDNSクエリにデータを埋め込む手法であり、クエリの長さ、量、エントロピーの分析によって検出できることを学びました。次は、IPsec、VPNプロトコル、リモートアクセスセキュリティについて学びます。

よくある質問

「セキュアDNS:DNSSECとDNS over HTTPS(DoH)」レッスンは無料ですか?

はい。「セキュアDNS:DNSSECとDNS over HTTPS(DoH)」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Security+ Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Security+ Academyコースには全4レッスンが含まれています。

「セキュアDNS:DNSSECとDNS over HTTPS(DoH)」で何を学びますか?

DNSSECがDNSキャッシュポイズニングを防ぐ仕組みと、DNS over HTTPSおよびDNS over TLSがオンパスの監視者からクエリのプライバシーを守る仕組みを学びます。 ブラウザで直接実行するハンズオンコードでSecurity+ Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Security+ Academyを始めるのに経験は必要ですか?

事前経験は必要ありません。CoddyKitのSecurity+ Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。

「セキュアDNS:DNSSECとDNS over HTTPS(DoH)」レッスンにはどのくらい時間がかかりますか?

ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このSecurity+ Academyレッスンでコードを書いて実行できますか?

はい。すべてのSecurity+ Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. 安全でないプロトコルの置き換え:Telnet対SSH、FTP対SFTP
  2. TLSバージョン、暗号スイート、完全前方秘匿性
  3. セキュアDNS:DNSSECとDNS over HTTPS(DoH)
  4. IPsec、VPNプロトコル、リモートアクセスセキュリティ
← Security+ Academyに戻る