Back

開発者が知っておくべきDNSの基礎知識

開発者が知っておくべきDNSの基礎知識

アプリケーションをデプロイしたのに、ユーザーから接続できないという報告が届きました。最初はサーバーを確認したくなるかもしれませんが、実際の原因はDNSであることが多いのです。DNSの基礎を理解することは任意ではなく、本番環境の問題をデバッグし、Webアプリケーションが実際にどのようにユーザーに到達するかを理解するために不可欠です。

この記事では、DNS解決の流れ、一般的なレコードタイプ、キャッシュの動作、そしてパフォーマンスとセキュリティに影響を与える最新のDNS開発について説明します。

重要なポイント

  • DNS解決には3つの層が関与します:スタブリゾルバ、再帰リゾルバ、権威ネームサーバー。障害はどの段階でも発生する可能性があります
  • TTL値が伝播時間を決定します。移行前にTTLを下げておき、移行中ではなく事前に対応しましょう
  • HTTPSレコード(SVCB)は、より高速で安全なブラウザ接続のための接続ヒントを提供します
  • DNSSECはレコードを認証し、DoH/DoT/DoQはクエリを暗号化します。それぞれ異なる問題を解決します
  • DNS問題をデバッグするには、digまたはnslookupを使用して異なるリゾルバにクエリを送信します

DNS解決の仕組み

ブラウザがapi.example.comに接続する必要がある場合、IPアドレスを魔法のように知っているわけではありません。解決プロセスには3つの層が関与します:

スタブリゾルバ: オペレーティングシステムに組み込まれたDNSクライアント。名前解決自体は行わず、設定された再帰リゾルバにクエリを転送し、応答をローカルにキャッシュします。

再帰リゾルバ: 通常、ISPまたはCloudflare(1.1.1.1)やGoogle(8.8.8.8)などのパブリックサービスによって運用されています。このサーバーが重い処理を行い、ユーザーに代わって他のサーバーにクエリを送信します。

権威ネームサーバー: ドメインのDNSレコードの信頼できる情報源。再帰リゾルバはDNS階層を辿ります。ルートサーバー、次にTLDサーバー(.com、.ioなど)、そしてドメインの権威サーバーの順に、答えを見つけます。

開発者にとって重要な洞察は、DNS障害がどの層でも発生する可能性があるということです。スタブリゾルバの設定ミス、到達不可能な再帰リゾルバ、または古い権威レコードのいずれもアプリケーションを壊す可能性があります。

一般的なDNSレコードタイプ

以下のレコードは頻繁に遭遇します:

  • A / AAAA: ホスト名をIPv4またはIPv6アドレスにマッピング
  • CNAME: あるホスト名を別のホスト名にエイリアス(ゾーンapexでは使用できません。example.com自体にはAまたはAAAAレコードが必要です)
  • MX: ドメインのメールサーバーを指定
  • TXT: 任意のテキストを保存。ドメイン検証やメール認証(SPF、DKIM)に一般的に使用されます
  • NS: ゾーンを特定のネームサーバーに委任

これらを理解することで、CDN、メールサービスの設定、またはサブドメインが解決されない理由のデバッグに役立ちます。

DNSキャッシュとTTL

DNSキャッシュとTTL(Time To Live、生存時間)は、デプロイ戦略に直接影響します。すべてのDNSレコードには秒単位のTTL値が含まれています。リゾルバがレコードをキャッシュすると、TTLが期限切れになるまで再度クエリを送信しません。

実用的な影響:

  • 3600秒(1時間)のTTLは、DNS変更の伝播に最大1時間かかることを意味します
  • 移行前に、変更中ではなく事前にTTLを下げておきます
  • ブラウザとオペレーティングシステムは独自のキャッシュを保持し、さらに別の層を追加します

「DNS伝播には24〜48時間かかる」という神話は誤解を招きます。伝播時間は以前のTTL値に依存します。古いTTLが86400秒(24時間)だった場合、それが最悪の待ち時間になります。

最新のDNS: HTTPSレコードと暗号化トランスポート

DNSは近年大幅に進化しています。Web開発者にとって最も重要な2つの開発があります。

HTTPSレコード(SVCB)

HTTPSレコード(SVCBレコードの特定のタイプ)は、ブラウザがサーバーに接続する前に接続ヒントを提供します。以下を通知できます:

  • HTTP/3とQUICのサポート
  • 代替ポート
  • Encrypted Client Hello(ECH)キー

これにより、ブラウザはより高速で安全な接続を確立できます。ただし、HTTPSレコードのサポートはまだ普遍的ではありません。すべてのDNSプロバイダーがサポートしているわけではなく、一部のリゾルバはクエリを送信しません。

注意: HTTPSレコードは限定的なapexエイリアス機能を提供しますが、完全なCNAME-at-apexソリューションではありません。

DNS over HTTPS(DoH)と暗号化DNS

従来のDNSクエリは、UDPポート53を介して平文で送信されます。DNS over HTTPS(DoH)、DNS over TLS(DoT)、DNS over QUIC(DoQ)は、これらのクエリを暗号化し、盗聴や改ざんを防ぎます。

暗号化DNSは現在広く展開されています。FirefoxとChromeは多くの構成でデフォルトでDoHを使用していますが、普遍的ではありません。企業ネットワークと一部のISPは、暗号化DNSを傍受またはブロックしています。

DNSSECと暗号化: 違いを理解する

よくある混乱: DNSSECは暗号化ではありません。

DNSSEC認証を提供します。DNSレコードに暗号署名を付けることで、リゾルバが応答が改ざんされていないことを検証できます。クエリを隠すことはありません。

暗号化DNS(DoH/DoT/DoQ)はプライバシーを提供します。トランスポート層を暗号化するため、観察者がどのドメインをクエリしているかを見ることができません。

これらは異なる問題を解決し、一緒に使用できます。

アプリケーションでDNS障害がどのように現れるか

DNSが失敗すると、通常次のようなエラーが表示されます:

  • NXDOMAINエラー(ドメインが存在しない)
  • 接続タイムアウト(リゾルバに到達不可能)
  • SERVFAIL応答(上流サーバーの問題)

ブラウザでは、これらは「DNS_PROBE_FINISHED_NXDOMAIN」または類似のエラーとして表示されます。Node.jsまたは他のランタイムでは、ENOTFOUNDまたは同等の例外が発生します。

デバッグにはdigまたはnslookupを使用します。異なるリゾルバにクエリを送信して、問題がローカルキャッシュ、リゾルバ、または権威サーバーのいずれにあるかを特定します。

まとめ

DNSはユーザーとサーバーの間に位置します。解決フロー、TTLの動作、HTTPSレコードやDoHなどの最新プロトコルを理解することで、より信頼性の高いデプロイとより迅速なデバッグが可能になります。何かが壊れたとき、DNSは最後の容疑者ではなく、最初の容疑者の1つであるべきです。

よくある質問

ターミナルでdigコマンドを使用します。例えば、dig example.com AでAレコードを確認したり、dig example.com ANYですべてのレコードを表示したりできます。dig @8.8.8.8 example.comのようにリゾルバを指定して、GoogleのDNSに直接クエリを送信することもできます。Windowsでは、代わりにnslookup example.comを使用します。

DNS変更が遅延して見えるのは、リゾルバがTTL値に基づいてレコードをキャッシュするためです。以前のTTLが3600秒だった場合、リゾルバはその1時間が経過するまで更新を確認しません。将来の変更を高速化するには、更新を行う前にTTLを十分に下げ、その後元に戻します。

Aレコードはホスト名を直接IPアドレスにマッピングします。CNAMEは、あるホスト名を別のホスト名に指すエイリアスを作成し、それがIPに解決されます。CNAMEは外部サービスを指すサブドメインに便利ですが、ゾーンapexでは使用できません。ルートドメインにはAまたはAAAAレコードが必要です。

DoHはDNSクエリを暗号化し、ネットワーク観察者がどのドメインを解決しているかを見ることを防ぎます。エンドユーザーのプライバシーには有益です。ただし、サーバーアプリケーションの場合、インフラストラクチャはすでに知られているため、従来のDNSで十分なことが多いです。ネットワーク仲介者からのプライバシーがユースケースにとって重要な場合は、DoHを検討してください。

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay