4.5. DNSSEC を使用した DNS トラフィックのセキュア化

DNSSEC は、DNSSEC( Domain Name System Security Extensions )のセットで、DNS クライアントが DNS ネームサーバーからの応答の整合性を認証およびチェックし、発信元を検証し、転送中に改ざんされているかどうかを判断できるようにします。

インターネット経由で接続するために、Web サイトの数が増え、HTTPS を使用して安全に接続する機能が提供されるようになりました。ただし、HTTPS Web サーバーに接続する前に、IP アドレスを直接入力しない限り、DNS ルックアップを実行する必要があります。これらの DNS ルックアップは安全 ではなく、認証がないため、中間者 攻撃の対象となります。つまり、DNS クライアントは、特定の DNS ネームサーバーから送られるように見える応答が本物であり、改ざんされていないことを確信できません。さらに重要なことに、再帰的ネームサーバーは、他のネームサーバーから取得したレコードが本物であることを確認できません。DNS プロトコルは、クライアントが中間者攻撃を受けないようにするためのメカニズムを提供していませんでした。DNSSEC は、DNS を使用してドメイン名を解決する際に認証および整合性チェックの欠如に対処するために導入されました。DNSSEC は、機密性の問題には対処しません。

DNSSEC 情報の公開には、DNS リソースレコードのデジタル署名や、DNS リゾルバーが信頼の階層チェーンを構築できるようにするなどの方法で公開鍵を配布することが含まれます。すべての DNS リソースレコードのデジタル署名が生成され、デジタル署名リソースレコード(RRSIG)としてゾーンに追加されます。ゾーンの公開鍵は、DNSKEY リソースレコードとして追加されます。階層的な連鎖を構築するために、DNSKEY のハッシュをDS(Delegation of Signing) リソースレコードとして親ゾーンで公開します。消極的事実の証明を容易にするために、NextSECure (NSEC) および NSEC3 リソースレコードが使用されます。DNSSEC 署名付きゾーンでは、各 リソースレコードセット (RRset) には対応する RRSIG リソースレコードがあります。子ゾーンへの委任に使用されるレコード (NS レコードおよび glue レコード) は署名されないことに注意してください。これらのレコードは子ゾーンに表示され、そこに署名されています。

DNSSEC 情報の処理は、root ゾーン公開鍵が設定されたリゾルバーによって実行されます。この鍵を使用して、リゾルバーは root ゾーンで使用される署名を検証できます。たとえば、ルートゾーンは .com の DS レコードに署名しています。ルートゾーンは、.com ネームサーバーの NS レコードおよび glue レコードも提供します。リゾルバーはこの委譲に従い、これらの委譲されたネームサーバーを使用して .com の DNSKEY レコードをクエリーします。取得した DNSKEY レコードのハッシュは、root ゾーンの DS レコードと一致する必要があります。その場合、リゾルバーは .com の取得した DNSKEY を信頼します。 .com ゾーンでは、RRSIG レコードは .com DNSKEY によって作成されます。このプロセスは、redhat.com など、.com 内の委譲についても同様に繰り返されます。この方法を使用すると、検証用 DNS リゾルバーは、通常の操作中に世界中から多くの DNSKEY を収集する間、1 つのルートキーでのみ設定する必要があります。暗号チェックに失敗した場合、リゾルバーはアプリケーションに SERVFAIL を返します。

DNSSEC は、DNSSEC をサポートしていないアプリケーションからは完全に見えないように設計されています。DNSSEC 非対応のアプリケーションが DNSSEC 対応リゾルバーにクエリーした場合、RRSIG などのこれらの新しいリソースレコードタイプがなくても応答を受け取ります。ただし、DNSSEC 対応のリゾルバーは引き続きすべての暗号化チェックを実行し、悪意のある DNS 応答を検出すると、アプリケーションに引き続き SERVFAIL エラーを返します。DNSSEC は、DNS サーバー（権威および再帰的）間のデータの整合性を保護します。これは、アプリケーションとリゾルバー間のセキュリティーを提供しません。したがって、アプリケーションにリゾルバーへの安全なトランスポートを提供することが重要です。これを実現する最も簡単な方法は、DNSSEC 対応のリゾルバーを localhost で実行し、/etc/resolv.conf で 127.0.0.1 を使用することです。または、リモート DNS サーバーへの VPN 接続を使用することもできます。

Wi-Fi Hotspots または VPN は、Wi-Fi サービスの認証（または支払い）が必要なページにユーザーをリダイレクトするために、DNS を乗っ取る傾向があります。「」VPN に接続するユーザーは、企業ネットワーク外に存在しないリソースを見つけるために、「内部のみ」 の DNS サーバーを使用することがよくあります。これには、ソフトウェアによる追加の処理が必要です。たとえば、dnssec-trigger を使用して、ホットスポットが DNS クエリーを乗っ取っているかどうかを検出でき、unbound は DNSSEC クエリーを処理するプロキシーネームサーバーとして機能できます。

DNSSEC 対応の再帰リゾルバーをデプロイするには、BIND または unbound のいずれかを使用できます。いずれもデフォルトで DNSSEC を有効にし、DNSSEC root キーで設定されています。サーバーで DNSSEC を有効にするには、どちらのサーバーも機能しますが、ノートブックなどのモバイルデバイスでは、ローカルユーザーが動的に DNSSEC オーバーライドを再設定できるため、dnssec-trigger を使用する際にローカルユーザーが Hotspot に必要な DNSSEC オーバーライドを動的に再設定し、Libreswan を使用する場合は VPN 向けに を使用することが推奨されます。unbound デーモンは、サーバーとモバイルデバイスの両方で役立つ etc/unbound/*.d/ ディレクトリーにリストされている DNSSEC 例外のデプロイメントをさらにサポートします。

unbound が /etc/resolv.conf にインストールされ、設定されると、アプリケーションからの DNS クエリーはすべて unbound によって処理されます。dnssec-trigger は、トリガーされた場合にのみ unbound リゾルバーを再設定します。これは、ノートパソコンなど、異なる Wi-Fi ネットワークに接続するローミングクライアントマシンに主に適用されます。プロセスは以下のようになります。

Wi-Fi ホットスポットは、インターネットへのアクセスを許可する前に、ユーザーをサインオンページにリダイレクトすることが多くなっています。上記のプロービングシーケンス中にリダイレクトが検出された場合、インターネットにアクセスするためにログインが必要かどうかを尋ねるプロンプトがユーザーに表示されます。dnssec-trigger デーモンは、10 秒ごとに DNSSEC リゾルバーのプローブを続行します。dnssec-trigger グラフィカルユーティリティーの使用方法は、「Dnssec-trigger の使用」 を参照してください。

VPN 接続のタイプによっては、VPN トンネル設定の一環として、ドメインとそのドメインに使用するネームサーバーのリストを伝達できます。Red Hat Enterprise Linux では、これは NetworkManager でサポートされています。つまり、unbound なdnssec-trigger と NetworkManager の組み合わせは、VPN ソフトウェアが提供するドメインおよびネームサーバーを適切にサポートできます。VPN トンネルが起動すると、受信したドメイン名のすべてのエントリーに対してローカルの unbound キャッシュがフラッシュされるため、ドメイン名内の名前に対するクエリーは VPN を使用して到達した内部ネームサーバーから新たにフェッチされます。VPN トンネルが終了すると、バインド されていないキャッシュが再度フラッシュされ、ドメインに対するクエリーが以前に取得したプライベート IP アドレスではなくパブリック IP アドレスを返すようにします。「接続が提供されるドメインの DNSSEC 検証の設定」を参照してください。

Red Hat は、static および transient の両方の 名前が host.example.com などの DNS 内のマシンに使用される完全修飾ドメイン 名(FQDN)と一致することを推奨します。

Internet Corporation for Assigned Names and Numbers (ICANN)は、以前に登録解除されたトップレベルドメイン( .yourcompanyなど)をパブリックレジスターに追加することがあります。このため、Red Hat では、プライベートネットワーク上であっても委任されていないドメイン名を使用しないことを強く推奨しています。その結果、ネットワークリソースは利用できなくなります。また、委任されていないドメイン名を使うと、DNSSEC の実装および維持がより困難になります。これは、ドメイン名の競合が DNSSEC 検証の有効化に手動の設定ペナルティーを必要とするためです。この問題の詳細は、ドメイン名の衝突に関する ICANN のよくある質問を参照してください。

階層暗号化システムでは、トラストアンカーは信頼できると想定される、信頼できるエンティティーです。たとえば、X.509 アーキテクチャーでは、ルート証明書がトラストチェーンの元となるトラストアンカーとなっています。トラストアンカーは、パスの検証ができるように、事前に信頼できる団体が所有しておく必要があります。

DNSSEC のコンテキストでは、トラストアンカーは、その名前に関連付けられた DNS 名と公開鍵（または公開鍵のハッシュ）で設定されます。これは、base 64 でエンコードされたキーとして表されます。DNS レコードの検証および認証に使用できる公開鍵を含む情報を交換する手段である点で、証明書と似ています。RFC 4033 は、トラストアンカーを設定された DNSKEY RR または DNSKEY RR の DS RR ハッシュと定義しています。検証用セキュリティー対応リゾルバーは、この公開鍵またはハッシュを、署名された DNS 応答への認証チェーンを構築するための開始点として使用します。一般に、検証用リゾルバーは、DNS プロトコルの外部にある安全な手段または信頼できる手段を介してトラストアンカーの初期値を取得する必要があります。トラストアンカーの存在はまた、リゾルバーがトラストアンカーが指すゾーンが署名されていることを想定すべきことを意味します。

dnssec-trigger アプリケーションには、DNSSEC プローブ結果を表示し、DNSSEC プローブ要求をオンデマンドで実行するための GNOME パネルユーティリティーがあります。ユーティリティーを起動するには、Super キーを押してアクティビティーの概要に入り、DNSSEC と 入力 して Enter を押します。画面下のメッセージトレイに、船の錨に似たアイコンが追加されます。画面の右下にある青い丸い通知アイコンを押して表示します。錨アイコンを右クリックすると、ポップアップメニューが表示されます。

通常の操作では、unbound はローカルでネームサーバーとして使用され、resolv.conf は 127.0.0.1 を指します。Hotspot Sign-On パネルで OK をクリックすると、これが変更されます。DNS サーバーは NetworkManager からクエリーされ、resolv.conf に配置されます。これで、Hotspot のサインオンページで認証ができるようになりました。アンカーアイコンには、DNS クエリーが安全ではないことを警告するために、大きな赤い感嘆符が表示されます。認証されると、dnssec-trigger は自動的にこれを検出し、セキュアモードに戻す必要がありますが、場合によってはユーザーではなく、ユーザーは Reprobe を選択して手動でこれを行う必要があります。

dnssec-trigger は通常、ユーザーの対話を必要としません。一度起動するとバックグラウンドで動作し、問題が発生した場合は、ポップアップのテキストボックスでユーザーに通知します。また、resolv.conf ファイルへの変更について unbound に通知します。

DNSSEC が機能しているかどうかを確認するために、さまざまなコマンドラインツールを使用することができます。最適なツールは、bind-utils パッケージの dig コマンドです。ldns パッケージからの drill と unbound パッケージの unbound-host に役立つその他のツール。古い DNS ユーティリティー nslookup および host は廃止されているため、使用しないでください。

dig を使用して DNSSEC データを要求するクエリーを送信するには、オプション +dnssec がコマンドに追加されます。以下に例を示します。

~]$ dig +dnssec whitehouse.gov
; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-4.P2.el7 <<>> +dnssec whitehouse.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21388
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;whitehouse.gov.			IN	A

;; ANSWER SECTION:
whitehouse.gov.		20	IN	A	72.246.36.110
whitehouse.gov.		20	IN	RRSIG	A 7 2 20 20130825124016 20130822114016 8399 whitehouse.gov. BB8VHWEkIaKpaLprt3hq1GkjDROvkmjYTBxiGhuki/BJn3PoIGyrftxR HH0377I0Lsybj/uZv5hL4UwWd/lw6Gn8GPikqhztAkgMxddMQ2IARP6p wbMOKbSUuV6NGUT1WWwpbi+LelFMqQcAq3Se66iyH0Jem7HtgPEUE1Zc 3oI=

;; Query time: 227 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:01:52 EDT 2013
;; MSG SIZE  rcvd: 233

A レコードに加えて、DNSSEC 署名、および署名の開始時刻と有効期限を含む RRSIG レコードが返されます。unbound サーバーは、上部の flags: セクションの ad ビットを返して、データが DNSSEC 認証されていることを示しています。

DNSSEC の検証に失敗すると、dig コマンドは SERVFAIL エラーを返します。

~]$ dig badsign-a.test.dnssec-tools.org
; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.el7 <<>> badsign-a.test.dnssec-tools.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1010
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;badsign-a.test.dnssec-tools.org. IN	A

;; Query time: 1284 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:04:52 EDT 2013
;; MSG SIZE  rcvd: 60]

障害に関する詳細情報を要求するには、dig コマンドに +cd オプションを指定して DNSSEC チェックを無効にすることができます。

~]$ dig +cd +dnssec badsign-a.test.dnssec-tools.org
; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.el7 <<>> +cd +dnssec badsign-a.test.dnssec-tools.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26065
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;badsign-a.test.dnssec-tools.org. IN	A

;; ANSWER SECTION:
badsign-a.test.dnssec-tools.org. 49 IN	A	75.119.216.33
badsign-a.test.dnssec-tools.org. 49 IN	RRSIG	A 5 4 86400 20130919183720 20130820173720 19442 test.dnssec-tools.org. E572dLKMvYB4cgTRyAHIKKEvdOP7tockQb7hXFNZKVbfXbZJOIDREJrr zCgAfJ2hykfY0yJHAlnuQvM0s6xOnNBSvc2xLIybJdfTaN6kSR0YFdYZ n2NpPctn2kUBn5UR1BJRin3Gqy20LZlZx2KD7cZBtieMsU/IunyhCSc0 kYw=

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 22:06:31 EDT 2013
;; MSG SIZE  rcvd: 257

多くの場合、DNSSEC の間違いは、開始時間や有効期限が不適切であることから明らかになりますが、この例では、www.dnssec-tools.org の人々がこの RRSIG 署名を故意に理解不能にしており、この出力を手動で確認しても検出することはできません。このエラーは systemctl status unbound の出力に表示され、unbound デーモンはこれらのエラーを以下のように syslog に記録します。

Aug 22 22:04:52 laptop unbound: [3065:0] info: validation failure badsign-a.test.dnssec-tools.org. A IN

unbound-host を使用する例：

~]$ unbound-host -C /etc/unbound/unbound.conf -v whitehouse.gov
whitehouse.gov has address 184.25.196.110 (secure)
whitehouse.gov has IPv6 address 2600:1417:11:2:8800::fc4 (secure)
whitehouse.gov has IPv6 address 2600:1417:11:2:8000::fc4 (secure)
whitehouse.gov mail is handled by 105 mail1.eop.gov. (secure)
whitehouse.gov mail is handled by 110 mail5.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail4.eop.gov. (secure)
whitehouse.gov mail is handled by 110 mail6.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail2.eop.gov. (secure)
whitehouse.gov mail is handled by 105 mail3.eop.gov. (secure)

ネットワークに接続すると、dnssec-trigger は Hotspot を検出しようとします。Hotspot は通常、ユーザーがネットワークリソースを使用する前に、Web ページとのユーザーインタラクションを強制するデバイスです。検出は、既知のコンテンツを含む特定の固定 Web ページのダウンロードを試みることによって行われます。Hotspot がある場合、受信したコンテンツは想定どおりではありません。

dnssec-trigger が Hotspot を検出するために使用できる既知のコンテンツを含む固定 Web ページを設定するには、次の手順に従います。

設定オプションの詳細は、man ページの dnssec-trigger.conf (8)を参照してください。

デフォルトでは、適切なネームサーバーを持つ正引きゾーンは、NetworkManager を介した Wi-Fi 接続を除き、すべての接続で dnssec-trigger によって unbound に自動的に追加されます。デフォルトでは、unbound に追加されたすべての転送ゾーンは DNSSEC 検証済みです。

転送ゾーンの検証に関するデフォルトの動作は、デフォルトではすべての転送ゾーンが DNSSEC で 検証されない ように、変更することができます。これを行うには、dnssec-trigger 設定ファイル /etc/dnssec.conf の validate_connection_provided_zones 変数を変更します。root ユーザーとして、以下のように行を開いて編集します：

validate_connection_provided_zones=no

この変更は、既存の正引きゾーンではなく、将来の正引きゾーンに対してのみ行われます。したがって、現在提供されているドメインの DNSSEC を無効にする場合は、再接続する必要があります。

add_wifi_provided_zones=yes

DNSSEC の詳細については、以下を参照してください。