4.6. DNSSEC を使った DNS トラフィックのセキュア化

4.6.1. DNSSEC の概要

DNSSEC は、Domain Name System Security Extensions (DNSSEC : ドメイン名システムセキュリティー拡張機能) のセットです。DNS クライアントが DNS ネームサーバーからの応答の整合性を認証、検査して、応答元を検証し、転送中に不正に変更されなかったかどうかを判別できるようにします。

4.6.2. DNSSEC について

今日では、インターネット接続で多くのウェブサイトが HTTPS を使った安全な接続機能を提供しています。しかし、IP アドレスを直接入力していなければ、HTTPS ウェブサーバーに接続する前に DNS ルックアップが実行される必要があります。この DNS ルックアップは安全に実行されず、認証がないことから 中間者攻撃の対象となります。つまり、ある DNS ネームサーバーから送信されたようにみえる応答が本物で、不正に変更されていないことに DNS クライアントは確信を持てません。さらに重要なのは、再帰問い合わせネームサーバーは、他のネームサーバーから得られる記録が本物かどうかを判断できません。DNS プロトコルは、クライアントが中間者攻撃の対象とならないようなメカニズムを提供していませんでした。DNSSEC は、DNS を使用したドメインネームを解決する際の認証および完全性のチェックの欠如に対処するために導入されました。DNSSEC は、機密性の問題には対処しません。
DNSSEC 情報の公開では、DNS リソース記録のデジタル署名と、DNS リゾルバーが信頼の階層チェーンを構築できる方法での公開鍵の配布が行われます。すべての DNS リソースレコードのデジタル署名は、デジタル署名のリソース記録 (RRSIG) として生成され、ゾーンに追加されます。ゾーンの公開鍵は、DNSKEY リソースレコードとして追加されます。階層チェーンを構築するために、DNSKEY のハッシュが Delegation of Signing (DS) リソースレコードとして親ゾーンに公開されます。存在しない証拠を活用するため、NextSECure (NSEC) および NSEC3 リソースレコードが使用されます。DNSSEC 署名ゾーンでは、各 リソースレコードセット (RRset) に対応する RRSIG リソースレコードがあります。子ゾーンへの委任用に使用されるレコード (NS および glue レコード) には署名されないことに注意してください。それらのレコードは子ゾーンに表示され、そこで署名されます。
DNSSEC 情報の処理は、root ゾーンの公開鍵で設定されたリゾルバーが行います。この鍵を使ってリゾルバーは root ゾーンで使用された署名を検証することができます。たとえば、root ゾーンが .com の DS レコードを署名しているとします。root ゾーンは .com ネームサーバーの NS および glue レコードも処理します。リゾルバーはこの委任を追いかけ、これらの委任されたネームサーバーを使用して .com の DNSKEY レコードを問い合わせます。獲得された DNSKEY レコードのハッシュは、root ゾーンの DS レコードとマッチするはずです。マッチする場合、リゾルバーは獲得された .com の DNSKEY を信頼します。.com ゾーンでは、RRSIG レコードは .com DNSKEY が作成します。このプロセスは、redhat.com などの .com 内の委任で同様に繰り返されます。この方法を使用することで、検証を行う DNS リゾルバーは 1 つの root 鍵での設定のみが必要で、多くの DNSKEY を通常の操作中に世界中から収集します。暗号検査が失敗すると、リゾルバーはアプリケーションに SERVFAIL を返します。
DNSSEC は、DNSSEC をサポートしていないアプリケーションには全く見えないように設計されています。DNSSEC 非対応のアプリケーションが DNSSEC 対応リゾルバーを問い合わせると、RRSIG のような新たなリソースレコードタイプのない応答を受け取ります。ただし、DNSSEC 対応リゾルバーはすべての暗号検査を実行し、悪意のある DNS 応答を検出するとアプリケーションに SERVFAIL エラーを返します。DNSSEC は、DNS サーバー間 (権威と再帰) でデータの整合性を保護しますが、アプリケーションとリゾルバー間のセキュリティーは提供しません。このため、アプリケーションにリゾルバーへの安全なトランスポートが提供されることが重要になります。一番簡単な方法は、DNSSEC 対応リゾルバーを localhost 上で稼働して /etc/resolv.conf 内の 127.0.0.1 を使用することです。代わりに、リモートの DNS サーバーに VPN 接続することもできます。

ホットスポットの問題について

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

DNSSEC 対応のリカーシブリゾルバー

DNSSEC 対応のリカーシブリゾルバーを実装するには、BIND または unbound を使用することができます。両方ともデフォルトで DNSSEC を有効にし、DNSSEC root キーで設定されています。サーバー上で DNSSEC を有効にするにはどちらでも可能ですが、ノートパソコンなどのモバイルデバイスでは、unbound が推奨されます。これは、dnssec-trigger 使用時にはホットスポット、Libreswan 使用時には VPN に必要となる DNSSEC 上書きの再構成をローカルユーザーが動的に行えるようになるためです。unbound デーモンはさらに、etc/unbound/*.d/ ディレクトリーにリスト化されている DNSSEC 例外の実装もサポートします。これは、サーバーとモバイルデバイスの両方で役立ちます。

4.6.3. Dnssec-trigger について

unbound/etc/resolv.conf にインストールされ設定ができたら、アプリケーションからのすべての DNS クエリーは unbound によって処理されます。dnssec-triggerunbound リゾルバーを再構成するのは、そうするようにトリガーされた場合のみです。これは主に、異なる Wi-Fi ネットワークに接続するノートパソコンのような、ローミングを行うクライアントマシンに当てはまります。プロセスは以下のようになります。
  • 新規 DNS サーバーが DHCP 経由で獲得されると、NetworkManagerdnssec-triggerトリガー (開始) します。
  • Dnssec-trigger がサーバーに対して多くのテストを実行し、サーバーが DNSSEC を適切にサポートしているかどうかを判断します。
  • サポートしている場合は、dnssec-triggerunbound を再構成して、その DNS サーバーをすべてのクエリーに対するフォワーダーとして使用します。
  • テストが失敗した場合は、dnssec-trigger は新規 DNS サーバーを無視して利用可能なフォールバックの方法をいくつか試行します。
  • 無制限ポート 53 (UDP および TCP) が利用可能だと判断されたら、フォワーダーを使用せずに unbound が完全なリカーシブ DNS サーバーになるように指示します。
  • たとえば、ポート 53 が ネットワークの DNS サーバー自体以外にはファイアウォールでブロックされているなどしてこれが可能でない場合は、ポート 80 へは DNS を、ポート 443 へは TLS カプセル化された DNS の使用を試みます。ポート 80 および 443 で DNS を稼働しているサーバーは、/etc/dnssec-trigger/dnssec-trigger.conf で設定できます。デフォルトの設定ファイルでは、コメントアウトされた例が利用可能になっています。
  • これらのフォールバックの方法も失敗する場合は、dnssec-trigger は DNSSEC を完全に迂回してセキュアでない状態で機能するか、cache only モードで実行します。後者の場合、新規の DNS クエリーは試行されませんが、キャッシュにすでにあるものについてはすべて応答します。
Wi-Fi ホットスポットでは、ユーザーはインターネットへのアクセスを許可される前にサインオンページにリダイレクトされる傾向が強まっています。上記で示された調査手順の間にリダイレクトが検出されると、ユーザーはインターネットアクセスにログインが必要かどうかを尋ねるようにプロンプトが示されます。dnssec-trigger デーモンは 10 分ごとに DNSSEC リゾルバーをプローブし続けます。dnssec-trigger グラフィカルユーティリティーの使用に関する情報は、「Dnssec-trigger の使用」 を参照してください。

4.6.4. VPN が提供されるドメインサーバーおよびネームサーバー

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

4.6.5. 推奨される命名プラクティス

Red Hat では、静的および一時的なネームの両方が host.example.com のように DNS 内のマシンに使用されている 完全修飾ドメインネーム (FQDN) に合致することを推奨しています。
ICANN (The Internet Corporation for Assigned Names and Numbers) は、(.yourcompany などの) トップレベルの未登録ドメインを公開登録簿に追加することがあります。このため、Red Hat では、プライベートネットワーク上であっても委任されていないドメイン名を使用しないことを強く推奨しています。これは、ネットワーク設定によっては異なる解決をしてしまうドメインネームになってしまう可能性があるからです。その結果、ネットワークリソースは利用不可能になってしまいます。また、委任されていないドメイン名を使うと、DNSSEC の実装および維持がより困難になります。これは、ドメインネームが競合すると DNSSEC 検証に手動の設定が必要となるからです。この問題に関する詳細情報は、ICANN FAQ on domain name collision を参照してください。

4.6.6. トラストアンカーについて

階層暗号化システムでは、トラストアンカー は信頼できるとされる権威あるエンティティーです。たとえば、X.509 アーキテクチャーではルート証明書はトラストチェーンの元となるトラストアンカーとなっています。トラストアンカーは、パスの検証ができるように事前に信頼できる団体が所有しておく必要があります。
DNSSEC のコンテキストでは、トラストアンカーは DNS ネームとそのネームに関連づけられた公開鍵 (または公開鍵のキャッシュ) で構成されます。ベース 64 のエンコード化された鍵として表示されます。これは、DNS レコードの検証と認証に使用可能な公開鍵を含む情報の交換方法という意味で、証明書と同様のものになります。RFC 4033 では、設定済みの DNSKEY RR または DNSKEY RR の DS RR ハッシュとしてトラストアンカーを定義しています。有効なセキュリティー対応のリゾルバーは、この公開鍵またはハッシュを、署名済みの DNS の応答に対して認証チェーンを構築するための開始地点として使用します。一般的に、有効なリゾルバーはトラストアンカーの初期値をセキュアまたは信頼できる手段で DNS プロトコルの外部から取得する必要があります。トラストアンカーがあると、リゾルバーは、トラストアンカーがポイントするゾーンは署名されているはずとの扱いをすると意味合いがあります。

4.6.7. DNSSEC のインストール

4.6.7.1. unbound のインストール

マシン上でローカルに DNSSEC を使用する DNS を検証するためには、DNS リゾルバー unbound (または bind ) をインストールする必要があります。モバイルデバイスでは、dnssec-trigger のインストールのみが必要です。サーバーには unbound で十分ですが、サーバーの場所 (LAN もしくはインターネット) によってはローカルドメイン用の転送設定が必要となる場合もあります。dnssec-trigger は現在、グローバルの公開 DNS ゾーンのみで機能します。NetworkManagerdhclient、および VPN アプリケーションは自動でドメイン一覧 (およびネームサーバー一覧も) を収集することが多くありますが、dnssec-triggerunbound ではこれは行われません。
unbound をインストールするには、root ユーザーで以下のコマンドを実行します。
~]# yum install unbound

4.6.7.2. unbound の稼働確認

unbound デーモンが稼働しているかどうかを確認するには、以下のコマンドを実行します。
~]$ systemctl status unbound
 unbound.service - Unbound recursive Domain Name Server
	  Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled)
	  Active: active (running) since Wed 2013-03-13 01:19:30 CET; 6h ago
unbound サービスが稼働していないと systemctl status コマンドは unboundActive: inactive (dead) とレポートします。

4.6.7.3. unbound の起動

現行セッション用に unbound を起動するには、root ユーザーで以下のコマンドを実行します。
~]# systemctl start unbound
systemctl enable コマンドを実行すると unbound がシステム起動時に毎回起動します。
~]# systemctl enable unbound
unbound デーモンは、以下のディレクトリーを使用してローカルデータの設定または上書きを可能にします。
  • /etc/unbound/conf.d ディレクトリーは、特定のドメインネーム用の設定追加に使用されます。ドメインネームのクエリーを特定の DNS サーバーにリダイレクトするために使用されます。企業 WAN 内にのみ存在するサブドメインに多く使用されます。
  • /etc/unbound/keys.d ディレクトリーは、特定のドメインネーム用のトラストアンカーの追加に使用されます。これは、内部のみのネームが DNSSEC 署名されているものの、トラストのパスを構築するための DS レコードが公開で存在しない場合に必要になります。別のユースケースは、企業 WAN 外で公開で入手可能なネームではない別の DNSKEY を使って署名された、内部バージョンのドメインの場合になります。
  • /etc/unbound/local.d ディレクトリーは、ローカルで優先させる特定の DNS データを追加するために使用されます。このデータを使用すると、ブラックリストを構築したり、手動で特定の DNS を優先させたりできます。このデータは unbound によってクライアントに返されますが、DNSSEC 署名としてマークされません。
一部の VPN ソフトウェアと同様に NetworkManager では設定を動的に変更することが可能です。これらの設定ディレクトリーには、コメントアウトしたサンプルエントリーが含まれています。詳細については unbound.conf(5) man ページを参照してください。

4.6.7.4. Dnssec-trigger のインストール

dnssec-trigger アプリケーションは dnssec-triggerd デーモンとして稼働します。dnssec-trigger をインストールするには、root ユーザーで以下のコマンドを実行します。
~]# yum install dnssec-trigger

4.6.7.5. Dnssec-trigger デーモンの稼働確認

dnssec-triggerd が稼働しているかどうかを確認するには、以下のコマンドを実行します。
~]$ systemctl status dnssec-triggerd
systemctl status dnssec-triggerd.service
dnssec-triggerd.service - Reconfigure local DNS(SEC) resolver on network change
	  Loaded: loaded (/usr/lib/systemd/system/dnssec-triggerd.service; enabled)
	  Active: active (running) since Wed 2013-03-13 06:10:44 CET; 1h 41min ago
systemctl status コマンドは、 dnssec-triggerd デーモンが稼働していなければ Active: inactive (dead) とレポートします。dnssec-triggerd を現行セッションで起動するには、root ユーザーで以下のコマンドを実行します。
~]# systemctl start dnssec-triggerd
systemctl enable コマンドを実行すると dnssec-triggerd がシステム起動時に毎回起動します。
~]# systemctl enable dnssec-triggerd

4.6.8. Dnssec-trigger の使用

dnssec-trigger アプリケーションには、DNSSEC プローブの結果を表示し、DNSSEC プローブ要求をオンデマンドで実行するための GNOME パネルユーティリティーがあります。このユーティリティーを起動するには、Super キーを押してアクティビティ画面に入り、DNSSEC と入力して Enter を押します。船の錨に似たアイコンが画面下部のメッセージトレイに追加されます。画面右下の青く丸い通知アイコンを押してこれを表示させます。錨アイコンを右クリックすると、ポップアップメニューが表示されます。
通常の操作では、unbound はローカルでネームサーバーとして使用され、resolv.conf127.0.0.1 をポイントします。Hotspot Sign-On パネルの OK をクリックすると、これが変更されます。DNS サーバーが NetworkManager からクエリーを受け、resolv.conf に置かれます。これで Hotspot のサインオンページで認証が可能になります。錨アイコンは赤い大きな感嘆符を表示して、DNS クエリーが安全でない状態で行われていることを警告します。認証が行われると、dnssec-trigger は自動的にこれを検出し、セキュアモードに戻します。ただし、場合によってはこれができず、ユーザーが手動で Reprobe を選択する必要があることもあります。
Dnssec-trigger は通常、ユーザーとのやりとりを必要としません。一旦開始するとバックグラウンドで稼働し、問題が発生したらポップアップのテキストボックスでユーザーに通知します。また、resolv.conf ファイルへの変更を unbound に知らせます。

4.6.9. DNSSEC における dig の使用

DNSSEC が稼働しているかどうかを確認するには、様々なコマンドラインツールの使用が可能です。最適なのは、bind-utils パッケージからの dig コマンドです。ldns パッケージからの drillunbound パッケージからの unbound-host も有用です。nslookup および host という古い DNS ユーティリティーは旧式なので使用しないでください。
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 レコードに加えて RRSIG レコードが返されます。これには DNSSEC 署名と署名の取得および失効時間が含まれています。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)

4.6.10. Dnssec-trigger 用のホットスポット検出インフラストラクチャーの設定

ネットワークに接続する際に、dnssec-trigger はホットスポットの検出を試みます。ホットスポットは通常、ユーザーがネットワークリソースを利用する前にウェブページとのやりとりを強制するデバイスです。この検出は既知のコンテンツがある特定の固定ウェブページのダウンロード試行で行われます。ホットスポットがある場合は、既知のコンテンツ以外のものがダウンロードされます。
dnssec-trigger によるホットスポット検出に使用可能な、既知のコンテンツがある固定ウェブページを設定するには、以下の手順にしたがいます。
  1. インターネット上で公開されているマシン上にウェブサーバーを設定します。Red Hat Enterprise Linux 7 システム管理者のガイドの Web サーバー の章を参照してください。
  2. サーバーが稼働したら、既知のコンテンツがある静的ページを公開します。このページは、有効な HTML ページである必要はありません。たとえば、hotspot.txt という名前のプレーンテキストファイルで OK という文字列の内容だけでも構いません。サーバーが example.com にあり、そのサーバーのサブディレクトリー document_root/static/hotspot.txt ファイルを公開したとすると、この静的ページのアドレスは、example.com/static/hotspot.txt になります。Red Hat Enterprise Linux 7 システム管理者のガイドの Web サーバー の章にある DocumentRoot ディレクティブを参照してください。
  3. 以下の行を /etc/dnssec-trigger/dnssec-trigger.conf ファイルに追加します。
    url: "http://example.com/static/hotspot.txt OK"
    このコマンドは、HTTP (ポート 80) 経由でプローブされる URL を追加します。最初の部分は解決される URL とダウンロードされるページで、後の部分はダウンロードしたウェブページに含まれることになる文字列です。
設定オプションに関する詳細情報は、man ページ dnssec-trigger.conf(8) を参照してください。

4.6.11. 接続によって提供されるドメイン用の DNSSEC 検証の設定

デフォルトでは、適切なネームサーバーのある転送ゾーンは、Wi-Fi 以外の接続が提供するドメインすべてについて dnssec-trigger が自動的に NetworkManagerunbound に追加します。デフォルトでは、unbound に追加されるすべての転送ゾーンは DNSSEC で検証されます。
転送ゾーンの検証におけるデフォルト動作は変更可能なので、すべての転送ゾーンがデフォルトで DNSSEC 検証されるわけれは ありません。すべてを検証するようにするには、 dnssec-trigger 設定ファイルである /etc/dnssec.conf にある validate_connection_provided_zones 変数を変更します。root ユーザーでファイルを開き、以下のように行を編集します。
validate_connection_provided_zones=no
この変更は既存の転送ゾーンではなく、将来の転送ゾーンにのみ有効になります。このため、現在提供されているドメインについて DNSSEC を無効にするには、再接続が必要になります。

4.6.11.1. Wi-Fi が提供するドメイン用の DNSSEC 検証の設定

Wi-Fi が提供するゾーンへの転送ゾーンの追加を有効にすることができます。これを行うには、dnssec-trigger の設定ファイル /etc/dnssec.conf にある add_wifi_provided_zones 変数を変更します。 root ユーザーでファイルを開き、以下のように行を編集します。
add_wifi_provided_zones=yes
この変更は既存の転送ゾーンではなく、将来の転送ゾーンにのみ有効になります。このため、現在 Wi-Fi が提供するドメインについて DNSSEC を有効にするには、Wi-Fi の再接続 (再起動) が必要になります。

警告

Wi-Fi 提供ドメインを転送ゾーンとして unbound に追加することを オン にすると、セキュリティー面で以下のような影響があります。
  1. Wi-Fi アクセスポイントは意図的に、DHCP 経由でドメインを提供することが可能です。このドメインは認証されていないもので、ユーザーの DNS クエリーすべてをこのアクセスポイントの DNS サーバーにルーティングしてしまいます。
  2. 転送ゾーンの DNSSEC 検証を オフ にすると、Wi-Fi 提供の DNSサーバーは、ユーザーが知らない間に提供されたドメインからドメインネームの IP アドレスのなりすましができるようになります。

4.6.12. その他のリソース

以下のリソースでは、DNSSEC について詳細な説明が提供されています。

4.6.12.1. インストールされているドキュメント

  • dnssec-trigger(8) man ページ — dnssec-triggerddnssec-trigger-control および dnssec-trigger-panel のコマンドオプションについて説明しています。
  • dnssec-trigger.conf(8) man ページ — dnssec-triggerd の設定オプションについて説明しています。
  • unbound(8) man ページ — unboundDNS 検証リゾルバーのコマンドオプションについて説明しています。
  • unbound.conf(5) man ページ — unbound の設定方法に関する情報が含まれています。
  • resolv.conf(5) man ページ — リゾルバールーチンが読み取る情報が含まれています。

4.6.12.2. オンラインのドキュメント

http://tools.ietf.org/html/rfc4033
RFC 4033 DNS Security Introduction and Requirements.
http://www.dnssec.net/
DNSSEC リソースに関する多くのリンクがあるウェブサイトです。
http://www.dnssec-deployment.org/
米国土安全保障省が後援する DNSSEC Deployment Initiative です。DNSSEC に関する多くの情報と DNSSEC 導入に関する問題を話し合うメーリングリストが含まれています。
http://www.internetsociety.org/deploy360/dnssec/community/
Internet Society の Deploy 360 イニシアチブで、DNSSEC 導入の活性化と調整を図ります。世界中のコミュニティーと DNSSEC アクティビティーを探す便利なリソースになります。
http://www.unbound.net/
unbound DNS サービスに関する全般的な情報が含まれています。
http://www.nlnetlabs.nl/projects/dnssec-trigger/
dnssec-trigger に関する全般的な情報が含まれています。