NTTが貸し出しているﾙｰﾀなどで､ntt.setupという架空のﾄﾞﾒｲﾝを自分自身のWebUIに向けていることがありますが､あれはどういう仕組みですか｡ｸﾗｲｱﾝﾄからの名前…

NTTが貸し出しているﾙｰﾀなどで､ntt.setupという架空のﾄﾞﾒｲﾝを自分自身のWebUIに向けていることがありますが､あれはどういう仕組みですか｡
ｸﾗｲｱﾝﾄからの名前解決が来たときに自分自身のIPを応えているのかな､とか想像はできますが､それがどういう技術に則って行われているのか想像がつきません｡
RFCにそのような技術についての記載があるのであれば､その番号も教えてください｡

その環境で､nslookup した結果を載せている人がいました｡

C:\prg\test\java\RegExp>nslookup
Default Server: ntt.setup
Address: 192.168.1.1
...
竹形誠司ﾌﾞﾛｸﾞ:Mac mini ｻｰﾊﾞｰ化計画:DNSの設定がなかなか反映されない場合のﾁｪｯｸﾎﾟｲﾝﾄ(ﾒﾓ)

こういう環境だと､ｸﾗｲｱﾝﾄの IP ｱﾄﾞﾚｽは自動割り当て (DHCP) にしているはずで､DNS ｻｰﾊﾞも自動割り当てになっています｡
DHCP ｻｰﾊﾞと DNS ｻｰﾊﾞは､ﾙｰﾀが兼ねてます｡
DNS ｻｰﾊﾞ (ﾙｰﾀ) が､ntt.setup というﾄﾞﾒｲﾝがが自身を指している､というふうになっています｡

技術的には､普通の DNS です｡

DNS にからむ RFC は､こんなにあります｡
https://www.isc.org/community/rfcs/dns/

敢えて､どれ､って選ぶとしたら､RFC 1034 と RFC 1035 の二つでしょうか｡

NTTのﾙｰﾀｰがDNSﾌﾟﾛｷｼ(上位DNSへの転送)やってると思いますが､そこで独自ﾄﾞﾒｲﾝを定義してるだけです｡
(定義されていない大部分のﾄﾞﾒｲﾝは上位DNSへﾌｫﾜｰﾄﾞって風)

Windowsﾄﾞﾒｲﾝの中に置くDNSも全く一緒のことやってます｡

仕組みとしては ntt.setup じゃなくて microsoft.com とｱｸｾｽされたときﾙｰﾀｰの管理画面に飛ばすようにも出来ます｡

RFCは解決方法を提示しているだけで､ﾄﾞﾒｲﾝ名はNICの管轄｡
具体的なﾄﾞﾒｲﾝ名が実在ぽいものなのか架空なのか､そんなことはRFC的にはどうでもいいことです｡

NTTのﾙｰﾀｰに BIND が入ってるのか Unbound 的なﾌﾟﾛｷｼ向けDNSが入ってるか分かりませんが､RFCの番号的には､

ﾌﾟﾗｲﾏﾘDNSｻｰﾊﾞｰにおける正引き
ﾌｫﾜｰﾀﾞの定義に関する部分

その辺が該当になるかと｡

たぶんDHCPで使われてると思いますが､ﾊﾟｿｺﾝのﾈｯﾄﾜｰｸ設定で参照DNSｻｰﾊﾞｰを｢DHCPから自動取得｣でなく｢8.8.8.8｣等にしてみると ntt.setup は使えなくなると思います｡
(NTTのﾙｰﾀｰをDNSに指定しているときだけしか使えないﾄﾞﾒｲﾝ)

手前味噌で申し訳ないですが､NTTﾙｰﾀｰ内のDNSがやってることと同じ技術(手法)を使って､自前で宅内DNSｻｰﾊﾞｰを建てて迷惑ｻｲﾄをﾌｨﾙﾀｰﾘﾝｸﾞするDNSｻｰﾊﾞｰの構築についてﾌﾞﾛｸﾞで書いたことがあります｡

Raspberry PI + Raspbian + Unbound 自分ﾒﾓ
http://d.hatena.ne.jp/wakwak_koba/20150211

自分で定義したﾄﾞﾒｲﾝ名(ﾎｽﾄ名)の正引きを自分のDNSｻｰﾊﾞｰで行い､自力で解決できないものを上位に問い合わせる､みたいなことを Unbound 使ってやってます｡
もし Unbound 使うんであれば､ﾙｰﾀｰが 192.168.1.1 だと仮定して

local-data:"ntt.setup 86400 IN A 192.168.1.1"

追加するだけです｡