Show Table of Contents
一部の VPN ソフトウェアと同様に NetworkManager では設定を動的に変更することが可能です。これらの設定ディレクトリーには、コメントアウトしたサンプルエントリーが含まれています。詳細については
このページには機械翻訳が使用されている場合があります (詳細はこちら)。
4.5. DNSSEC を使った DNS トラフィックのセキュア化
4.5.1. DNSSEC の概要
DNSSEC は、Domain Name System Security Extensions (DNSSEC : ドメイン名システムセキュリティー拡張機能) のセットです。
DNS
クライアントが DNS
ネームサーバーからの応答の整合性を認証、検査して、応答元を検証し、転送中に不正に変更されなかったかどうかを判別できるようにします。
4.5.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.5.3. Dnssec-trigger について
unbound
が/etc/resolv.conf
にインストールされ設定ができたら、アプリケーションからのすべての DNS
クエリーは unbound
によって処理されます。dnssec-trigger が unbound
リゾルバーを再構成するのは、そうするようにトリガーされた場合のみです。これは主に、異なる Wi-Fi ネットワークに接続するノートパソコンのような、ローミングを行うクライアントマシンに当てはまります。プロセスは以下のようになります。
- 新規
DNS
サーバーがDHCP
経由で獲得されると、NetworkManager が dnssec-trigger を「開始」します。 - Dnssec-trigger がサーバーに対して多くのテストを実行し、サーバーが DNSSEC を適切にサポートしているかどうかを判断します。
- サポートしている場合は、dnssec-trigger が
unbound
を再構成して、その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.5.4. VPN が提供されるドメインサーバーおよびネームサーバー
VPN 接続の中には、ドメインとネームサーバー一覧を伝達して、そのドメインを VPN トンネル設定の一部として使用できるタイプもあります。Red Hat Enterprise Linux では、NetworkManager がこれをサポートしています。つまり、
unbound
、dnssec-trigger、および NetworkManager の組み合わせは、VPN ソフトウェアが提供するドメインとネームサーバーを適切にサポートできるということです。VPN トンネルができれば、ローカルの unbound
キャッシュは、受け取られたドメインネームのエントリーについてフラッシュされるので、そのドメインネーム内のネームに関するクエリーは VPN 経由で届いた内部ネームサーバーから新たにフェッチされます。VPN トンネルが終了すると、unbound
キャッシュが再度フラッシュされ、ドメインへのクエリーが以前に獲得されたプライベート IP アドレスではなく、公開 IP アドレスを返すようにします。詳細は 「接続によって提供されるドメイン用の DNSSEC 検証の設定」 を参照してください。
4.5.5. 推奨される命名プラクティス
Red Hat では、静的および一時的なネームの両方が
host.example.com
のように DNS
内のマシンに使用されている 完全修飾ドメインネーム (FQDN) に合致することを推奨しています。
インターネット上の割り当てられた名前と番号(ICANN)は、未登録のトップレベルドメイン(
。yourcompany
など)をパブリックレジスタに追加することがあります。したがって、Red&Hatは、プライベートネットワーク上でも、自分に委任されていないドメイン名を使用しないことを強くお勧めします。これは、ネットワーク構成によってドメイン名の解決方法が異なる可能性があるためです。その結果、ネットワークリソースが利用できなくなる可能性があります。自分に委任されていないドメイン名を使用すると、DNSSEC検証を有効にするためにドメイン名の衝突に手動の設定が必要になるため、DNSSECの展開と維持がより困難になります。この問題の詳細については、ドメイン名の衝突に関するICANNのよくある質問を参照してください。ICANN (The Internet Corporation for Assigned Names and Numbers) は、(.yourcompany
などの) トップレベルの未登録ドメインを公開登録簿に追加することがあります。このため、Red Hat では、プライベートネットワーク上であっても委任されていないドメイン名を使用しないことを強く推奨しています。これは、ネットワーク設定によっては異なる解決をしてしまうドメインネームになってしまう可能性があるからです。その結果、ネットワークリソースは利用不可能になってしまいます。また、委任されていないドメイン名を使うと、DNSSEC の実装および維持がより困難になります。これは、ドメインネームが競合すると DNSSEC 検証に手動の設定が必要となるからです。この問題に関する詳細情報は、「Name Collision Resources and Information」を参照してください。
4.5.6. トラストアンカーについて
階層暗号化システムでは、トラストアンカー は信頼できるとされる権威あるエンティティーです。たとえば、X.509 アーキテクチャーではルート証明書はトラストチェーンの元となるトラストアンカーとなっています。トラストアンカーは、パスの検証ができるように事前に信頼できる団体が所有しておく必要があります。
DNSSEC のコンテキストでは、トラストアンカーは
DNS
ネームとそのネームに関連づけられた公開鍵 (または公開鍵のハッシュ) で構成されます。ベース 64 のエンコード化された鍵として表示されます。これは、DNS
レコードの検証と認証に使用可能な公開鍵を含む情報の交換方法という意味で、証明書と同様のものになります。RFC 4033 では、設定済みの DNSKEY RR または DNSKEY RR の DS RR ハッシュとしてトラストアンカーを定義しています。有効なセキュリティー対応のリゾルバーは、この公開鍵またはハッシュを、署名済みの DNS の応答に対して認証チェーンを構築するための開始点として使用します。一般的に、有効なリゾルバーはトラストアンカーの初期値をセキュアまたは信頼できる手段で DNS プロトコルの外部から取得する必要があります。トラストアンカーがあると、リゾルバーは、トラストアンカーが指定するゾーンは署名されているはずとの扱いをすると意味合いがあります。
4.5.7. DNSSEC のインストール
4.5.7.1. unbound のインストール
マシン上でローカルに DNSSEC を使用する
DNS
を検証するためには、DNS
リゾルバー unbound
(または bind
) をインストールする必要があります。モバイルデバイスでは、dnssec-trigger のインストールのみが必要です。サーバーには unbound
で十分ですが、サーバーの場所 (LAN もしくはインターネット) によってはローカルドメイン用の転送設定が必要となる場合もあります。dnssec-trigger は現在、グローバルの公開 DNS ゾーンのみで機能します。NetworkManager、dhclient、および VPN アプリケーションは自動でドメイン一覧 (およびネームサーバー一覧も) を収集することが多くありますが、dnssec-trigger や unbound ではこれは行われません。
unbound
をインストールするには、root
ユーザーで以下のコマンドを実行します。
~]# yum install unbound
4.5.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
コマンドは unbound
を Active: inactive (dead)
とレポートします。
4.5.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 署名としてマークされません。
unbound.conf(5)
man ページを参照してください。
4.5.7.4. Dnssec-trigger のインストール
dnssec-trigger アプリケーションは
dnssec-triggerd
デーモンとして稼働します。dnssec-trigger をインストールするには、root
ユーザーで以下のコマンドを実行します。
~]# yum install dnssec-trigger
4.5.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.5.8. Dnssec-trigger の使用
dnssec-trigger アプリケーションには、DNSSEC プローブの結果を表示し、DNSSEC プローブ要求をオンデマンドで実行するための GNOME パネルユーティリティーがあります。このユーティリティーを起動するには、Super キーを押してアクティビティ画面に入り、
DNSSEC
と入力して Enter を押します。船の錨に似たアイコンが画面下部のメッセージトレイに追加されます。画面右下の青く丸い通知アイコンを押してこれを表示させます。錨アイコンを右クリックすると、ポップアップメニューが表示されます。
通常の操作では、unbound はローカルでネームサーバーとして使用され、
resolv.conf
は 127.0.0.1
をポイントします。Hotspot Sign-On パネルの をクリックすると、これが変更されます。DNS
サーバーが NetworkManager からクエリーを受け、resolv.conf
に置かれます。これで Hotspot のサインオンページで認証が可能になります。錨アイコンは赤い大きな感嘆符を表示して、DNS
クエリーが安全でない状態で行われていることを警告します。認証が行われると、dnssec-trigger は自動的にこれを検出し、セキュアモードに戻します。ただし、場合によってはこれができず、ユーザーが手動で Reprobe を選択する必要があることもあります。
Dnssec-trigger は通常、ユーザーとのやりとりを必要としません。一旦開始するとバックグラウンドで稼働し、問題が発生したらポップアップのテキストボックスでユーザーに通知します。また、
resolv.conf
ファイルへの変更を unbound
に知らせます。
4.5.9. DNSSEC における dig の使用
DNSSEC が稼働しているかどうかを確認するには、様々なコマンドラインツールの使用が可能です。最適なのは、bind-utils パッケージからの dig コマンドです。ldns パッケージからの drill とunbound パッケージからの 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.5.10. Dnssec-trigger 用のホットスポット検出インフラストラクチャーの設定
ネットワークに接続する際に、dnssec-trigger はホットスポットの検出を試みます。ホットスポットは通常、ユーザーがネットワークリソースを利用する前にウェブページとのやりとりを強制するデバイスです。この検出は既知のコンテンツがある特定の固定ウェブページのダウンロード試行で行われます。ホットスポットがある場合は、既知のコンテンツ以外のものがダウンロードされます。
dnssec-trigger によるホットスポット検出に使用可能な、既知のコンテンツがある固定ウェブページを設定するには、以下の手順にしたがいます。
- インターネット上で公開されているマシン上にウェブサーバーを設定します。Red Hat Enterprise Linux 7 システム管理者のガイドの Web サーバー の章を参照してください。
- サーバーが稼働したら、既知のコンテンツがある静的ページを公開します。このページは、有効な HTML ページである必要はありません。たとえば、
hotspot.txt
という名前のプレーンテキストファイルでOK
という文字列の内容だけでも構いません。サーバーがexample.com
にあり、そのサーバーのサブディレクトリーdocument_root/static/
にhotspot.txt
ファイルを公開したとすると、この静的ページのアドレスは、example.com/static/hotspot.txt
になります。Red Hat Enterprise Linux 7 システム管理者のガイドの Web サーバー の章にあるDocumentRoot
ディレクティブを参照してください。 - 以下の行を
/etc/dnssec-trigger/dnssec-trigger.conf
ファイルに追加します。url: "http://example.com/static/hotspot.txt OK"
このコマンドは、HTTP
(ポート 80) 経由でプローブされる URL を追加します。最初の部分は解決される URL とダウンロードするページで、後の部分はダウンロードした web ページに含まれることになる文字列です。
設定オプションに関する詳細情報は、man ページ
dnssec-trigger.conf(8)
を参照してください。
4.5.11. 接続によって提供されるドメイン用の DNSSEC 検証の設定
デフォルトでは、適切なネームサーバーのある転送ゾーンは、Wi-Fi 以外の接続が提供するドメインすべてについて dnssec-trigger が自動的に NetworkManager で
unbound
に追加します。デフォルトでは、unbound
に追加されるすべての転送ゾーンは DNSSEC で検証されます。
転送ゾーンの検証におけるデフォルト動作は変更可能なので、すべての転送ゾーンがデフォルトで DNSSEC 検証されるわけれは ありません。すべてを検証するようにするには、 dnssec-trigger 設定ファイルである
/etc/dnssec.conf
にある validate_connection_provided_zones
変数を変更します。root
ユーザーでファイルを開き、以下のように行を編集します。validate_connection_provided_zones=noこの変更は既存の転送ゾーンではなく、将来の転送ゾーンにのみ有効になります。このため、現在提供されているドメインについて DNSSEC を無効にするには、再接続が必要になります。
4.5.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
に追加することを オン にすると、セキュリティー面で以下のような影響があります。
- Wi-Fi アクセスポイントは意図的に、
DHCP
経由でドメインを提供することが可能です。このドメインは認証されていないもので、ユーザーの全DNS
クエリーをこのアクセスポイントのDNS
サーバーにルーティングしてしまいます。 - 転送ゾーンの DNSSEC 検証を オフ にすると、Wi-Fi 提供の
DNS
サーバーは、ユーザーが知らない間に提供されたドメインからドメインネームのIP
アドレスのなりすましができるようになります。
4.5.12. その他のリソース
以下のリソースでは、DNSSEC について詳細な説明が提供されています。
4.5.12.1. インストールされているドキュメント
dnssec-trigger(8)
man ページ —dnssec-triggerd
、dnssec-trigger-control および dnssec-trigger-panel のコマンドオプションについて説明しています。dnssec-trigger.conf(8)
man ページ —dnssec-triggerd
の設定オプションについて説明しています。unbound(8)
man ページ —unbound
、DNS
検証リゾルバーのコマンドオプションについて説明しています。unbound.conf(5)
man ページ —unbound
の設定方法に関する情報が含まれています。resolv.conf(5)
man ページ — リゾルバールーチンが読み取る情報が含まれています。
4.5.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 に関する全般的な情報が含まれています。
このページには機械翻訳が使用されている場合があります (詳細はこちら)。