Red Hat Training

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

4.5.2. DNSSEC について

インターネット上で接続するため、Web サイトの数が増えると、HTTPS を使用して安全に接続できるようになりました。ただし、HTTPS Web サーバーに接続する前に、IP アドレスを直接入力しない限り DNS ルックアップを実行する必要があります。これらの DNS ルックアップは安全ではないため、認証の欠如により中間攻撃の対象となります。言い換えると、指定の DNS ネームサーバーから現れる応答が信頼できると、改ざんされていない DNS クライアントには安全ではありません。より重要なのは、再帰的ネームサーバーは、他のネームサーバーから取得するレコードが、性の値であることを確認できません。DNS プロトコルは、クライアントの仲介用攻撃の影響を受けないように、クライアントにメカニズムを提供していませんでした。DNS を使用してドメイン名を解決する際に、DNSSEC は認証および整合性チェックがないことに対応するために導入されました。機密性の問題は対処しません。
DNSSEC 情報の公開には、デジタル署名 DNS リソースレコードと、DNS リゾルバーを有効にして信頼の階層チェーンを構築するようにする手段があります。すべての DNS リソースレコードのデジタル署名が生成され、デジタル署名リソースレコード(RRSIG)としてゾーンに追加されます。ゾーンの公開鍵は DNSKEY リソースレコードとして追加されます。階層チェーンを構築するには、DNSKEY のハッシュが署名(DS)リソースレコードの委譲として親ゾーンに公開されます非共存を容易にするために、NextSECure (NSEC)および NSEC3 リソースレコードが使用されます。DNSSEC 署名ゾーンでは、各リソースレコードセット (RRset)には対応する RRSIG リソースレコードがあります。子ゾーン(NS および glue レコード)への委譲に使用されるレコードは署名されていません。これらのレコードは子ゾーンに表示され、そこに署名されています。
DNSSEC 情報の処理は、root ゾーンの公開鍵で設定されたリゾルバーを使用して行われます。このキーを使用することで、リゾルバーはルートゾーンで使用される署名を検証できます。たとえば、root ゾーンは DS レコード for.com に署名されています。root ゾーンは、.com ネームサーバーの NS レコードおよび glue レコードも提供します。 リゾルバーは、これらの委譲されたネームサーバーを使用して、この委譲されたネームサーバーを使用してこの委任およびクエリーに従います。取得した DNSKEY レコードのハッシュは、root ゾーンの DS レコードと一致する必要があります。その場合、リゾルバーは取得した DNSKEY for.com を信頼します。.com ゾーンでは、RRSIG レコードは.com DNSKEY によって作成されます。 このプロセスは、redhat.com などの委譲の反復です。この方法では、通常の操作時に多数の DNSKEY を収集する間、DNS リゾルバーの検証を 1 つのルートキーでのみ設定する必要があります。暗号化チェックに失敗すると、リゾルバーは SERVFAIL をアプリケーションに返します。
DNSSEC は、DNSSEC をサポートしないアプリケーションに完全に見えない方法で設計されています。DNSSEC 以外のアプリケーションが DNSSEC 対応リゾルバーをクエリーすると、RRSIG などのこれらの新しいリソースレコードタイプなしで応答を受け取ります。ただし、DNSSEC 対応リゾルバーは引き続きすべての暗号化チェックを実行し、悪意のある DNS の応答を検出すると、アプリケーションに SERVFAIL エラーを返します。DNSSEC は DNS サーバー(authoritative and recursive)との間でデータの整合性を保護し、アプリケーションとリゾルバー間でセキュリティーを提供しません。そのため、アプリケーションに、リゾルバーにセキュアなトランスポートが付与されることが重要です。最も簡単な方法として、ローカルホストで DNSSEC 対応リゾルバーを実行し、/etc/resolv.conf127.0.0.1 を使用します。または、リモート DNS サーバーへの VPN 接続を使用できます。

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

Wi-Fi Hotspots または VPN は、DNS の電子ポータル(Captive portal) DNS に依存するため、ユーザーは Wi-Fi サービスの認証(または支払)サービスに対して認証(または支払)する必要があるページにリダイレクトするために Captive portals の DNS ハイジャックの DNS に依存します。VPN に接続するユーザーは、企業ネットワーク外に存在しないリソースを見つけるために、多くの場合に内部 DNS サーバーを使用する必要があります。これには、ソフトウェアによる追加の処理が必要になります。たとえば、dnssec-trigger を使用すると、Hotspot が DNS クエリーとバインドされていない DNS クエリーのハイジャックが、DNSSEC クエリーを処理できるプロキシーネームサーバーとして動作します。

DNSSEC Capable Recursive Resolver の選択

DNSSEC 対応の再帰リゾルバーをデプロイするには、BIND または unbound のいずれかを使用できます。両方はデフォルトで DNSSEC を有効にし、DNSSEC root キーで設定されます。サーバーで DNSSEC を有効にするには、ノートブックなど、モバイルデバイスではバインドされていないデバイスの使用が推奨されます。これは、ローカルユーザーが dnssec-trigger を使用する際に、Hotspots に必要な DNSSEC の上書きを動的に再設定することや、Libreswan の使用時に VPN では動的に再設定できるようにします。unbound デーモンは、etc/unbound/*.d/ ディレクトリーに一覧表示されている DNSSEC 例外のデプロイメントをさらにサポートし、サーバーおよびモバイルデバイスの両方に役立ちます。

このページには機械翻訳が使用されている場合があります (詳細はこちら)。