DNSヘルスチェック
ドメインのDNSチェックを、レジストリの委任、直接問い合わせる全ネームサーバー、SOA、DNSSEC、メールのレコードまで行うドメイン検証ツールです。40項目それぞれに修正方法を示します。
ルートサーバーから.nlレジストリへたどり、sidn.nlの各ネームサーバーに直接問い合わせます · 40項目 · 約3秒.nlレジストリ → 全ネームサーバー · 40項目
.nlNS 3件DNSSEC：署名済みsidn.nlは、実行したすべてのチェックに合格しました（DNSSECを含む）
SIDNで登録·2.9秒
A+：情報以上の指摘なし。すべてのネームサーバーが権威を持って応答し、互いに一致しています。タイマーはZonemasterの範囲内にあり、Google Public DNSはルートからのDNSSECの信頼の連鎖を検証しています。
DNSヘルスチェックでは、DNS設定の何を確認する？
DNSヘルスチェックは、リゾルバーがドメインを見つけるのと同じ順にたどり、各段階をテストします：レジストリの委任、直接問い合わせる各ネームサーバー、サーバー同士が一致しているか、SOAレコード、DNSSEC、メールのレコードです。このDNSチェックは7グループ40項目を実行し、各項目をその基準が定めるレベルで評価します。
多くのチェッカーはリゾルバーに問い合わせ、返ってきた結果を評価します。これでは背後のサーバーが見えません：リゾルバーは動いているネームサーバーのどれかから応答を得るため、壊れたサーバーは、他のサーバーも故障するまで気付かれません。ここでは各ネームサーバーに再帰オフのTCPで問い合わせ、レジストリにあるNSレコードのコピーをゾーン自身のものと比較し、DNSSECの信頼の連鎖をレジストリのDSからゾーン内の署名まで検証します。
変更の後には、DNS監査として使ってください：ウェブサイトが表示されるかどうかだけでなく、ドメインが依存するDNSレコードを確認します（サイトそのものは、サイトダウンチェッカーで確認できます）。レポートをコピーを押すと、結果がプレーンテキストのDNSレポートになり、チケットに貼り付けられます。
評価レベルだけで決まります：重大なし、エラーなし、警告2件ならAです。リングはスコア（100点中90点）を示します。40項目、1項目に1マスページの一覧と同じグループ順です。黄色と青のマスは警告と注意、斜線のマスは実行できなかったチェックです。問題を先に修正すべき点のあるグループが上に開き、各行に根拠となる基準と修正方法を表示します。経路ルートサーバー、Verisignが運用する.comレジストリ、そして直接問い合わせた各ネームサーバー：その応答、シリアル、EDNSです。信頼の連鎖経路の横にあるDNSSECのレールです：保たれている所は緑、止まっている所は破線、壊れている所は赤で表示します。DNSチェックの評価はどう決まる？
評価の文字は、失敗した項目のレベルだけで決まり、点数表は使いません：重大な問題が1つでもあればF、エラー2件以上でD、エラー1件または警告5件以上でC、警告3～4件でB、警告1～2件（または注意のみ）でA、情報以上の指摘がなければA+です。
レベルは、引用している基準自身のものです：テストを定義している場合はZonemasterのデフォルトプロファイル、そうでなければRFCのMUSTまたはSHOULDです。100点満点のスコアは、同じ文字の中でドメインを順位付けするためだけのものです（100から、重大1件につき30、エラー1件につき12、警告1件につき4、注意1件につき1を引きます）。当サイトのサーバーで実行できないチェックが、ドメインの不利になることはありません。4分の1以上を実行できなかった場合、評価には一部のみと表示されます。
- A+100情報以上の指摘なしINFO 「問題を示すものでは決してない」sidn.nl100
- A90～99警告1～2件、または注意のみNOTICE 「ゾーンの管理者が知っておくべきだが、必ずしも問題であるとは限らない」github.com90example.com95bücher.de90
- B75～89警告3～4件WARNING 「状況によっては問題になるが、一般の利用者が気付く可能性は低い」cloudflare.com87google.com83
- C60～74エラー1件、または警告5件以上ERROR 「ゾーンの機能に悪影響を及ぼす可能性が非常に高い（あるいは確実に及ぼす）」サンプルになし
- D45～59エラー2件以上dnssec-failed.org55
- F0～44重大な問題が1つでもあるCRITICAL 「存在しないと言っても差し支えない」.comのドメイン44
スコア = 100 − 30 × 重大 − 12 × エラー − 4 × 警告 − 1 × 注意（その文字の範囲内に収めます）
一部のみ4分の1以上のチェックを当サイトのサーバーから実行できなかったため、評価にそのことを表示します
親と子のNSレコードは一致している？
一致しているべきです：レジストリ（親）とゾーン（子）はそれぞれNSセットを公開しており、RFC 1912 §2.8は両者を同じに保つよう求めています。ゾーンに応答しないサーバーをレジストリが指している状態がレームデリゲーションです：そのサーバーはREFUSEDを返すか、権威（AA）フラグなしで応答します。
リゾルバーは次のサーバーに移るため、レームなサーバーが1台なら時間を失うだけですが、リストされたすべてのサーバーがレームなら、ドメインは名前解決できなくなります。Zonemasterは、レジストリだけがリストする名前をエラー（EXTRA_NAME_PARENT）、ゾーンだけがリストする名前を注意、動作するサーバーが1台もない状態を重大と評価します。
github.com一致
- ns-520.awsdns-01.net
- ns-421.awsdns-52.com
- ns-1707.awsdns-21.co.uk
- ns-1283.awsdns-32.org
- dns1–4.p08.nsone.net
- 同じ8台
8台中8台がAAで応答
.netのドメイン不一致
- ns1.domaindirect.com
- ns2.domaindirect.comREFUSED
- ns3.domaindirect.com
- ns1.hover.com
- ns2.hover.com
共通の名前なし · ns2.domaindirect.comはREFUSED · エラー2件
.comのドメインレームデリゲーション
- ns63.domaincontrol.comREFUSED
- ns64.domaincontrol.comREFUSED
- 誰も応答しないSERVFAIL
全サーバーがREFUSED · リゾルバーはSERVFAILを返す · CRITICAL
ドメインに必要なネームサーバーは何台？
最低2台、推奨は3台です。RFC 1034 §4.1はすべてのゾーンを少なくとも2台のサーバーで提供するよう求め、RFC 2182 §5はほとんどの組織レベルのゾーンに3台を推奨しています。Zonemasterでは、ネームサーバー1台はエラー、2台は情報付きの合格です。
台数より重要なのは置き場所です。そのため、このネームサーバーの確認では、所属するネットワークも調べます。1つのネットワークにあるサーバーは一緒に停止します：Zonemasterは、すべてのアドレスが1つの自律システム（AS）にあると警告します（IPV4_ONE_ASN）。Google、Cloudflare、Akamaiのように、各アドレスが多数の拠点から応答するanycastのホストでも同じです。anycastは負荷を分散しますが、運用者は1社のままです。
- google.comNS 4件 · 1ネットワークネットワークが1つ
- github.comNS 8件 · 2ネットワーク分散
- sidn.nlNS 3件 · 2ネットワーク分散
- cloudflare.comNS 5件 · 1ネットワークネットワークが1つ
- nasa.govNS 6件 · 1ネットワークネットワークが1つ
- example.comNS 2件 · 1ネットワークネットワークが1つ
AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1
「ほとんどの組織レベルのゾーンには3台のサーバーを用意し、少なくとも1台は他から十分に離れた場所に置くことが推奨される。」 RFC 2182 §5
SOAレコードの値は正しい？
大手のDNSホストが設定した値なら、チェッカーが指摘しても、ほぼ確実に問題ありません。リフレッシュ、リトライ、エクスパイアは、ゾーン転送でゾーンをコピーするセカンダリサーバーだけを制御します。ミニマムはネガティブキャッシュのTTL（RFC 2308）で、名前が存在しないことをリゾルバーが記憶しておく時間です。
RIPE-203（1999年）は、リフレッシュ86400、リトライ7200、エクスパイア3600000、ミニマム172800を推奨しています（最後の値はRFC 2308以前のものです）。Zonemasterの下限はそれより低く、リフレッシュ14400とリトライ3600（注意）、エクスパイア604800（唯一の警告）、ミニマムは300から86400の間（注意）です。Cloudflare、Route 53、Azureのデフォルト値はリフレッシュとリトライの下限を下回っており、Google Cloud DNSのエクスパイア3日は、大手ホストの中で唯一の警告です。
| リフレッシュZonemaster基準 ≥ 4 時間 · ◆ 1 日 | リトライZonemaster基準 ≥ 1 時間 · ◆ 2 時間 | エクスパイアZonemaster基準 ≥ 7 日 · ◆ 41.7 日 | ミニマムZonemaster基準 5 分～1 日 · ◆ 2 日 | ||
|---|---|---|---|---|---|
| Cloudflare | 2.8 時間 | 40 分 | 7 日 | 30 分 | 注意2件 |
| Amazon Route 53 | 2 時間 | 15 分 | 14 日 | 1 日 | 注意2件 |
| Google Cloud DNS | 6 時間 | 1 時間 | 3 日 | 5 分 | 警告1件 |
| Azure DNS | 1 時間 | 5 分 | 28 日 | 5 分 | 注意2件 |
| GoDaddy | 8 時間 | 2 時間 | 7 日 | 1 時間 | 合格 |
| Namecheap BasicDNS | 12 時間 | 1 時間 | 7 日 | 1 時間 | 合格 |
| google.com（自社の設定） | 15 分 | 15 分 | 30 分 | 1 分 | 警告1件 · 注意3件 |
Zonemasterの下限未満合格注意警告RIPE-203（1999年）
DNSSECの確認：DS、DNSKEY、署名
DNSSECの確認では信頼の連鎖をたどります：レジストリのDSレコードはゾーンにある鍵（DNSKEY）のダイジェストでなければならず、その鍵がゾーンの鍵セットに署名し、すべての署名（RRSIG）が検証に成功して、有効期間内になければなりません。このチェックはダイジェストを自ら計算して各署名を検証し、さらにGoogle Public DNSが検証に成功するかを問い合わせます。
連鎖のどこか1か所でも切れると、検証を行うリゾルバーはSERVFAILを返し、その背後の利用者全員からドメインが見えなくなります。意図的に壊したままにしてあるテストゾーンdnssec-failed.orgでは、2か所の破損が同時に見られます。アルゴリズムはIANAのレジストリ（RFC 9904）で判断します：8、13、15が推奨され、SHA-1で署名する5と7はもう使用してはならず（RFC 9905）、Zonemasterはエラーと評価します。
cloudflare.com検証成功
- .comのDS 2371アルゴリズム13 · SHA-256 · 329968…26F2B9
- ダイジェストが鍵2371と一致
- DNSKEY 2371 · KSKフラグ257 · ECDSA P-256 (13)
- 鍵セットに署名 · 61 日のうち残り50.8 日
- DNSKEY 34505 · ZSKフラグ256 · ECDSA P-256 (13)
- レコードに署名 · SOA：2 日のうち残り1 日
- Google Public DNSADフラグあり：検証成功
dnssec-failed.org検証失敗
- .orgのDS 42069アルゴリズム13 · SHA-256
- ゾーンに鍵42069がない
- DNSKEY 50719 · KSKゾーンの実際の鍵署名鍵
- 鍵セットへの署名は112 日前に期限切れ
- DNSKEY 32784 · ZSKSOAに署名：有効、7 日のうち残り5.7 日
- 信頼できるものが何も届かない
- Google Public DNSSERVFAIL、CDを立てると応答：検証失敗（bogus）
署名アルゴリズム（IANAレジストリ、RFC 9904）
- RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519これを使う
- MAY14 ECDSAP384SHA384 · 16 ED448使用可
- NOT RECOMMENDED10 RSASHA512ZonemasterではWARNING
- MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · ZonemasterではERROR
上の2つの連鎖はどちらも13で署名
メールのDNS：MX、SPF、DMARC
メールのチェックは、受信サーバーが読むものを読みます：MXレコード（またはドメインがメールを受け付けないことを示すnull MX、RFC 7505）、RFC 7208の上限であるDNSルックアップ10回以内に収まる1つのSPFレコード、そしてDMARCポリシー（2026年5月にRFC 7489を置き換えたRFC 9989）です。
SPFは見つけるだけでなく評価します：includeをすべてたどって数えます。github.comのレコードはちょうど10回のルックアップと1回のvoidルックアップを必要とし、有効ですが余裕はありません。メールを一切送らないドメインは、そのことを示すべきです：example.comは、パーキング用のセットとしてnull MX、v=spf1 -all、p=rejectを公開しています。詳しくは、SPFレコードチェッカーとDMARCチェッカーで確認できます。
github.com送受信する
example.comパーキング用のセット
コマンドラインでDNSとネームサーバーを確認する（dig）
digとdelvを使う4つの手順で、このチェックの中核を再現できます：ルートから委任をたどる、再帰オフで1台のネームサーバーに直接問い合わせる、レジストリのDSとゾーンの鍵を比較する、そして検証を行うリゾルバーに信頼の連鎖を判定させる、の4つです。
当サイトのサーバーと同じ条件で見るには+tcpを付けます。付けなければUDPをテストでき、これはCloudflareのネットワーク上のウェブツールにはできないことです。応答のヘッダーでは、aaが権威ある応答を示します。レジストリがリストするサーバーからのREFUSED、またはaaフラグのない応答は、レームデリゲーションです。
ターミナル · dig 9.20
$ dig +trace +tcp github.com NS ;; （省略） com. 172800 IN NS a.gtld-servers.net. ;; h.root-servers.netから 1 github.com. 172800 IN NS ns-520.awsdns-01.net. ;; h.gtld-servers.netから：NS 8件 2 $ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp ;; flags: qr aa; QUERY: 1, ANSWER: 1 3 github.com. 900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400 4 $ dig @a.gtld-servers.net github.com DS +norec ;; status: NOERROR, ANSWER: 0 ;; DSなし：未署名 5 $ delv @8.8.8.8 cloudflare.com SOA ; fully validated 6 cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com. 2417999975 10000 2400 604800 300
- ルートは.comをその13台のサーバーに案内します
- github.comに対するレジストリのNSセット。2日間保持されます
- aa：キャッシュではなく、権威ある応答
- SOA：シリアル1、続いてリフレッシュ、リトライ、エクスパイア、ミニマム
- .comにDSなし：DNSSECで検証するものはありません
- delvはルートからの信頼の連鎖を検証しました
DNSチェックツールで結果が食い違うのはなぜ？
基準にしている数値が違うからです。従来のチェッカーはプロバイダーのデフォルト値を指摘します：intoDNSはgoogle.comのエクスパイア1800秒を「NOT OK」とし、github.comの2つのシリアルをエラーにしますが、これは2つのDNSホストを使う場合には正常なことです。Zonemasterはシリアルを警告と評価し、null MXを認識します。当サイトの最初のバージョンは、そのどちらもできていませんでした。
また、ネットワークを見る場所も違います。Zonemaster（AFNICとスウェーデン・インターネット財団）はUDPとTCP、IPv4とIPv6で問い合わせます。このチェックはCloudflareのエッジで動いており、TCPでのみ問い合わせ、IPv6には接続せず、Cloudflare自身のアドレスにも接続できません。そのため、それらのサーバーは1.1.1.1経由で取得し、そのチェックは不合格ではなく未テストと表示します。intoDNSの代替ツールとして、単なるOKやNOT OKではなく、各レベルの根拠となる基準を示します。
| ケース | intoDNS | Zonemaster | DNS Robot v1 | このチェック |
|---|---|---|---|---|
| github.com2つのSOAシリアル（2つのDNSホスト） | エラー「Looks like your nameservers do not agree on the SOA serial.」 | 警告MULTIPLE_ | 不合格「Serial mismatch detected: 1656468023 vs 1.」 | 警告説明あり：DNSホストごとに1つのシリアル |
| google.comSOAのエクスパイア1,800秒 | NG「Your SOA EXPIRE number is: 1800. That is NOT OK」 | 警告EXPIRE_ | 不合格「too low (min recommended: 14 days)」 | 警告エクスパイアが影響する範囲を説明 |
| example.comnull MX（0 .） | エラー「0 No A Record (no glue either)」 | 情報Z09_ | 合格「Found 1 MX record(s)」 | 合格null MXを認識 |
| cloudflare.comSOAのリトライ2,400秒 | —引用なし | 注意RETRY_ | 不合格「too high (max recommended: 15min)」 | 注意Cloudflareのデフォルト値 |
| cloudflare.comDNSSECで署名済み | 未確認DNSSECのテストなし | 合格DNSSEC02 · 05 · 08：連鎖を検証 | 要注意「DNSSEC does not appear to be enabled for this domain.」 | 合格DS → KSK → RRSIGを検証、Googleも検証成功 |
