自分のDNSへの理解を整理する（「浸透」という用語）

「浸透」って仕組みがないっていう話だったよな。でもTwitterとかでも海外でもよく言ってるみたいだぜ。「浸透」がだめなら「反映」「伝搬」とか。

そうみたいですね。なぜそうかたくなに言い張るのかは私にはよくわからないのですが…

「浸透」類似の用例
更新データが有効になるまでの時間＝浸透待ち時間？
浸透（とは？）
1. だましたの？
2. 「浸透」と言いたいのはなぜ？
大事なことは何？

「浸透」類似の用例

例えばこれはどうなのよ？

世界規模でのDNSレコードのプロパゲーション期間

DNSサービス（ドメインネームシステム）| CloudflareマネージドDNS

CloudflareのマネージドDNSは、他のどのDNSプロバイダーよりも高速レスポンスを可能にします。他にない冗長性とセキュリティを組み込んでおり、DNSを瞬時に高速化します。

これはCloudFlare DNSというサービス内の話みたいですね。世界中にCloudflare DNS

の権威DNSサーバが配置されていて、このサービスに登録したリソースレコードがCloudflare DNS全体で同じ応答を返せるようになるまでの時間を「プロパゲーション」と言っているみたいですね。

じゃあこれは？

③TTL設定はDNSのキャッシュ保持期間となります。
短ければ短い程、短期間でDNSに設定内容が反映されます。

※変更がインターネット上に反映されるまで、5～30分程度かかる場合があります。

DNS情報・URL転送の設定 | バリュードメインユーザーガイド

ドメイン登録・取得代行や、レンタルサーバーなどのサービスを提供するバリュードメイン。このサイトは、ドメインやサーバーの操作・設定方法や、支払い手順などをまとめた総合マニュアルです。

これは書いてある時間の長さからして「リソースレコードのTTLを起因としたキャッシュ情報更新のタイミング」のことを言っているっぽいですね。直前の例示でTTLに「1200秒」、つまり20分が設定されていますので、さらに余裕をもたせて30分と言っているのだと思います。

ただ、「かかる場合があります」と条件などが示されない曖昧な表現になっているので、利用者からしたら「30分たっても更新した情報が参照されない。やはり【反映＝浸透】には時間がかかるのだ」という誤解を強化する元かもしれませんね。

ぐぬぬ…じゃあこれはどうだ！「浸透いうな」って言われないために書いてないだけだと思うけど、「数時間から72時間」とかまさに浸透に必要な時間じゃねーか！！

ご利用のレンタルサーバー業者様指定のネームサーバー(DNS)情報をドメインに設定していただきましたら、
数時間から72時間程度で、メールアドレスやホームページを利用が可能となります。

【ドメイン】ドメインの登録はいつ完了する？登録したドメインでメールアドレスやホームページが運用できるようになるまでの時間は？｜ヘルプ | ドメイン取るならお名前.com

国内最大級のドメイン登録サービス「お名前.com」のヘルプページでは、ドメインやサーバーのご利用方法について、よくあるご質問・ご利用ガイドをご案内しております。

こ、これは…！

これは…？

意味がわかりません。

…おいっ！

いや、ほんとに意味がよくわからないのです。

ご利用のレンタルサーバー業者様指定のネームサーバー(DNS)情報をドメインに設定していただきましたら、

ここは「契約者が利用するレンタルサーバー業者が指定したネームサーバー」と言っているので、おそらく「個人で権威DNSサーバを用意せず、レンタルサーバー業者が使わせてくれる権威DNSサーバー」のことだと思うのです。つまり、レンタルサーバー業者の管理画面から、委譲されたドメインの管理を行う環境を言っているのだと思います。

その場合、委譲元にはレンタルサーバー業者の権威DNSサーバーをこのドメインのネームサーバーとして使うのだと登録する必要があるので、そのための設定をレジストリである「お名前.com」に「設定」したら、という作業の話のようですね。

ネームサーバーの変更｜お名前.com Navi ガイド｜ドメイン取るならお名前.com

お名前.com Naviへのログイン方法やログインに必要なID・パスワードの再発行方法、ドメイン移管、DNSレコードの設定、レンタルサーバーの申し込みなど、各種手続き方法をご確認いただけます。

おう、それっぽいな。

ですが

数時間から72時間程度で、メールアドレスやホームページを利用が可能となります。

がわからないのです。ネームサーバーを「お名前.com」に登録するということは「レジストリ」に利用するネームサーバー情報を登録することになるはずなのですが、それと「メールアドレス」や「ホームページ」がどう関係するのかが情報が不足していて全くイメージできないのです。

更新データが有効になるまでの時間＝浸透待ち時間？

レジストリ、レジストラ目線

なんでよ、リソースレコード登録すれば使えるじゃん。

その「リソースレコード」はどこに登録するのですか？

えーっと、自分のドメインのネームサーバー、だっけ。

はい。では「ご自身が利用するネームサーバーに情報を登録する」ことと、「レジストリに登録してある委譲先となるネームサーバー情報を更新する」ことは同じでしょうか？

SQLで言えば

UPDATE delegate_from.delegate_info SET nameserver = 'new_server_address' WHERE domain_name = 'あなたのドメイン名';

と

INSERT INTO delegated.resource_records(domain_name, record_type, record_name, record_address) VALUES ('あなたのドメイン名', 'A', 'blog', '192.0.2.100');

のような動作です。

こんなんデータベースもテーブルも違うんだから、やってること違うに決まってんじゃん。

そうです。以前「分散データベース」というお話をしましたが、「どのデータベースの情報を更新」した結果を、リゾルバが「どのデータベースの情報を参照」するかによって、更新した内容が参照可能になるまでの時間というのは変わってくるのです。

委譲元に登録したネームサーバー情報の更新であれば

レジストラがレジストリに対して情報更新を行うまでの時間
レジストリが自身のネームサーバーに、委譲先ネームサーバー情報を反映するまでの時間
レジストリのゾーン情報や、委譲先ネームサーバー情報に設定されたTTLに基づき、フルリゾルバが以前アクセスしてキャッシュした情報の期限切れによる更新までの時間

が考えられます。例えば

$ dig +norec @a.gtld-servers.net twitter.com

; <<>> DiG 9.10.6 <<>> +norec @a.gtld-servers.net twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14399
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;twitter.com.			IN	A

;; AUTHORITY SECTION:
twitter.com.		172800	IN	NS	ns3.p34.dynect.net.
twitter.com.		172800	IN	NS	ns4.p34.dynect.net.
twitter.com.		172800	IN	NS	d01-01.ns.twtrdns.net.
twitter.com.		172800	IN	NS	d01-02.ns.twtrdns.net.
twitter.com.		172800	IN	NS	a.r06.twtrdns.net.
twitter.com.		172800	IN	NS	b.r06.twtrdns.net.
twitter.com.		172800	IN	NS	c.r06.twtrdns.net.
twitter.com.		172800	IN	NS	d.r06.twtrdns.net.

;; Query time: 240 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon May 10 11:34:02 JST 2021
;; MSG SIZE  rcvd: 211

だと、twitter.com の委譲先ネームサーバーのTTLは「172800秒（48時間）」なので、更新した情報が48時間参照できない場合はありえます。

ここに加えて、「レジストラがレジストリに対して情報更新を行う」までの、事務作業にかかる時間や更新タイミングなどの運営上の時間。これは事業者次第なのでかかる時間は不明です。

そして、「レジストリが自身のネームサーバー（a.gtld-servers.net など）に、委譲先ネームサーバー情報を反映する」時間もあるので、先程の48時間以上掛かる可能性は十分あります。

だからそれが「浸透時間」なんじゃねーの？

事務作業は「浸透」なのでしょうか？

また、特定の時間、例えば「レジストリに対して情報更新を行うのは、負荷軽減も考慮して毎時0分、1日24回とする」ような運用だった場合、この「毎時0分」になるのを待つのは「浸透」なのでしょうか？

ただ待ってるだけだったりするのを「浸透」っていうのは、まぁ違うかなぁ…

利用者目線

私もそう思います。

そして今度は利用者側が「ネームサーバーに必要なリソースレコードを登録」するまでの時間です。この作業をしていないと、委譲されたドメインのネームサーバーは「そんなリソースレコードは無い」という意味の「NXDOMAIN」という応答を返します。

$ dig +norec @ns3.p34.dynect.net. nxdomain.twitter.com

; <<>> DiG 9.10.6 <<>> +norec @ns3.p34.dynect.net. nxdomain.twitter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16286  ←ここの「status: NXDOMAIN」で「NXDOMAIN」応答が返ってきたことがわかる
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nxdomain.twitter.com.		IN	A

;; AUTHORITY SECTION:
twitter.com.		60	IN	SOA	ns1.p26.dynect.net. zone-admin.dyndns.com. 2007143982 3600 600 604800 60 ←ここの最後の「60（秒）」が「NXDOMAIN」応答のキャッシュTTL

;; Query time: 44 msec
;; SERVER: 208.78.71.34#53(208.78.71.34)
;; WHEN: Mon May 10 11:50:26 JST 2021
;; MSG SIZE  rcvd: 124

この応答もキャッシュされるので、ネームサーバーへのリソースレコード登録を後回しにしていると「NXDOMAIN」応答のキャッシュが消えるまで、正しくリソースレコードを登録しても応答が得られない、ということがおきます。

そうすると、

レジストラへの登録作業以降の部分はある程度予想できる。ただし、レジストラの作業完了までにどれだけ時間がかかるかによって変わってくる。
ネームサーバーへのリソースレコード登録前にその名前への問い合わせが発生すると、「NXDOMAIN」応答が問い合わせ元に返される。その場合NXDOMAINの応答がキャッシュされ、TTLもしくはフルリゾルバのキャッシュの扱いによって再度問い合わせをおこなって正しい情報を得られるまでの時間が変わってくる。

のように、名前解決が正常に行われるまでの時間には制御できないところがあることがわかってきます。

それってやっていいの？ vs. なんでやらないの？

ちょいまち。例えばブログ用のサーバが構築完了してないからまだいいやってリソースレコード登録するの後回しにするのって普通だと思うんだけど、構築前にネームサーバーに登録作業ってしていいわけ？

もちろんです。むしろなぜ後回しにするのか理解できません。

ブログ用のサーバが構築できていなければ、アクセスがあってもブラウザ上は

サーバーが応答しない
コンテンツが存在しない

のように見えるだけで、何も問題はありません。DNSの名前解決の観点では「委譲先のネームサーバーが、問い合わせに対して正しく応答できた」ことが重要であり、「サーバーが応答するかどうか」はその後の話です。

例えば引越しをするとして。

契約も済ませ住民として管理人にも把握してもらい、さらに部屋に表札も出しているが、実際はまだ引っ越しておらず誰もいないところに友人が訪ねてきた場合、「何だ留守か」ですみます。表札などでも事前情報でも正しい情報が得られているので問題はありません。

まぁ住んでるのわかってれば、また来ればいいよな。

はい。

しかし、契約のみ済ませたが引越し前だからとそれ以降の作業を放置していて管理人にも認知されていない場合、友人が訪ねてきた際に「そんな人ここには住んでないよ」と言われたらどうでしょう？

うーん、情報が間違ってんのかなって思うし、自分が間違った建物に来たんじゃねーかって考えもできるな。直接本人に聞けばすむけど。

そうですね、人間同士なら直接連絡取ればすみますが、DNSの仕組みでは「本人に直接聞く」はありえませんよね。ルートからたどっていく、もしくはフルリゾルバのキャッシュからの応答を利用するのどちらかです。

「そんな人ここには住んでないよ」と同様の「NXDOMAIN」がキャッシュされてしまったら、キャッシュ切れまで無駄に待たされることがありえますよね。

確かに。

逆に「正しく到達したけど、ドアホンの応答がない」のような場合は、正しく到達できているのでキャッシュ切れによる情報更新までの時間を待つ必要もないですよね。

おぅ…

ということで、「サーバが構築完了していない状況でも、正しい情報を先に登録しておく」ことが問題ない、むしろ必要そうだということはご理解いただけますか？

わかった。しても問題ないし、むしろしないほうが問題ありそうって話ね。

はい。これも「浸透」という存在しない仕組みを、それっぽく発生させている事例の1つです。

浸透（とは？）

なに？それっぽく発生させるてるって、浸透しないのって俺が原因なの？

それも1つです。もう1つは以前もお話した「ネームサーバーへの反復問い合わせによる確認作業ではなく、不用意なフルリゾルバへの再帰問い合わせを使った確認作業」によるものです。

まだ委譲元のネームサーバーに新規に取得した独自ドメインのネームサーバー情報が登録されていない、もしくは登録したリソースレコードについてネームサーバーがまだ応答を返せないような状況で再帰問い合わせを行うと、フルリゾルバに「NXDOMAIN」のようなエラー情報がキャッシュされてしまい、TTLが切れるまで名前解決ができないという事態に陥ってしまいます。

この場合

フルリゾルバはプロバイダや社内システムといった自身が管理できない範囲にあるため「キャッシュをクリアするために再起動する」といったことが気軽にできず、ただ待つしか無い
PCからのpingやブラウザのURLバーからのアクセスなどでの確認は簡単に誰でもできてしまうため、「アクセスできないなー」と何度も実行してしまい、エラー情報のキャッシュをいつまでも参照して文句を言うことになる
ネームサーバーが正しく応答を返せる状態で、エラー情報をキャッシュしていないフルリゾルバを経由した名前解決をすると「アクセスできる」となり、「自分のところではアクセスできないのに…」と環境の問題と勘違いする要因になる

のです。

は？環境要因じゃないの？

俺のPCではだめだったけどWi-Fi切ったスマホだったらOKとかお客様がやったらOKとかなったから、プロバイダの問題だって報告して「浸透に時間がかかるから環境によってアクセスできるまでの時間が違う」って補足情報も付けて承認されたんだけど。

あああ…

厳しい言葉で言えば、それは「浸透でだましきった」ということですね。

だましたの？

ちょっと！だましたとか人聞き悪いこと言うな！！

でも「浸透」という仕組みはない、ということはご理解いただいたのですよね？

そうだけど…

わかっていて「浸透」と言っているのですか？

いや、あれは前の話だから。

では今も「浸透」と言いたいですか？

「浸透」と言いたいのはなぜ？

いや、「浸透」は無いって話だろ？しかもだましたとか言われるんなら別の言葉使えばよくね？

「反映」とか「伝搬」とか、横文字で「プロパゲーション」とか。

なにをどこに反映するのですか？

もしくは何がどこに伝搬するのですか？

反映するのはリソースレコードをネームサーバーに。

伝搬は…伝わってないから違うか。問い合わせ？うーん…

「伝搬」は不自然ですね。なしにしましょうか。

「反映」はネームサーバーに、ということであれば「データベースの情報を更新したらキャッシュではなくデータベースを確認する」のが筋ではないですか？

せやな。

ではデータベースを確認するのが筋であれば、DNSの場合はどこを確認するのですか？

ネームサーバー

ネームサーバーに登録したリソースレコードが参照可能かを確認するには何を使えばよいのでしょう？

ルートからの反復問い合わせ

そうですね、もしくはリソースレコードを登録したネームサーバーに直接問い合わせるのでもOKです。では「反映」と「ルートからの反復問い合わせ」は同じことを言っているのでしょうか？

違うな…INSERT/UPDATEと、SELECT多段の副問合せって感じ。

副問合せを使った複雑な条件指定

前回はデータのレポート化や集計に役立つ便利な構文を紹介しました。今回は、複雑な条件を指定したい場合に役立つ「副問合せ」を紹介します（編集部）

そうですね、データベース的な見方をすれば「副問合せ」は似てますね。

結局「浸透」を言い換えるというのは「存在しない事象や仕組みを、言葉上でそれっぽく取りつくろおうとしている」ということの証拠でしか無いのです。

ですので、なんとかして「浸透」やその類似の用語を使いたいというのはある意味「【DNS浸透】の信者」であり「幽霊は存在する！」や「これは陰謀だ！俺だけがわかっている！」のようなことを言うのと同じレベルなのです…

ふざけんな！おれそんな痛いやつじゃねーし！

ですよねぇ。であればなぜ「浸透」と言いたがったり、「浸透以外の用語」を必要としたりするのでしょうか…教えていただけませんか？

そりゃ…説明しやすいから…

誰に何を説明するのですか？

お客さんやユーザーに、浸透しない理由を。

「浸透」は存在しないのですよね。具体的には何を説明するのですか？

え、ドメインにアクセスできないときに、その理由を。

「アクセスできない」のはどうやって確認したのですか？

少し前に言及しましたが、「不用意な再帰問い合わせ」はいわゆる「浸透しない」の要因の1つとお話しましたが、どうでしょう？

…した

？

したっていってんだろおおおおお！ブラウザでアクセスしたんだよおおおおお！digとか反復問い合わせとか誰も教えてくれなかったんだよおおおおおおおおおお！！！！！！

俺がトラブってるときにお客さんが自宅からアクセスしたらOKだって言われたから、報告するとき浸透以外いえないって話になったんだよ！！！！

なるほど…辛い環境だったのですね。誰も教えてくれない、正しい確認手順も存在しない、説明できないから「浸透」というしかないと。

そうだよ！悪いか！

おれはユーザー説明しやすいから「浸透」って言いたいんだよ！

なるほど…もしかして、使いたい言葉を「いうな」って言われるから反発しているのですか？

大事なことは何？

うっせ！お客さんが納得するのが大事なんだよ！！

時間も大事なんだよ！そんな「なんとか問い合わせ」とか説明してわかってもらえるなら苦労しねー！

そうですか…これこそ「個々の環境」なので私にはこれ以上のことは言えませんが

もしお客様が「浸透いうな」に理解がある場合、あなたが「だましている or 技術力が低い」ことを看破されることになるのではないでしょうか。それは「信用を下げる」行為だと思うのですが…
注意すべき点を踏まえて「正しい確認方法」を知り、実行するのはそんなに難しいことでしょうか。正しく確認できていれば「浸透待ち」は起きないですし、起きた場合でも原因が特定できるので説得力のある報告ができると思うのですが…
それほど「浸透」ということにメリットがあるのでしょうか？「浸透言うな」と言ってもらうのが嬉しい、とかならわからなくも無いのですが…