dns DNSルックアップ (A, MX, TXT, NS) star

仕組み

ドメインを入力しレコードタイプを選択すると、照会は従来のバイナリ形式のUDPポート53プロトコルではなく、DNS over HTTPS(DoH)を通じてGoogleのパブリックリゾルバー8.8.8.8に送られます — JSONベースのHTTPS APIです。これは意図的な選択です。DoHは標準のHTTPS上で動作するため、ブラウザ内から生のソケットアクセスなしに機能し、同じくらい重要なこととして、お使いのOS、ルーター、ISPが通常使用するDNSリゾルバーを完全に迂回します。あなたの端末、オフィスのネットワーク、ISPはそれぞれ独自のDNSキャッシュを保持しており、それぞれがレコードのTTL(Time To Live)に基づいて独自のスケジュールで更新するため、ある瞬間においてそれぞれが少しずつ異なる、少し古い回答を示している可能性があります。Googleのリゾルバーに直接問い合わせることで、これら3つのキャッシュすべてを迂回し、大規模で頻繁に更新される公開リゾルバーが現時点で信じている内容を示します — これは「インターネットが今何を見ているか」に最も近い代理指標ですが、それでもあくまで一つのリゾルバーの見解であり、世界的な保証ではありません。

各レコードタイプは異なる運用上の疑問に答えます。AとAAAAレコードはホスト名をIPv4またはIPv6アドレスに対応付けます — これはブラウザが接続を開く前にまさに解決する内容です。MXレコードは、そのドメイン宛のメールを受け取るメールサーバーを、数値の優先度(数値が小さいほど先に試される)とともに列挙します — メールプロバイダーを移行する際に重要です。古いMXレコードが残っていると、メールは古いプロバイダーへルーティングされ続けるからです。TXTレコードは構造化されていない任意のテキストで、SPF、DKIM、ドメイン検証文字列が格納される場所です。1つのドメインが複数のTXTレコードを持つこともあり、不正な形式や欠落したSPF TXTレコードは、正当なメールがスパムに分類される最も一般的な原因の一つです。CNAMEレコードは、あるホスト名を別のホスト名のエイリアスとして指し示します(裸のドメインを指すwwwや、CDNのエンドポイントを指すサブドメインなど) — CNAMEを持つホスト名は同じ名前で他のレコードタイプを持つことができず、これが「なぜこのサブドメインにMXレコードも設定できないのか」という混乱のよくある原因です。NSレコードは、そのドメインに関する問い合わせに答える責任を持つ権威ネームサーバーを列挙します — これらが誤っていたり、レジストラと同期していなかったりすると、そのドメインの他のどのレコードもどこでも正しく解決されません。

典型的な使用例:ウェブサイトを新しいホストに移行した後、AレコードをGoogleの新しいサーバーのIPに向けます。伝播は瞬時には起こりません — 古いレコードのTTLによって制限されます。TTLが3600(1時間)に設定されたレコードは、世界中のキャッシュから消えるまで最大1時間かかることがあり、一部のリゾルバーはTTLを無視してそれ以上長くキャッシュすることさえあります。GoogleのDoHリゾルバーに直接問い合わせることで、自分のISPのキャッシュの期限切れを待たずに、「新しい値が少なくともこの大手リゾルバーには届いているか」を確認できます。

知っておくべきこと

• DNS over HTTPSはローカルキャッシュを迂回するため、ここでの結果はnslookupやOSが示すものより新しいことがあります — これは想定どおりであり、不具合ではありません。
• A、MX、TXT、CNAME、NSはほぼすべての伝播・メール・検証確認をカバーします。SRVやCAAのような珍しいタイプは現時点では含まれていません。
• DNSの変更はキャッシュされるものであり、瞬時には反映されません — 以前のTTLに応じた遅延を見込んでください。即座に世界中へ反映されるわけではありません。