6月4日、Louwrentius氏が「DNS is for people」と題した記事を公開した。
Facebook障害が示したDNS依存のリスク
2021年10月、Facebook/Meta（現在のMeta）で発生した大規模障害は、DNSへの過度な依存がもたらすリスクを世界中に知らしめた。この障害では、DNS可用性への「循環依存」により、従業員が物理的に建物から締め出されるという前例のない事態まで発生した。
現在、多くの企業がクラウドネイティブなアーキテクチャを採用し、マイクロサービス間の通信が増加している。そんな中、Louwrentius氏は挑発的な問いを投げかける：内部ITインフラでDNSを使用する必要は本当にあるのか？
「それはいつもDNS」— 運用者が恐れる障害パターン
IT運用の現場では、この短い俳句が有名だ：
It's not DNS
There's no way it's DNS
It was DNS
実際に、Facebook障害以外にもAWSの障害事例など、DNSが関与した重大インシデントは数多く存在する。これらのケースで注目すべきは、根本原因がDNS自体ではないにも関わらず、DNSが事実上すべてのサービスの重要経路にあるため、障害の影響が甚大になることだ。
DNSは本来「人間のため」の技術
DNS（Domain Name System）は、人間にとってIPアドレス（185.15.59.224）を覚えるのが困難で、ドメイン名（wikipedia.org）を覚える方がはるかに簡単だという理由で生まれた。インターネット上のサービスでは、人間がアクセスする必要があるため、DNSの仕組みを使ってウェブサイトやAPIエンドポイントを公開するのは理にかなっている。
しかし著者は、機械同士の通信において果たしてDNSが必要なのかという根本的な疑問を提起する。
内部インフラでDNSを避けるべき理由
1. キャッシュによる予期しない動作
DNSクライアントはTTL（Time To Live）に基づいてDNSレコードをキャッシュする。異なるDNSクライアント実装は異なる動作をする可能性があり、比較的同質な環境であっても、すべてのクライアントが更新されたIPアドレスを確実に使用することを保証するのは困難だ。
2. セキュリティリスク
現在、ほとんどのネットワークトラフィックはHTTPSなどで暗号化されているが、DNSはデフォルトでは平文だ。DNSSECで軽減できるが、それは別の管理負荷を導入する。
3. データ流出の経路
攻撃者はdnscat2やiodineなどのツールを使い、DNSクエリを通じてデータを外部に流出させることができる。攻撃者はドメインを取得し、sensitivedata.evil.domainのようなDNSリクエストを実行することで、悪意のあるDNSサーバーのログからデータを抽出する。
実用的な代替案：/etc/hostsの活用
著者が提案する解決策は意外にもシンプルだ。**/etc/hostsファイルを活用する**ことで、DNSサービスなしにドメイン名を使用できる。Ansibleやpyinfraなどの構成管理ツールを使えば、大規模にシステムを設定するのも容易だ。
この方法により、DevOps/プラットフォームエンジニアは人間にとって読みやすいドメイン名を設定に使いながら、DNSサービスへの依存を避けることができる。
現在の技術トレンドとの関連
近年、サービスメッシュ技術（Istio、Linkerd）やサービスディスカバリ（Consul、etcd）が普及している背景には、従来のDNSベースの名前解決の限界があることも一因だ。これらの技術は、より高度な負荷分散やヘルスチェック機能を提供する一方、DNSへの依存度を下げる方向性も示している。
評価と今後の展望
著者は、すべてはトレードオフであり、組織のコンテキストやリスク許容度に応じて判断する必要があると述べている。それでも、信頼性と堅牢性を高めるために、ITインフラ内でDNSを完全に避けることができるかどうかを検討するのは合理的だと結論づけている。
クラウドネイティブ時代において、障害の影響を最小化する設計思想は重要性を増している。この記事は、当たり前のように使われているDNSについて、改めて考え直すきっかけを提供してくれる。
詳細はDNS is for peopleを参照していただきたい。
