Menu Close

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

4.5.2. DNSSEC について

インターネットを介して接続するために、HTTPS を使用して安全に接続する機能を提供する Web サイトが増えています。ただし、HTTPSWebサーバーに接続する前に、IPアドレスを直接入力しない限り、DNSルックアップを実行する必要があります。これらの DNS ルックアップは安全に行われず、認証がないため、中間者 攻撃の対象となります。つまり、 DNSクライアントは、特定のDNSネームサーバーから送信されたように見える応答が本物であり、改ざんされていないことを確信できません。さらに重要なことに、再帰的ネームサーバーは、他のネームサーバーから取得したレコードが本物であることを確認できません。DNS プロトコルは、クライアントが中間者攻撃を受けないようにするためのメカニズムを提供していませんでした。DNSSEC は、DNS を 使用してドメイン名を解決する際に、認証と整合性のチェックができないことに対処するために導入されました。DNSSEC は、機密性の問題には対処しません。
DNSSEC 情報の公開には、DNS リソースレコードのデジタル署名のほか、DNS リゾルバーが信頼の階層チェーンを構築できるように公開鍵を配布することが含まれます。すべての DNS リソースレコードに対するデジタル署名が生成され、デジタル署名リソースレコード (RRSIG) としてゾーンに追加されます。ゾーンの公開鍵は、DNSKEY リソースレコードとして追加されます。階層的な連鎖を構築するために、DNSKEYのハッシュをDSDelegation 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 つの root キーで設定するだけで済みます。暗号チェックに失敗した場合、リゾルバーはアプリケーションに SERVFAIL を返します。
DNSSEC は、DNSSEC をサポートしていないアプリケーションからは完全に見えないように設計されています。DNSSEC 非対応のアプリケーションが DNSSEC 対応リゾルバーにクエリーした場合、RRSIG などのこれらの新しいリソースレコードタイプがなくても応答を受け取ります。ただし、DNSSEC 対応のリゾルバーは引き続きすべての暗号化チェックを実行し、悪意のある DNS 応答を検出した場合は、アプリケーションに引き続き SERVFAIL エラーを返します。DNSSECは、DNSサーバー(権威および再帰的)間のデータの整合性を保護しますが、アプリケーションとリゾルバ間のセキュリティは提供しません。したがって、アプリケーションにリゾルバーへの安全なトランスポートを提供することが重要です。これを実現する最も簡単な方法は、DNSSECに対応したリゾルバをlocalhostで実行し、/etc/resolv.conf127.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 を有効にするには、どちらでも構いませんが、ノート PC などのモバイルデバイスでは、ローカルユーザーが動的に DNSSEC オーバーライド (dnssec-trigger 使用時は Hotspot 用、Libreswan 使用時は VPN 用に必要) を再設定できる unbound の使用が望ましいです。unbound デーモンは、サーバーとモバイルデバイスの両方に有用である etc/unbound/*.d/ ディレクトリーにリストされている DNSSEC 例外のデプロイメントをさらにサポートしています。