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


4.5.1. DNS の概要

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

4.5.2. DNSSEC について

インターネット経由で接続するために、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.conf127.0.0.1 を使用することです。または、リモート DNS サーバーへの VPN 接続を使用することもできます。

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

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

DNSSEC 対応の再帰的リゾルバーの選択

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

4.5.3. Dnssec-trigger について

unbound/etc/resolv.conf にインストールされ、設定されると、アプリケーションからの DNS クエリーはすべて unbound によって処理されます。dnssec-trigger は、トリガーされた場合にのみ unbound リゾルバーを再設定します。これは、ノートパソコンなど、異なる Wi-Fi ネットワークに接続するローミングクライアントマシンに主に適用されます。プロセスは以下のようになります。
  • NetworkManager は、新しい DNS サーバーが DHCP 経由で取得されたときに dnssec-triggerトリガー します。
  • dnssec-trigger は、サーバーに対して多くのテストを実行し、DNSSEC を適切にサポートしているかどうかを判断します。
  • その場合、dnssec-triggerunbound を再設定し、その DNS サーバーをすべてのクエリーのフォワーダーとして使用します。
  • テストが失敗した場合、dnssec-trigger は新しい DNS サーバーを無視し、いくつかの利用可能なフォールバック方法を試します。
  • 無制限のポート 53 (UDP および TCP)が使用可能であると判断した場合、フォワーダーを使用せずに完全な再帰 DNS サーバーになるように unbound に指示します。
  • これが不可能な場合(たとえば、ポート 53 がネットワークの DNS サーバー自体に到達する場合を除きすべてについてファイアウォールによってブロックされている場合)は、DNS を使用してポート 80 に到達するか、または TLS でポート 443 にカプセル化された DNS を使用しようとします。ポート 80 および 443 で DNS を実行しているサーバーは、/etc/dnssec-trigger/dnssec-trigger.conf で設定できます。コメントアウトされた例は、デフォルトの設定ファイルで利用できるはずです。
  • これらのフォールバック方法も失敗すると、dnssec-trigger は、DNSSEC を完全にバイパスする安全でない方法で動作するか、新しい DNS クエリーを試行しないが、キャッシュ内にすでに存在するすべてのものに応答する cache only モードで実行することを提案します。
Wi-Fi ホットスポットは、インターネットへのアクセスを許可する前に、ユーザーをサインオンページにリダイレクトすることが多くなっています。上記のプロービングシーケンス中にリダイレクトが検出された場合、インターネットにアクセスするためにログインが必要かどうかを尋ねるプロンプトがユーザーに表示されます。dnssec-trigger デーモンは、10 秒ごとに DNSSEC リゾルバーのプローブを続行します。dnssec-trigger グラフィカルユーティリティーの使用方法は、「Dnssec-trigger の使用」 を参照してください。

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

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

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

階層暗号化システムでは、トラストアンカーは信頼できると想定される、信頼できるエンティティーです。たとえば、X.509 アーキテクチャーでは、ルート証明書がトラストチェーンの元となるトラストアンカーとなっています。トラストアンカーは、パスの検証ができるように、事前に信頼できる団体が所有しておく必要があります。
DNSSEC のコンテキストでは、トラストアンカーは、その名前に関連付けられた DNS 名と公開鍵(または公開鍵のハッシュ)で設定されます。これは、base 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 をインストールするだけで済みます。サーバーの場合は、サーバーが置かれている場所(LAN またはインターネット)によってはローカルドメインの転送設定が必要になる場合がありますが、unbound で十分です。dnssec-trigger は現在、グローバルパブリック DNS ゾーンでのみ役立ちます。NetworkManagerdhclient、VPN アプリケーションは、多くの場合、ドメインリスト(およびネームサーバーリスト)を自動的に収集できますが、dnssec-triggerunbound は収集できません。
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
systemctl status コマンドは、バインド されていないサービスが実行されていない場合に、unboundActive: 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 データをローカルオーバーライドとして追加するために使用されます。これは、ブラックリストを作成したり、手動オーバーライドを作成したりするために使用できます。このデータは unbound によってクライアントに返されますが、DNSSEC 署名としてマークされません。
NetworkManager と一部の VPN ソフトウェアは、設定を動的に変更することがあります。これらのコンフィギュレーションディレクトリーには、コメントアウトされたサンプルエントリーが含まれています。詳細は、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
dnssec-triggerd デーモンが実行していない場合は、systemctl status コマンドは dnssec-triggerdActive: inactive (dead) として報告します。現行セッションで起動するには、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.conf127.0.0.1 を指します。Hotspot Sign-On パネルで OK をクリックすると、これが変更されます。DNS サーバーは NetworkManager からクエリーされ、resolv.conf に配置されます。これで、Hotspot のサインオンページで認証ができるようになりました。アンカーアイコンには、DNS クエリーが安全ではないことを警告するために、大きな赤い感嘆符が表示されます。認証されると、dnssec-trigger は自動的にこれを検出し、セキュアモードに戻す必要がありますが、場合によってはユーザーではなく、ユーザーは Reprobe を選択して手動でこれを行う必要があります。
dnssec-trigger は通常、ユーザーの対話を必要としません。一度起動するとバックグラウンドで動作し、問題が発生した場合は、ポップアップのテキストボックスでユーザーに通知します。また、resolv.conf ファイルへの変更について unbound に通知します。

4.5.9. DNSSEC における dig の使用

DNSSEC が機能しているかどうかを確認するために、さまざまなコマンドラインツールを使用することができます。最適なツールは、bind-utils パッケージの dig コマンドです。ldns パッケージからの drillunbound パッケージの 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)

4.5.10. Dnssec-trigger の Hotspot 検出インフラストラクチャーのセットアップ

ネットワークに接続すると、dnssec-trigger は Hotspot を検出しようとします。Hotspot は通常、ユーザーがネットワークリソースを使用する前に、Web ページとのユーザーインタラクションを強制するデバイスです。検出は、既知のコンテンツを含む特定の固定 Web ページのダウンロードを試みることによって行われます。Hotspot がある場合、受信したコンテンツは想定どおりではありません。
dnssec-trigger が Hotspot を検出するために使用できる既知のコンテンツを含む固定 Web ページを設定するには、次の手順に従います。
  1. インターネット上で公開されているマシンに Web サーバーをセットアップします。Red Hat Enterprise Linux 7 システム管理者ガイドの Web Servers の章を参照してください。
  2. サーバーを実行したら、既知のコンテンツを含む static ページを公開します。ページは有効な HTML ページである必要はありません。たとえば、文字列 OK のみを含む hotspot.txt という名前のプレーンテキストファイルを使用できます。サーバーが example.com にあり、Web サーバーの document_root/static/ サブディレクトリーに hotspot.txt ファイルをパブリッシュした場合、静的 Web ページのアドレスは 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 とダウンロードされるページです。コマンドの 2 番目の部分は、ダウンロードされた Web ページが含むと予想されるテキスト文字列です。
設定オプションの詳細は、man ページの dnssec-trigger.conf (8)を参照してください

4.5.11. 接続が提供されるドメインの DNSSEC 検証の設定

デフォルトでは、適切なネームサーバーを持つ正引きゾーンは、NetworkManager を介した Wi-Fi 接続を除き、すべての接続で dnssec-trigger によって unbound に自動的に追加されます。デフォルトでは、unbound に追加されたすべての転送ゾーンは DNSSEC 検証済みです。
転送ゾーンの検証に関するデフォルトの動作は、デフォルトではすべての転送ゾーンが DNSSEC で 検証されない ように、変更することができます。これを行うには、dnssec-trigger 設定ファイル /etc/dnssec.confvalidate_connection_provided_zones 変数を変更します。root ユーザーとして、以下のように行を開いて編集します:
validate_connection_provided_zones=no
この変更は、既存の正引きゾーンではなく、将来の正引きゾーンに対してのみ行われます。したがって、現在提供されているドメインの DNSSEC を無効にする場合は、再接続する必要があります。

4.5.11.1. Wi-Fi 提供ドメインの DNSSEC 検証の設定

Wi-Fi 提供ゾーンの転送ゾーンの追加を有効にすることができます。これを行うには、dnssec-trigger 設定ファイル /etc/dnssec.confadd_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.5.12. 関連情報

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

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

  • dnssec-trigger (8) man ページ - dnssec-triggerddnssec-trigger-controldnssec-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 に関する多くのリソースへのリンクがある Web サイト。
http://www.dnssec-deployment.org/
米国国土安全保障省が後援する DNSSEC デプロイメントイニシアチブには、多くの DNSSEC 情報が含まれており、DNSSEC のデプロイメントに関する問題を議論するためのメーリングリストもあります。
http://www.internetsociety.org/deploy360/dnssec/community/
DNSSEC のデプロイメントを刺激し、調整するための Internet Society の Deploy 360 イニシアチブは、世界中のコミュニティーと DNSSEC 活動を見つけるための優れたリソースです。
http://www.unbound.net/
本書には、バインドされていない DNS サービスに関する一般的な情報が記載されています。
http://www.nlnetlabs.nl/projects/dnssec-trigger/
本書には、dnssec-trigger に関する一般的な情報が記載されています。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.