NXDOMAIN（Non-Existent Domain）
概要
NXDOMAIN（Non-Existent Domain） は、DNS クエリで問い合わせたドメイン名が存在しないことを示すレスポンスコード（RCODE = 3）です。RFC 1035（1987年）で RCODE として定義され、RFC 2308（1998年）でネガティブキャッシュの対象として扱いが規定されています。
再帰リゾルバーは NXDOMAIN 応答を受け取ると、SOA レコードの MINIMUM フィールドと SOA TTL の小さい方を期間として「このドメインは存在しない」という結果をキャッシュします。同じドメインへの再問い合わせがあれば、権威サーバーに問い合わせずにキャッシュから NXDOMAIN を返します。このネガティブキャッシュが、ドメインを新規作成した直後に「ドメインが見つからない」と報告される原因になります。
一部の ISP やパブリック DNS は NXDOMAIN 応答を独自のページにリダイレクトする（NXDOMAIN Rewriting）挙動があり、DNSSEC 検証で検知可能な仕様違反です。
仕組み
NXDOMAIN は DNS の応答コードの一つで、クエリの対象となるドメイン名がどのレコードタイプでも存在しないことを権威サーバーが通知する仕組みです。
RCODE の一覧
DNS の応答コード（RCODE）は 4 ビットのフィールドで表現され、RFC 1035 で次の値が定義されています。
| RCODE | 名称 | 意味 |
|---|---|---|
| 0 | NOERROR | 問い合わせ成功 |
| 1 | FORMERR | フォーマットエラー |
| 2 | SERVFAIL | サーバー障害 |
| 3 | NXDOMAIN | ドメインが存在しない |
| 5 | REFUSED | 問い合わせを拒否 |
NXDOMAIN（RCODE 3）は「ドメイン名そのものがゾーンに存在しない」ことを意味します。同じドメインの別レコードタイプ（A、MX、TXT など）を問い合わせても同じ NXDOMAIN が返ります。
NXDOMAIN と NODATA の違い
NXDOMAIN と混同されやすい応答に NODATA があります。NODATA は独立した RCODE ではなく、RCODE = 0（NOERROR）かつ ANSWER SECTION が空の応答として表現されます。
NXDOMAIN は「ドメイン自体が存在しない」ことを示します。nonexistent.example.com に A レコードを問い合わせて NXDOMAIN が返った場合、このドメインには MX レコードも TXT レコードも存在しません。
NODATA は「ドメインは存在するが、リクエストされたレコードタイプが存在しない」ことを示します。example.com に AAAA レコードを問い合わせて NODATA が返った場合、このドメインの A レコードや MX レコードは存在する可能性があります。
# NXDOMAIN の例
dig A nonexistent.example.com# → status: NXDOMAIN# NODATA の例
dig AAAA example.com# → status: NOERROR, ANSWER SECTION が空ネガティブキャッシュとの関係
再帰リゾルバーが NXDOMAIN を受け取ると、そのドメインが存在しないという事実をキャッシュします。キャッシュの保持期間は、NXDOMAIN 応答の AUTHORITY SECTION に含まれる SOA レコードの情報から決定します。
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345
;; AUTHORITY SECTION:
example.com. 300 IN SOA ns1.example.com. admin.example.com. (
2024010101 3600 900 604800 300 )RFC 2308 はネガティブキャッシュの TTL を「SOA の MINIMUM フィールドと SOA TTL の小さい方」と定めています。上記の例では SOA TTL が 300 秒、MINIMUM が 300 秒のため、ネガティブキャッシュの保持期間は 300 秒です。
設定例
NXDOMAIN そのものを「設定」する項目ではありませんが、ネガティブキャッシュの期間を制御する SOA レコードの MINIMUM フィールドの設定例を示します。
短いネガティブ TTL（推奨）
; ネガティブ TTL を 300 秒（5 分）に設定
example.com. 3600 IN SOA ns1.example.com. admin.example.com. (
2024010101 3600 900 604800 300 )新しいサブドメインを頻繁に追加する環境では 300〜600 秒 が推奨値です。ネガティブキャッシュが短時間で切れるため、新しいレコードの追加後に NXDOMAIN のキャッシュが原因で「反映されない」状態が長引きません。
長いネガティブ TTL
; ネガティブ TTL を 3600 秒（1 時間）に設定
example.com. 3600 IN SOA ns1.example.com. admin.example.com. (
2024010101 3600 900 604800 3600 )サブドメインの追加がほぼ発生せず、存在しないドメインへのクエリが大量にある場合は長めに設定します。権威サーバーの負荷を減らす効果がありますが、ネガティブキャッシュが切れるまで最大 1 時間は新しいサブドメインが見つかりません。
確認方法
dig で存在しないドメインを問い合わせると NXDOMAIN 応答を確認できます。
dig A nonexistent.example.com;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345
;; QUESTION SECTION:
;nonexistent.example.com. IN A
;; AUTHORITY SECTION:
example.com. 300 IN SOA ns1.example.com. admin.example.com. (
2024010101 3600 900 604800 300 )status: NXDOMAIN がドメインが存在しないことを示しています。AUTHORITY SECTION の SOA レコードの最後のフィールド（300）が MINIMUM で、ネガティブキャッシュの保持期間の候補です。
SOA レコードのフィールドを直接確認するには次のコマンドを使います。
dig SOA example.com特定のリゾルバーのキャッシュを確認するには @ でサーバーを指定します。
dig A nonexistent.example.com @8.8.8.8外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、Cloudflare ネットワーク越しに見た結果を取得できます。
curl "https://labee.dev/api/dns?domain=example.com&type=SOA,A"{
"success": true,
"data": {
"domain": "example.com",
"records": {
"SOA": [
{
"mname": "ns1.example.com",
"rname": "admin.example.com",
"serial": 2024010101,
"refresh": 3600,
"retry": 900,
"expire": 604800,
"minimum": 300
}
],
"A": [
{ "address": "203.0.113.1", "ttl": 300 }
]
}
},
"error": null,
"meta": { "responseTime": 42 }
}SOA.minimum フィールドの値がネガティブキャッシュ TTL の候補です。存在しないドメインを問い合わせた場合、API 側では A レコードが空となり、SOA レコードの minimum からネガティブキャッシュ期間を推測できます。
よくある問題
NXDOMAIN に関連するトラブルは、ネガティブキャッシュの遅延、ISP によるリダイレクト、ワイルドカードドメインとの干渉に集約されます。
新しいサブドメインを作ったのに見つからない
新しいサブドメインを追加する前にそのドメインを問い合わせてしまうと、NXDOMAIN がネガティブキャッシュに記録されます。SOA の MINIMUM が 3600 秒の場合、最大 1 時間は「存在しない」とキャッシュされ続けます。
OS の DNS キャッシュをフラッシュするか、dig @8.8.8.8 のように別のリゾルバーを使うか、ネガティブキャッシュの TTL が切れるまで待つかのいずれかで解決します。頻繁にサブドメインを追加する環境では、MINIMUM を 300 秒 程度に設定しておくと影響を最小化できます。
ISP が NXDOMAIN をリダイレクトしている
一部の ISP やパブリック DNS は、NXDOMAIN 応答を独自の検索ページや広告ページにリダイレクトします。NXDOMAIN Rewriting と呼ばれるこの挙動は、RFC 1034 と RFC 2308 の仕様に反しています。リダイレクトにより架空の A レコードが返るため、アプリケーションが「ドメインが存在しない」と判定できなくなります。
DNSSEC 検証を有効にしたリゾルバーを使うと、NXDOMAIN の改ざんを検知できます。DNSSEC に対応していないリゾルバーを使っている場合は、Google Public DNS（8.8.8.8）や Cloudflare DNS（1.1.1.1）に変更することで NXDOMAIN Rewriting を回避できます。
ワイルドカードレコードが NXDOMAIN を隠している
*.example.com のようなワイルドカードレコードが設定されていると、存在しないサブドメインへの問い合わせが NXDOMAIN ではなくワイルドカードのレコードを返します。セキュリティ上の理由で存在しないドメインを NXDOMAIN で区別したい場合は、ワイルドカードを使わずに必要なサブドメインだけを個別に設定します。
DNSSEC 検証で NXDOMAIN が SERVFAIL になる
DNSSEC が有効なドメインで NXDOMAIN 応答が正当なものであることを証明するため、権威サーバーは NSEC レコードで「存在しないこと」を署名します。この署名が検証できない場合（ゾーンの鍵更新漏れ等）、再帰リゾルバーは NXDOMAIN の代わりに SERVFAIL を返します。DNSSEC の運用で NSEC レコードの署名が期限切れになると、存在しないドメインへの問い合わせが全て SERVFAIL になります。