要約

  • DNSOP working-group draft は、単独の空 NS target で child zone の境界だけを公開し、利用可能な public authoritative server は示さない方式を提案する。
  • roaming device が public 側で得た authenticated denial を private namespace にまで持ち込み、内部の正答を bogus と扱う衝突を減らす狙いがある。
  • 親の表明、resolver が見た referral、private path、child authority、DNSSEC validation、application outcome は独立して確認しなければならない。

delegation を二つの主張に分解する

通常の delegation は、「ここから child zone が始まる」と「その child はこの server にある」を一つの RRSet で結ぶ。split DNS では前半だけが真になることがある。example.com は global DNS にあり、corp.example.com は社内 resolver からしか見えない。public parent は境界を知っていても、外部から使える server を持たない。

DNSOP working-group draft の revision 00 は、その状態を一つだけの empty NSDNAME で表す。CORP 3600 IN NS-dot は、child の不存在ではなく、parent namespace から利用できる authoritative server がないことを示す。通常の NS target と空 target を同じ RRSet に混ぜた構成は対象外である。形を厳密に限定するからこそ、空値が曖昧な wildcard にならない。

DNS には同じ発想の先例がある。Null MX は mail を受け取らないこと、SRV の dot target は service が明確に利用できないこと、AliasMode SVCB の empty target は service の不存在または利用不能を表す。ただし先例は新しい NS 規約の普及を証明しない。示すのは、能力がないと正直に書く設計が protocol に馴染むということだけだ。

cache が持ち越すのは答えだけではない

mobile device が社外にいる間、内部名らしい query を global DNS に送ると、DNSSEC-aware resolver は signed negative response を cache できる。その後社内 network に移り、internal authority が positive answer を返しても、先に得た否定を全 namespace の事実と誤認すれば、新しい回答を bogus と扱い得る。

zone cut to nowhere は public 側の主張を狭める。親は「下に何もない」とは言わず、「別 namespace に child boundary があるが、この path では server を示さない」と返す。特別な resolver 処理は不要で、到達不能な nameserver を持つ referral と同様に resolution は止まる。

外部で失敗すること自体は設計どおりである。重要なのは failure reason だ。NXDOMAIN と private boundary は、現在の public query では同じく service に届かなくても、network を移った後の cache と authority の意味が異なる。

設定、観測、到達、検証を別々に残す

最初の証拠は parent configuration である。管理者が singleton empty-target NS を置いた。DNSSEC が付けば、signed parent がそれを公開したという二番目の証拠になる。しかし、どちらも private nameserver の identity や稼働を証明しない。

三番目は resolver の observation だ。ある時刻に referral を受け、特定の TTL と validation state で cache した。stale cache や中間装置によって、zone file と実際の応答はずれ得る。

四番目は private network へ移った後の resolver selection である。端末が child に到達できる internal resolver または forwarding policy を選んだか。public の empty target はその path を発見せず、access を許可もしない。

五番目が child answer と validation、六番目が application use である。private authority は停止、mis-sign、view divergence を起こし得る。lookup が成功しても application が使わない場合がある。したがって empty-target NS の deployment count を private service health に転用してはならない。

DS は trust path を補えるが network path ではない

parent が child signing key を知る場合、draft は DS と empty-target NS を並べる secure delegation to nowhere を許す。後に private namespace で signed child response を得た resolver は、親からの trust relation を使える可能性がある。

ただし、複数の private view が異なる key を用いる、または unsigned view を含むなら、一つの DS は共通 authority を表せない。revision 00 はその場合 secure delegation を使わないよう求める。DS の配置は単なる hardening ではなく、親がどの child identity を承認するかという authority decision である。

DS は reachability を作らない。resolver discovery、network admission、child availability、application success は依然として別の control surface にある。

document status を運用実績に変換しない

revision 00 は 2026 年 9 月 23 日付の active Standards Track Internet-Draft であり、RFC でも final IETF consensus でもない。root に INTERNAL と empty-target NS を置く例は意図的な説明で、IANA への operational direction ではない。

draft は実験結果が広範な operational problem を示さなかったと述べる一方、software の incompatible assumption や root traffic の懸念も記す。ここから得られるのは検証課題であって、全 implementation の compatibility receipt ではない。

また、普段は private な child の下に ACME DNS-01 用 TXT を一時的に public 公開する構成は、この clean model をそのまま使えない。例外を隠した minimal specification は、最小でも正確でもない。

出典