LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）として名前解決基盤・DNSの開発・運用を受託

DNSレコードの設定ミスが招く名前解決の停止——全サービスが一斉に到達不能になる怖さ

自社サイトへのアクセス、社員が使う業務システム、取引先とのメール送受信——。これらはすべて、ドメイン名をIPアドレスへ変換する「名前解決」の上で動いています。利用者がドメイン名で接続すると、その問い合わせはフルリゾルバ(キャッシュDNS)を経て、最終的に自社が管理する権威DNSサーバーへ届き、そこに登録されたレコードが応答として返るわけです。JPRSは、この応答を返すサーバーを権威DNSサーバーと呼んでいます^*6。

やっかいなのは、この障害の多くが攻撃ではなく「地味な人為ミス」から起きる点です。レコードを一文字打ち間違える、公開すべきでない値を残す、子ゾーンの委任(NSレコード)を誤る、DNSSECの署名と親ゾーンの登録がずれる——。どれも単独では小さな操作ですが、名前解決という共通基盤を壊すため、影響は突然かつ全面的に現れます。しかもキャッシュDNSはレコードをTTL(次に問い合わせるまで保持する時間)の分だけ抱え込むので、誤った値がしばらく残り続けることもあるのです^*1。

手作業と表計算ソフトの台帳に頼っていると、ドメインやレコードの本数が増えるほど、この見落としのリスクは膨らんでいきます。だからこそ、レコードの発行・変更・委任を体系立てて統制し、改ざん対策や障害回避まで一貫して扱うDNS管理の仕組みが要るわけです。本稿では、DNS管理システムが何をする仕組みなのか、証明書管理(PKI)や監視基盤とどう役割が分かれるのか、そして開発・運用を外注する際にどこを確認すべきかを、公式情報に基づいて整理していきます。想定する読者は、名前解決基盤の発注を検討するIT部門の意思決定層の方々です。

DNS管理システムとは、権威DNSのレコード運用と名前解決基盤を統制する仕組み

DNS(Domain Name System)は、ルート(「.」)を頂点に、com・jpなどのトップレベルドメイン、co.jpなどの下位ドメインへと連なる階層構造です^*1。その各階層のドメインを世界中の権威DNSサーバーが分担してホストしています^*1。自社ドメインの名前解決を担うのは、この階層の末端にある自社の権威DNSサーバーです。

マイクロソフトは、特定ドメインのDNSレコードをホストする単位を「DNSゾーン」と呼び、ドメインをホストするにはまずそのDNSゾーンを作成し、各レコードをゾーン内に作成すると説明しています^*1。たとえばcontoso.comというゾーンには、メールサーバー向けのmail.contoso.comやWebサイト向けのwww.contoso.comといったレコードが収まります^*1。DNS管理システムとは、このゾーンとレコードを、発行から変更、委任、失効(削除)まで統制し、名前解決を止めないよう運用する仕組みを指すわけです。

ここで押さえておきたいのは、DNS管理が単なる「レコードの登録」で終わらない点です。ゾーンの頂点(apex)にはNSレコードとSOAレコードが自動で作られ、子ゾーンへの委任もNSレコードで表現されます^*1。さらに、応答の改ざんを防ぐDNSSECの署名や、キャッシュの保持時間を決めるTTLの設計、変更時の承認フローまでが運用の対象になります。どのレコードがどこにあり、いつ・誰が・何を変えたかを一元的に把握する。この統制こそが、名前解決の停止による障害を防ぐ土台になるのです。

証明書管理(PKI)・監視基盤との違い——「名前解決基盤の運用」に特化する領域

DNS管理を検討する際に混同されやすいのが、証明書管理(PKI)や監視基盤との違いです。いずれもシステムの可用性やセキュリティにかかわるため、守備範囲が重なって見えます。当サイトでも証明書管理や監視基盤(Zabbix)は別途取り上げていますが、DNS管理が担う対象はそれらとは別物です。ここで境界を整理しておきましょう。

証明書管理(PKI)が相手にするのは、SSL/TLSサーバー証明書やクライアント証明書という「身元を証明する文書」の発行・更新・失効です。通信の暗号化と相手認証を支える領域であり、証明書切れによる通信断を防ぐことに主眼があります。一方のDNS管理が扱うのは、ドメイン名とIPアドレスなどを結びつける「名前解決そのもの」です。両者は隣り合いますが、DNSSECの署名鍵とTLS証明書は別物であり、混同すると要件定義でどちらの層に何を任せるかが曖昧になります。

監視基盤(Zabbixなど)は、サーバーやネットワーク機器の稼働状態・性能を継続的に観測し、異常を検知して通知する仕組みです。「動いているかを見張る」役割であって、名前解決の設定そのものを統制するわけではありません。DNS管理はレコードやDNSSEC、TTLといった名前解決の「設定と運用」を担い、その健全性を監視基盤が外形から見守る、という補完関係にあると整理できるでしょう。3者の違いを表にまとめます。

要件定義の段階で「どの層に何を任せるか」を先に切り分けておくと、機能の重複投資や責任の空白を避けやすくなります。DNS管理は名前解決基盤の運用に特化した領域であり、証明書管理や監視とは別に設計・運用の体制を考える必要があるのです。

DNS管理システムの機能要素——レコード運用・DNSSEC・TTL設計・変更承認

DNS管理システムの中身を、機能要素に分解して見ていきます。ここを理解しておくと、外注時の要件定義でどこに工数がかかるかを判断しやすくなるでしょう。

レコード運用——A/AAAA/CNAME/MX/TXT/NSの管理と変更フロー

名前解決の実体は、ゾーンに登録された各種レコードです。マイクロソフトの資料によれば、もっとも一般的なのは名前をIPv4アドレスへ対応づけるAレコードで、名前をメールサーバーへ対応づけるMXレコードもよく使われます^*1。同社のAzure DNSはA・AAAA・CAA・CNAME・MX・NS・PTR・SOA・SRV・TXTといった一般的なレコード種別に対応しています^*1。それぞれの役割を押さえておくことが、運用ミスを防ぐ第一歩になります。

代表的な種別を整理すると、AはIPv4アドレス、AAAAはIPv6アドレスへの対応づけです^*1。CNAMEは別名(エイリアス)を表しますが、同じ名前で他の種別と共存できず、ゾーンの頂点(apex)にも置けないという制約があります^*1。MXはメールサーバー、NSは権威DNSサーバーの指定や子ゾーンへの委任を担います^*1。TXTは任意のテキストを保持し、メール認証のSPFやDKIMで使われる種別です^*1。なおSPFはかつて専用種別がありましたが、RFC 7208により現在はTXTレコードで作成することとされ、専用種別は非推奨になっています^*1。同じ名前・同じ種別のレコードの集合はレコードセットとして扱われ、SOAとCNAMEだけは1件しか持てません^*1。

運用で肝心なのは、これらを「誰が・いつ・どう変えるか」のフローです。1件の変更が名前解決全体に波及するため、変更前の影響確認、変更後の反映確認、そして誤りに気づいたときの切り戻しまでを手順として持つことが求められます。台帳が散在していると、どのゾーンにどのレコードがあるかすら追えなくなり、変更のたびに事故の芽が生まれます。

DNSSEC——電子署名による応答の改ざん・なりすまし対策

レコードを正しく管理していても、名前解決の「経路」で応答が差し替えられれば意味がありません。これを防ぐのがDNSSEC(DNS Security Extensions)です。JPRSはDNSSECを、DNSの応答に電子署名を付加し、問い合わせ側で検証することでDNSへの攻撃への耐性を高める仕組みだと説明しています^*5。マイクロソフトも、DNSSECはDNS応答が本物であると検証できるようにする拡張群で、とりわけDNSスプーフィング攻撃への耐性を高めると述べています^*2。

DNSSECではゾーンに署名(ゾーン署名)を施し、RRSIG(署名)やDNSKEY(公開鍵)、DS(委任を保護する記録)といったレコードを追加します^*2。検証側のフルリゾルバは、信頼の起点(トラストアンカー)であるDNSKEYを使って署名を検証し、ハッシュ値が一致すればAレコードなどの応答を返し、一致しなければSERVFAILを返します^*2。これにより、キャッシュポイズニングなどで応答を偽装し、利用者を悪意あるサーバーへ誘導するDNSハイジャックを防げるわけです^*2。たとえばAレコードが偽装されれば偽サイトへ、MXレコードが偽装されればメールが攻撃者へ流れかねませんが、署名検証はこれを弾きます^*2。

DNSSECの要は「途切れない信頼の連鎖(チェーン・オブ・トラスト)」です。子ゾーンが署名されていても、親ゾーンにその子のDSレコードが正しく登録されていなければ、連鎖は切れて検証は失敗します^*2。鍵の運用も見落とせません。ゾーンに署名する鍵(ZSK)は定期的に交換され、その鍵を署名する鍵(KSK)はより長い有効期間を持ちますが、KSKを交換する際は親ゾーンのDSレコードも更新する必要があります^*2。この鍵と委任の整合を保てないと、改ざん対策のはずのDNSSECが、逆に名前解決を止める原因になってしまうのです。

TTL設計とフェイルオーバー——ヘルスチェック連動の障害回避

TTL(Time To Live)は、各レコードを問い合わせ側が再取得するまでキャッシュに保持する時間です^*1。マイクロソフトの例では3600秒(1時間)が示され、指定できる値は1秒から2,147,483,647秒の範囲とされています^*1。TTLを長くするとキャッシュが効いて問い合わせは減りますが、レコードを変更しても古い値が長く残ります。逆に短くすると変更の反映は速くなる代わりに、問い合わせ回数は増えるのが難点でしょう。この設計は、障害時の切り替え速度に直結します。

障害回避の代表的な仕組みが、ヘルスチェックと連動したフェイルオーバーです。AWSのRoute 53は、Webアプリケーションやサーバーの正常性を監視するヘルスチェックを提供し、同じ役割を持つ複数のリソースがある場合、異常なリソースから正常なリソースへトラフィックを振り向けるDNSフェイルオーバーを構成できると説明しています^*3。たとえばWebサーバーが2台あり片方が異常になれば、もう片方へ誘導するといった具合です^*3。

ヘルスチェックの挙動も理解しておきたい点です。Route 53は世界各地のヘルスチェッカーから対象へリクエストを送り、間隔は10秒ごとか30秒ごとを選べます^*4。各チェッカーは応答時間と、指定した連続失敗回数(失敗しきい値)をもとに正常性を判定し、全体では18%を超えるチェッカーが正常と報告すればそのエンドポイントを正常とみなします^*4。切り替えを速くしたいならTTLを短めに設計する必要がありますが、短すぎれば権威DNSへの負荷が増えます。TTLとヘルスチェック、フェイルオーバーは一体で設計してこそ、障害時の到達不能時間を短く抑えられるのです。

変更承認——設定ミス・委任ミスを防ぐレビューと権限分離

ここまで見た機能は、いずれも1件の操作ミスが名前解決全体を止めうるものです。だからこそ、変更を誰かが単独で本番へ反映できない仕組み——変更内容のレビュー、承認、権限の分離——が運用の要になります。誰がどのゾーンを変更できるかを絞り、変更前に第三者が影響を確認し、記録を残す。この統制があるかどうかで、設定ミスや委任ミスの事故率は大きく変わってきます。

特に委任(NSレコード)やDNSSECのDSレコードの変更は、親子ゾーンの整合にかかわるため影響が広範です^*1*2。変更承認のフローを持たないまま本番を触ると、一度の誤りが長時間の名前解決停止につながりかねません。DNS管理システムには、こうした変更の統制を仕組みとして組み込むことが望まれます。

DNS管理基盤の構築・運用を外注する際に確認したい4つの点

DNS管理は、ツールを導入すれば完結する性格のものではありません。自社にどのゾーン・レコードがあるかを把握し、改ざん対策を施し、障害時の切り替えを設計し、変更を統制する運用の設計に成否がかかっています。外注を検討する際は、次の4点を委託先と確認しておくとよいでしょう。

第一に、レコードの棚卸しと一元管理を設計できるかどうかです。Webサーバー、メール、社内システム、外部SaaS連携と、レコードは散在します。どのゾーンに何があり、どのTTLで、いつ変更されたかを可視化する仕組みを描けるかが出発点になります^*1。台帳が整っていなければ、変更も改ざん対策も後手に回るからです。

第二に、DNSSECの署名と鍵運用まで担えるかです。ゾーン署名、RRSIG・DNSKEY・DSレコードの管理、親ゾーンへのDS登録、そしてKSK/ZSKの鍵交換と委任の整合維持までを設計・運用できるかを見ます^*2。ここは連鎖が一箇所でも切れると検証が失敗するため、鍵と委任を継続的に整合させる運用力が問われます^*2。

第三に、TTL設計とフェイルオーバーを一体で設計できるかです。ヘルスチェックの間隔や失敗しきい値、正常判定の考え方を踏まえ、切り替え速度と問い合わせ負荷のバランスをとれるかを確認します^*3*4。障害時に何秒で正常系へ振り向けたいのかという目標から逆算した提案ができる委託先が望ましいでしょう。

第四に、変更承認の統制を仕組みとして提供できるかです。誰がどのゾーンを変更できるかの権限分離、変更前レビュー、記録の保全までを運用に組み込めるかを見ます。DNSは一度の設定ミス・委任ミスが全面的な障害に直結するため、人手の注意力に頼らない統制が要るのです。これらは複数の専門領域にまたがります。棚卸しからDNSSEC運用、TTL・フェイルオーバー設計、変更承認までを一貫して担える体制が前提になります。現状のDNS管理状況を診断したうえで、内製と外注の切り分けを検討することが実務的です。

まとめ：DNS管理システムで押さえる3つの要点

本稿では、DNS管理システムの仕組みと外注時の確認点を、公式情報をもとに整理しました。要点は3つに集約できます。第一に、DNS管理とは権威DNSのゾーンとレコード(A/CNAME/MX/NS等)を発行・変更・委任・失効まで統制し、名前解決を止めない運用を支える仕組みです^*1。第二に、証明書管理(PKI)や監視基盤とは対象が異なり、DNS管理は名前解決基盤の運用に特化して、DNSSECによる改ざん対策やTTL・フェイルオーバーによる障害回避を担います^*2*3。第三に、レコード運用・DNSSECの署名と鍵運用・TTL設計とフェイルオーバー・変更承認という4つの機能要素を一貫して回せる体制かどうかが、外注の分かれ目になるでしょう^*1*2*4。名前解決は全サービスの土台であるだけに、統制の質がそのまま事業継続の質につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Microsoft「DNS Zones and Records Overview」（Azure DNS ドキュメント）（https://learn.microsoft.com/en-us/azure/dns/dns-zones-records）
2. *2　出典：Microsoft「Overview of DNSSEC」（Azure Public DNS ドキュメント）（https://learn.microsoft.com/en-us/azure/dns/dnssec）
3. *3　出典：Amazon Web Services「Creating Amazon Route 53 health checks and configuring DNS failover」（Amazon Route 53 Developer Guide）（https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html）
4. *4　出典：Amazon Web Services「How Amazon Route 53 determines whether a health check is healthy」（Amazon Route 53 Developer Guide）（https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html）
5. *5　出典：JPRS用語辞典「DNSSEC（ディーエヌエスセック）」（株式会社日本レジストリサービス）（https://jprs.jp/glossary/index.php?ID=0019 ）
6. *6　出典：JPRS用語辞典「権威サーバー（権威DNSサーバー）」（株式会社日本レジストリサービス）（https://jprs.jp/glossary/index.php?ID=0145 ）

Tweet