「dig NS example.com が何も返さない」「whois を叩いても空白のまま」「ドメインを移管したはずなのに、委任されているのか判断できない」——ドメインの委任状況を確認しようとして、こうした沈黙に困った経験はないでしょうか。
原因の多くは、ネットワーク環境側でUDPのDNSクエリが横取り（リダイレクトまたは遮断）されていることにあります。この記事では、UDPが信用できない環境でも、HTTPS経由のDNS（DoH）と権威サーバーへの直接問い合わせを組み合わせて、委任状況を確定させる手順を解説します。
この記事でわかること。
- なぜ
digやwhoisが空を返すのか - DoHで横取りを回避して名前解決する方法
- 親（TLD）サーバー・委任先サーバーに直接問い合わせて委任状態を特定する方法
- 3つの結果を組み合わせて「どちら側の作業待ちか」を1回で判定する考え方
-
dig +short NS <domain> @8.8.8.8 や whois が無言で空を返しても「未登録」と即断しない - HTTPS経由のDoH（
dns.google や cloudflare-dns.com）ならUDP横取りの影響を受けずに名前解決できる - 親（TLD）サーバーへ
+tcp +norecurse で直接問い合わせると「委任されているか」の一次情報が取れる - 委任先サーバーに直接聞いてREFUSED・NXDOMAIN・正常応答のどれが返るかで、作業待ちがどちら側かを特定できる
目次を開く
なぜ dig や whois が空を返すのか
UDPポート53のDNSクエリは、ネットワーク環境（ISP、社内プロキシ、公衆Wi-Fiなど）によっては透過的に横取り・改変・破棄されることがあります。この場合、dig +short NS example.com @8.8.8.8 のように問い合わせ先を明示的に指定しても、実際のパケットは別の場所へリダイレクトされたり応答が握りつぶされたりして、コマンドは黙って空の結果を返します。エラーメッセージが出ないため、「ドメインが存在しない」「まだ登録されていない」と誤読しやすいのが厄介な点です。
whois も同じく、多くの実装がバックグラウンドでUDP/TCPの問い合わせに依存しているため、同じ環境では同じように沈黙します。
この状態を疑うべきサインは次の通りです。
- 既に登録・稼働していると分かっているドメインで
digwhoisが軒並み空を返す - 同じコマンドを別のネットワーク（テザリング等）から叩くと正常に返る
- ブラウザでは名前解決できているのに、CLIツールだけ反応がない
HTTPSで迂回する（DoH）
DNS over HTTPS（DoH）は名前解決をHTTPS上で行うため、UDPの横取りの影響を受けません。パブリックなDoHエンドポイントに対して curl で直接問い合わせます。
# Google Public DNS のDoH
curl -s "https://dns.google/resolve?name=example.com&type=NS" \
| jq -c '{Status, Answer:(.Answer//[]|map(.data)), Authority:(.Authority//[]|map(.data))}'
# Cloudflare のDoH（JSON形式を明示）
curl -s -H 'accept: application/dns-json' \
"https://cloudflare-dns.com/dns-query?name=example.com&type=NS" レスポンスの Status フィールドが判定の核です。
| Status | 意味 |
|---|---|
| 0 | 正常応答。ドメインは存在し、NSレコードが引ける |
| 2 | SERVFAIL。権威サーバー側で応答不能（設定不備の可能性） |
| 3 | NXDOMAIN。ドメインが存在しない（未登録、または誤字） |
親（TLD）サーバーに直接問い合わせる
DoHで正常応答が返っても、「実際に委任先として設定されているNS」を確認するには、TLDを管理する親サーバーに直接聞くのが一次情報です。再帰的な問い合わせを頼まず、委任情報だけを取得します。
# .com の場合の例（TLDサーバーは事前にNSレコードで調べておく）
dig +tcp +norecurse NS example.com @a.gtld-servers.net-
+tcp: UDPの横取りを避けるためTCPで問い合わせる -
+norecurse: 親サーバーに再帰的な解決を頼まず、委任情報のみを見る
ここで委任先NSが返ってくれば、レジストラ側の設定（ドメインの委任）は完了していると確定できます。何も返らなければ、委任自体がまだ反映されていません。
委任先のNSに直接聞いて、受け皿側の状態を見る
親サーバーから委任先NSが分かったら、そのNSに直接クエリを投げます。
dig +tcp NS example.com @ns1.example-dns-provider.com応答の内容で、委任先側の状態を切り分けられます。
| 応答 | 意味 |
|---|---|
| 正常にNSやAレコードが返る | 委任・受け皿ゾーンともに設定完了 |
| REFUSED | 委任は届いているが、委任先でそのドメインのゾーンがまだ作成されていない |
| タイムアウト・無応答 | 委任先NS自体に到達できない（NSの指定ミスの可能性） |
3点を組み合わせて判定する
DoH・親サーバー・委任先NSの3つの結果を並べると、「どちらの作業待ちか」を1回の確認で決められます。
| DoH（Status） | 親サーバー | 委任先NS | 判定 |
|---|---|---|---|
| 0（正常） | 委任先NSが返る | 正常応答 | 設定完了。反映待ちのみ |
| 2（SERVFAIL） | 委任先NSが返る | REFUSED | レジストラ側の委任は完了。委任先でのゾーン作成待ち |
| 3（NXDOMAIN） | 何も返らない | — | ドメイン自体が未登録、または委任がまだ反映されていない |
この組み合わせが分かれば、相手（レジストラやDNSプロバイダ）に「設定されていますか」と往復して確認する手間が省けます。
まとめ
-
digやwhoisが無言で空を返しても「未登録」と即断しない。UDPが横取りされる環境を疑う - DoH（
dns.google/cloudflare-dns.com）ならHTTPS経由でUDP横取りの影響を受けずに名前解決できる - 親（TLD）サーバーへ
+tcp +norecurseで直接問い合わせると、委任済みかどうかの一次情報が取れる - 委任先NSに直接聞いてREFUSED・NXDOMAIN・正常応答のどれが返るかで、作業待ちがどちら側かを特定できる
よくある質問（FAQ）
Q. dig +short NS example.com @8.8.8.8 のようにサーバーを明示しているのに、なぜ横取りされるのですか？
A. @8.8.8.8 はUDPの宛先アドレスを指定しているだけで、実際にそのパケットがネットワーク経路上で改変・リダイレクトされることを防ぐ機構ではありません。透過的なDNSフィルタリングやリダイレクトは、宛先を指定していても発生します。HTTPS経由のDoHであれば通信自体が暗号化されたHTTPSのやり取りになるため、この種の横取りを回避できます。
Q. TLDサーバー（a.gtld-servers.net など）のアドレスはどうやって調べますか？
A. まずルートサーバーやレジストリの公開情報から対象TLDのネームサーバー一覧を確認します。.com / .net の場合は gtld-servers.net（a〜m）が使われています。DoHで type=NS の Authority フィールドを見ると、権威側のネームサーバー名がヒントとして得られる場合もあります。
Q. REFUSEDが返ったら、こちらで直せますか？
A. REFUSEDは委任先のDNSプロバイダ側でそのドメイン用のゾーン（受け皿）がまだ作成されていない状態を示します。委任（NSの設定）自体はレジストラ側で完了しているため、DNSプロバイダの管理画面でゾーンを作成すれば解消します。
Q. 社内ネットワークやVPN配下でも同じ手順は使えますか？
A. 使えます。ただしプロキシ環境によってはHTTPS通信自体もプロキシを経由するため、DoHの curl コマンドがプロキシ設定（https_proxy 環境変数など）を必要とする場合があります。手元の環境の curl -v で接続先を確認してから進めてください。
