DNSはインターネットの電話帳である

私たちが毎日当たり前のように使っているWebブラウジング。その裏では、DNSという巨大な分散データベースが休むことなく動き続けています。エンジニアとして10年以上インフラに関わってきた経験から言えば、DNSを深く理解しているかどうかで、トラブルシューティングの速度は劇的に変わる。本記事では、名前解決の基本的な仕組みからDNSSECまで、実務で役立つレベルで解説する。

名前解決の仕組みを正確に理解する

DNSの名前解決は、一見シンプルだが実際には複数のステップを経て行われます。ブラウザにURLを入力してからWebページが表示されるまでの間に、以下のような処理が走っています。

再帰的問い合わせと反復的問い合わせ

DNSの問い合わせには2つの方式があります。まず、クライアント（スタブリゾルバ）からフルサービスリゾルバへの問い合わせは「再帰的問い合わせ」と呼ばれます。クライアントは「この名前のIPアドレスを教えてくれ」と依頼し、リゾルバが最終的な答えを返すまで待つ。

一方、フルサービスリゾルバから権威DNSサーバーへの問い合わせは「反復的問い合わせ」です。リゾルバはルートサーバーから順にたどっていき、最終的な答えを自分で組み立てる。この違いを正確に理解していないと、DNS設計時に誤った構成を組んでしまうことがあります。

キャッシュとTTLの重要性

DNSのパフォーマンスを支えているのがキャッシュの仕組みです。各DNSレコードにはTTL（Time To Live）が設定されており、この値の設定は運用上極めて重要です。TTLを短くすれば変更の反映は早くなるが、DNSサーバーへの問い合わせ回数が増加する。逆にTTLを長くすれば負荷は減るが、障害時の切り替えに時間がかかる。

実務では、通常時はTTLを3600秒（1時間）程度に設定し、サーバー移行やDR切り替えの予定がある場合は事前にTTLを300秒（5分）程度に下げておくというのが一般的なプラクティスです。この「事前にTTLを下げる」作業を忘れて移行当日に慌てるケースは、意外とよく見かける。

DNSレコードの種類と実務での使い分け

DNSには様々なレコードタイプが存在するが、実務で頻繁に扱うものを整理しておこう。

• Aレコード：ドメイン名をIPv4アドレスに変換する最も基本的なレコード
• AAAAレコード：IPv6アドレスへの変換。IPv6対応が進む現在、設定の重要度が増しています
• CNAMEレコード：別名を定義する。CDNやロードバランサーとの連携で多用されます
• MXレコード：メールサーバーを指定する。優先度の設定が重要
• TXTレコード：テキスト情報を格納する。SPF、DKIM、DMARCなどメール認証に不可欠
• SRVレコード：サービスの場所を指定する。マイクロサービス環境での利用が増加
• NSレコード：ゾーンの権威サーバーを指定する。委任設計で重要

特に最近はTXTレコードの重要性が増しています。ドメイン所有権の検証、メール認証、さらにはサービス間連携の設定など、様々な用途で利用されるようになりました。

DNSセキュリティの課題

キャッシュポイズニングの脅威

DNSが抱える根本的なセキュリティ問題の一つが、キャッシュポイズニングです。攻撃者がDNSリゾルバのキャッシュに偽の情報を注入し、ユーザーを悪意のあるサーバーに誘導する手法です。2008年にダン・カミンスキーが発表した攻撃手法は、DNSの脆弱性を世界に知らしめた。

この攻撃が成立する根本原因は、従来のDNSにはレスポンスの真正性を検証する仕組みがなかったことにある。UDPベースの通信であるため、送信元の偽装も容易だった。ソースポートのランダム化やQID（Query ID）の強化である程度の対策は行われたが、根本的な解決にはならなかった。

DNSトンネリングとDDoS

DNSを悪用した攻撃はキャッシュポイズニングだけではありません。DNSトンネリングは、DNSクエリとレスポンスにデータを埋め込むことで、ファイアウォールを迂回して通信を行う手法です。マルウェアのC2通信に利用されるケースも多いです。

また、DNS増幅攻撃（DNS Amplification Attack）は、DDoS攻撃の代表的な手法の一つです。小さなクエリで大きなレスポンスを生成し、被害者に大量のトラフィックを送りつける。オープンリゾルバの存在がこの攻撃を可能にしているため、自社のDNSサーバーがオープンリゾルバになっていないかの確認は必須です。

DNSSECによる信頼性の確保

これらのセキュリティ課題に対する根本的な解決策として登場したのがDNSSECです。DNSSECは、DNSレスポンスに電子署名を付与することで、データの完全性と出自の真正性を検証可能にする拡張機能です。

DNSSECの仕組み

DNSSECでは、各ゾーンがZSK（Zone Signing Key）とKSK（Key Signing Key）という2種類の鍵ペアを持つ。ZSKは各レコードの署名に使用され、KSKはZSKの正当性を証明するために使用されます。この階層的な信頼の連鎖（Chain of Trust）により、ルートゾーンからの検証が可能になります。

新たに追加されるレコードタイプとして、RRSIG（署名データ）、DNSKEY（公開鍵）、DS（委任署名者）、NSEC/NSEC3（不存在証明）があります。特にNSEC3は、ゾーンウォーキング攻撃を防ぐために導入された重要な仕組みです。

DNSSEC導入の現実

DNSSECの有効性は広く認められているものの、導入率は依然として低いのが現実です。その理由は複数ある。まず、鍵管理の運用コストが高いです。ZSKは定期的なローテーションが必要で、KSKのロールオーバーはさらに慎重な手順が求められます。

また、DNSSECはレスポンスサイズを大きくするため、UDP断片化の問題を引き起こすことがあります。これはEDNS0によるバッファサイズの拡張で対応されているが、中間機器との互換性問題が生じることもあります。

さらに、DNSSECは暗号化を提供しないという点も理解しておく必要があります。あくまでデータの改ざん防止が目的であり、通信の秘匿化にはDoH（DNS over HTTPS）やDoT（DNS over TLS）が別途必要になります。

今後のDNSの展望

DNSの世界は静かに、しかし確実に進化を続けています。DoHやDoTによるプライバシー保護、マルチCDN環境でのインテリジェントなDNSルーティング、そしてゼロトラストアーキテクチャにおけるDNSの役割拡大など、エンジニアとして押さえておくべきトピックは増える一方です。

基礎に立ち返ってDNSの仕組みを正確に理解することは、ネットワークエンジニアのみならず、すべてのITエンジニアにとって価値のある投資です。名前解決という一見地味な仕組みの裏には、インターネットの信頼性を支える精巧な設計思想が詰まっています。