委任と DNS の総合診断レポート
DNS とレコード
DNS ルックアップ あらゆるドメインのすべての DNS レコード A レコードルックアップ ドメインの IPv4 アドレス AAAA レコードルックアップ ドメインの IPv6 アドレス MX ルックアップ ドメインのメールサーバー NS ルックアップ 権威ネームサーバー TXT ルックアップ TXT レコード、SPF、検証 CNAME ルックアップ 正規名（エイリアス）レコード SOA ルックアップ Start of Authority レコード SRV ルックアップ サービスロケーションレコード CAA ルックアップ どの CA が証明書を発行できるか 逆引き DNS（PTR） IP アドレスからホスト名へ DNSSEC チェック ドメインは署名され検証されているか？ DNS ヘルスチェック 委任と DNS の総合診断レポートメール到達性
SPF チェック Sender Policy Framework レコードを検証 DMARC チェック DMARC ポリシーを検査・評価 DKIM チェック DKIM 公開鍵を検索・検証 ブラックリストチェック IP をメールブロックリスト（DNSBL）と照合 SMTP テスト メールサーバーに接続し STARTTLS をチェック MTA-STS チェック 受信メールに対する強制 TLS ポリシー BIMI チェック メール用のブランドロゴレコード TLS-RPT チェック SMTP TLS レポートポリシーネットワークとウェブ
SSL 証明書チェック サイトの TLS 証明書と有効期限を検査 HTTP ヘッダーチェック レスポンスヘッダー、リダイレクト、セキュリティを検査 Ping（TCP） TCP 経由での到達性と遅延 ポートチェック どの一般的なポートが開いているかドメイン
WHOIS ルックアップ ドメイン、IP、ASN の登録データDNS ヘルスチェックは、1つのレコードタイプだけでなく、ドメインがどのように委任され、端から端まで設定されているかを検査します。まず親（TLD）サーバーに、あなたのドメインについて何を公開しているかを尋ね、次に自分のネームサーバーに直接尋ねて、両者を比較します。親とあなたのサーバーの食い違い——グルーの欠落、一致しないNSリスト、同期の取れていないSOAシリアル、レイムまたはオープン再帰のネームサーバー——こそが、DNSが遅い・断続的・気づかぬうちに壊れる原因です。IPeekはすべてのチェックを実行し、それぞれがなぜ重要で、どう修正すればよいかをわかりやすい言葉で説明します。
あなたのドメインへのあらゆる照会は、親ゾーン——TLD レジストリ（例えば .es や .com）——から始まります。親は、リゾルバーをあなたのネームサーバーへ導くNSレコードを保持しています。それらのネームサーバーが自分のドメイン内にある場合、親はそのIPアドレスを「グルー」として併せて公開しなければなりません。さもないとリゾルバーは鶏が先か卵が先かのループに陥ります。健全な委任では、親と自分のサーバーが同じNSセットで一致し、必要な箇所にグルーが存在します。両者が食い違うと、一部のリゾルバーは古い情報をたどり、あなたの変更は一部のユーザーには反映され、他のユーザーには反映されないように見えます。
RFC 2182 は、単一の障害でドメインがオフラインにならないよう、異なるネットワーク上に複数のネームサーバーを置くことを推奨しています。それぞれが自分のゾーンに対して権威をもって応答しなければなりません——応答しない「レイム」なサーバーは、気づきにくい信頼性の穴です。また、権威サーバーは見知らぬ相手への再帰を拒否すべきです。オープンな再帰ネームサーバーは、キャッシュポイズニングや DDoS 増幅に悪用される恐れがあります。IPeek は各ネームサーバーに直接照会し、応答すること、権威をもって答えること、互いに一致すること、TCP に対応すること、そして再帰を閉じていることを確認します。
SOA レコードは、ゾーンのシリアル番号とタイミング値を保持します。すべてのネームサーバーが同じシリアルを報告しなければならず、そうでなければゾーンは同期が取れておらず、変更が不均一に伝播します。シリアルは YYYYMMDDnn の慣習に従うべきで、refresh/retry/expire/minimum のタイマーは RFC が推奨する範囲に収まるべきです。メール側では、MX レコードはホスト名でなければならず（裸のIPやCNAMEは不可）、公開アドレスに解決される必要があります。最後に、Apex（裸のドメイン）はアドレスを公開すべきですが、CNAME は公開すべきではありません。RFC 1912 はほかのレコードと併存する CNAME を禁じています。
DNS ルックアップは、再帰リゾルバー越しに見えるレコードを表示します。ヘルスチェックはさらに踏み込み、親 TLD サーバーと自分の各ネームサーバーに直接照会し、それらを比較します。これにより、通常のルックアップでは見えない委任の問題——グルーの欠落、親子間のNS不一致、レイムまたは食い違うネームサーバー、同期の取れていないSOAシリアル——を捕捉できます。
グルーは、親ゾーンがNSレコードと併せて公開するネームサーバーのIPアドレスです。ネームサーバーが、自分が提供するのと同じドメイン内にある場合（例えば ns1.example.com が example.com を提供する場合）に必須です。さもないとリゾルバーは、何かを解決する前にネームサーバー自体を解決しなければならなくなるためです。その場合にグルーが欠けると解決が壊れます。ネームサーバーが別のドメインにある場合、グルーは任意であり、余分なルックアップを1回省くだけです。
権威ネームサーバーは、自分がホストするゾーンについてのみ応答すべきです。誰に対しても再帰を行うネームサーバー（「オープンリゾルバー」）は、DNS 増幅 DDoS 攻撃に悪用される恐れがあり、キャッシュポイズニングにもさらされやすくなります。ヘルスチェックがオープン再帰を指摘した場合は、権威サーバーで再帰を無効にするか、権威の役割と再帰の役割を別々のホストに分けてください。
SOA シリアルは、ゾーンのバージョン番号です。ネームサーバーが異なるシリアルを報告している場合、少なくとも1台が古いデータを提供しています——通常は、プライマリから最新のゾーンを転送できなかったセカンダリです。その結果、リゾルバーがどのサーバーに当たるかによって、応答が一貫しなくなります。ゾーン転送（AXFR/IXFR）、プライマリの NOTIFY 設定、SOA の refresh タイマーを確認してください。
どちらもエラーではありませんが、どちらも単一障害点です。MX が1つだと、そのサーバーが十分長く停止した場合にメールが失われる可能性があります。バックアップ MX があれば耐障害性が高まります。ネームサーバーが2つは RFC 2182 上は許容されますが、異なるネットワーク上に3つ以上ある方が安全です。ヘルスチェックはこれらを失敗ではなく警告として示します——改善する価値はありますが、緊急事態ではありません。