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

今日では、インターネット接続で多くのウェブサイトが 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 対応のリカーシブリゾルバーを実装するには、BIND または unbound を使用することができます。両方ともデフォルトで DNSSEC を有効にし、DNSSEC root キーで設定されています。サーバー上で DNSSEC を有効にするにはどちらでも可能ですが、ノートパソコンなどのモバイルデバイスでは、unbound が推奨されます。これは、dnssec-trigger 使用時にはホットスポット、Libreswan 使用時には VPN に必要となる DNSSEC 上書きの再構成をローカルユーザーが動的に行えるようになるためです。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 トンネルが終了すると、unbound キャッシュが再度フラッシュされ、ドメインへのクエリーが以前に獲得されたプライベート IP アドレスではなく、公開 IP アドレスを返すようにします。詳細は 「接続によって提供されるドメイン用の DNSSEC 検証の設定」 を参照してください。

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」を参照してください。

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

DNSSEC のコンテキストでは、トラストアンカーは DNS ネームとそのネームに関連づけられた公開鍵 (または公開鍵のハッシュ) で構成されます。ベース 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 も有用です。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)

ネットワークに接続する際に、dnssec-trigger はホットスポットの検出を試みます。ホットスポットは通常、ユーザーがネットワークリソースを利用する前にウェブページとのやりとりを強制するデバイスです。この検出は既知のコンテンツがある特定の固定ウェブページのダウンロード試行で行われます。ホットスポットがある場合は、既知のコンテンツ以外のものがダウンロードされます。

dnssec-trigger によるホットスポット検出に使用可能な、既知のコンテンツがある固定ウェブページを設定するには、以下の手順にしたがいます。

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

デフォルトでは、適切なネームサーバーのある転送ゾーンは、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 を無効にするには、再接続が必要になります。

add_wifi_provided_zones=yes

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