Domain IP Lookup

再帰的なDNS検索を1ホップずつ見る

ブラウザー

example.comを要求

リゾルバー

ISP / 1.1.1.1

ルート + TLD

.comの管理元は?

権威サーバー

正式な回答

この連鎖の各ホップはそれ自体がDNS検索で、結果はその後キャッシュされます

セキュリティ

DNSSECとは?DNS応答を検証する仕組み

読了時間:4分

DNSセキュリティ拡張(DNSSEC)は、DNSデータに暗号による認証を加える仕組みです。検証リゾルバーが、応答が意図したゾーンに由来し、転送中に改ざんされていないことを確認する助けになります。DNSSECは、DNSクエリを暗号化せず、問い合わせ先のドメイン名を隠さず、ウェブサイトの安全性を保証するものでもありません。提供するのは署名と鍵の連鎖であり、リゾルバーはこれを使って、署名されたデータを信頼されたルートまでさかのぼって検証できます。連鎖が正しく設定されていれば、リゾルバーは応答が本物であるというより強い根拠を得られます。連鎖が壊れていると、検証によって、本来は普通に成功するはずの検索まで失敗することがあります。

DNSSECの連鎖を構成するレコード

署名されたゾーンは、署名の検証に使う公開鍵を含むDNSKEYレコードを公開します。RRSIGレコードはレコードセットの署名を運び、親ゾーンにあるDSレコードは、子ゾーンの鍵を親の信頼の連鎖につなぎます。NSECやNSEC3のデータは、名前やレコードが存在しないことの認証付きの証明に使われます。運用者は一般に、これらの値の作成と保守をDNSプロバイダーやレジストラに任せますが、責任が分かれる場合があります。子ゾーンはDNSホストが署名し、親側のDSレコードはレジストラ経由で公開されます。この両者の不一致は、検証の問題でよくある原因です。

レコードDNSSECでの役割
DNSKEYゾーンの公開署名鍵を公開する
RRSIGDNSレコードセットへの署名を運ぶ
DS子ゾーンの鍵を親の信頼の連鎖に結び付ける
NSEC / NSEC3特定の否定応答(存在しないことの応答)を認証する

検証リゾルバーは、設定済みのトラストアンカー(通常はルート)から、親ゾーンと子ゾーンを通って信頼の連鎖をたどります。署名が有効であること、そしてレコードが鍵や委任のデータと一致していることを確認します。一般のユーザーがこれらの手順を目にすることはまずありませんが、結果には表れます。正しく署名された応答は受け入れられ、署名の連鎖が壊れているとSERVFAILになることがあります。検証を行わないリゾルバーは、検証リゾルバーが拒否する値を返すことがあります。DNSSECの障害が特定のネットワークだけで起きているように見えるのは、このためです。ホスト名にレコードがないと決めつけるより、リゾルバーを比較し、検証の状態を確認するほうが多くのことが分かります。

DNSSECの障害が起きるパターン

よくある失敗には、DNSプロバイダーを変更したあともレジストラに古いDSレコードが残っている、署名されたゾーンと対応しない鍵を公開している、署名が停止して有効期限が切れた、親と子で調整せずに委任を変更した、などがあります。DNSSECの導入や鍵のロールオーバーは、プロバイダーが文書化した手順に従って行い、独立した検証リゾルバーから確認する必要があります。DNSSECを無効にする場合、古いDSデータが残っていると、DSレコードがない状態よりも有害になりえます。検証側は、子がもう提供していない連鎖を引き続き期待するかもしれないからです。レジストラとDNSホストは、1つの作業を構成する連動した要素として扱ってください。

  • DNSプロバイダーがゾーンに署名し、鍵のローテーションを管理しているかを確認する。
  • レジストラのDS値が、プロバイダーの最新の案内と一致していることを確認する。
  • DNSSECを有効化、無効化、または移行したあとは、検証リゾルバー経由でテストする。
  • 鍵の変更は慎重に計画し、ロールバックの手段を確保しておく。
  • DNSSECによる認証と、暗号化されたDNSトランスポートを混同しない。

検証の失敗をトラブルシューティングする

検証リゾルバーからドメインがSERVFAILを返す場合は、無関係なAレコードやMXレコードを変更する前に、DNSSECの連鎖を確認します。権威ゾーンのDNSKEYと署名を確認し、親が公開しているDSと比較してください。署名の有効期間と、最近のプロバイダー側の変更も調べます。一般的なドメインからIPへの検索では、名前解決に失敗したことは分かっても、DNSSECの連鎖のどこが壊れているのかまでは分からないかもしれません。その詳しい問いには、DNSSEC対応の診断ツールを使ってください。リゾルバー、検証結果、問い合わせ時刻を障害メモに残しておくと、プロバイダーが再現可能な事例として調査できます。

DNSSECはデータの真正性を高めますが、運用の正確さは依然として重要です。ドメイン所有者のアカウントが乗っ取られることは防げず、誤ったレコードを正しくすることもできません。設定された鍵に従って、公開されたデータを認証するだけです。基礎的な背景は、DNS名前解決の解説 と DNSレコードタイプ をご覧ください。DNSSECは、連鎖を維持し、更新や移行をまたいで監視できる体制が整っている場合に有効化してください。一度オンにすれば正しさがずっと保証されるスイッチとして扱うのは避けましょう。

鍵のロールオーバーは、連携した変更として扱う

DNSSECの鍵のロールオーバーでは、検証リゾルバーが頼りにしている暗号の素材が変わります。安全な正確な手順は、署名を行うプロバイダーと、ロールオーバーがマネージドか手動かによって異なります。ドキュメントに記載された手順に従い、古い鍵と新しい鍵を必要なだけ重ねて公開し、署名を有効に保ち、適切な段階で親のDSデータが公開済みの鍵と一致するようにします。古いダッシュボードのスクリーンショットからDS値をコピーしたり、無関係な検索がタイムアウトしたからといって削除したりしてはいけません。ロールオーバーのあとは、複数のDNSSEC検証リゾルバーで確認し、プロバイダーのイベントログを保管してください。検証に失敗した場合は、ドメイン、リゾルバー、レスポンスコード、時刻を記録し、アプリケーションのレコードに手を付ける前に、署名とDSの関連付けを確認します。監視を伴う計画的なロールオーバーは、ブラウザーやメールシステムが失敗し始めてから慌てて連鎖を修復するより、はるかに安全です。

ドメインの公開DNSアドレスを調べたい場合は、Domain IP Lookupツールをお試しください。

関連記事

IPv4の各範囲にはIPv6の対応物がある

ループバックIPv4では127.0.0.0/8、IPv6では::1
プライベートIPv4では10.0.0.0/8など、IPv6ではfc00::/7
リンクローカルIPv4では169.254.0.0/16、IPv6ではfe80::/10
セキュリティ

見過ごせないIPv6のセキュリティ上の注意点

セキュリティの観点では、IPv6は単なる「アドレスが増えたIPv4」ではありません。いくつかの違いが、脅威モデルを実際に変えます。

読了時間:3分

偽の回答で競争に勝つ

攻撃者

本物の応答と競争

偽の回答

先に到着

リゾルバーキャッシュ

共有する全員分が汚染される

セキュリティ

DNSスプーフィングとキャッシュポイズニングの概要

偽のDNS応答でトラフィックをそらす手口は、ネットワークの世界で最も古いものの1つです。DNSSECや最新のリゾルバーの防御が存在する理由でもあります。

読了時間:3分

パブリックとプライベートのアドレス空間

パブリックIP

192.0.2.10

グローバルに一意、どこからでもルーティング可能

プライベート範囲

10.0.0.0/8172.16.0.0/12192.168.0.0/16

公開インターネットではルーティング不可

セキュリティ

プライベートIP範囲が公開DNSで解決されてはいけない理由

10.0.0.0/8や192.168.0.0/16などの範囲は、世界で一意にならないよう、あえて用意されています。それがDNSにとって重要な理由を解説します。

読了時間:3分