HungaryのDNS浸透チェッカー
Hungaryにある6台のリゾルバー(Budapest · Budapest · Gödöllő · Budapest · Bugyi · Budapest)に対してDNSルックアップを実行します。
- 解決済み
- 応答なし
- チェック中
-
Budapest Hungary —
-
Budapest Hungary —
-
Gödöllő Hungary —
-
Budapest Hungary —
-
Bugyi Hungary —
-
Budapest Hungary —
HungaryからDNSを確認するとわかること
DNSリゾルバーは、各レコードのキャッシュをTTL(有効期間)が許すあいだ保持します。しかもこれは場所ごとに別々に行われます。そのため、すでに公開済みの変更があるリゾルバーには反映されている一方で、別のリゾルバーはまだ古い答えを返し続けている、ということが起こります。
Hungaryからの確認では、その国の中にあるサーバーでレコードを引くため、別の大陸のリゾルバーがたまたま返す内容ではなく、現地の人々が実際に受け取っている内容がわかります。
これが最も重要になるのは、レコードを編集した直後です。8.8.8.8のようなグローバルなリゾルバーでは見えている更新が、HungaryのローカルISPではキャッシュが切れるまで古いままのことがあります。Hungaryのサーバーに対して確認を実行すれば、現地の訪問者が頼っているリゾルバーに新しい値が届いたかどうかがわかります。移行やメールの切り替えが効くのを待っているとき、本当に知りたいのはこの答えです。
Some answers from Hungarian ISP resolvers are shaped by state blocking: domains on the NMHH-run KEHTA list, chiefly unlicensed gambling sites ordered blocked by the SZTFH, return NXDOMAIN or a notice page instead of their real records.
DNS浸透(伝播)の仕組み
すべてのDNSレコードにはTTL(time-to-live)が設定されています。これは、リゾルバーが再度問い合わせるまでにキャッシュした答えを保持してよい秒数です。レコードを変更しても、古い値を持っているリゾルバーはそのタイマーが切れるまで古い値を返し続け、切れて初めて新しい値を取得します。
「浸透」とは、この期限切れが多数の独立したリゾルバーでばらばらに起こっていく過程にすぎません。だからこそ、変更前にTTLを下げておけば反映が早まります。決まった待ち時間はなく、古い答えがどれだけ残るかはレコード自身のTTLが決めます。
よくある質問
なぜHungaryのDNSサーバーは8.8.8.8と違う結果を返すのですか?
原因は2つあります。まず、各リゾルバーは独立してキャッシュするため、あるリゾルバーが別のリゾルバーより古い答えを保持していることがあります。
次に、CDN(コンテンツ配信ネットワーク)は問い合わせ元リゾルバーの場所に応じて応答し、Hungaryのリゾルバーを近くのエッジノードに誘導します。
どちらの答えも、それぞれの場所にとっては同時に正しいことがあります。
DNSの変更がHungaryで見えるようになるまでどのくらいかかりますか?
それは国ではなく、レコードのTTLで決まります。
Hungaryのリゾルバーはキャッシュが切れるまで以前の答えを保持し、その後で新しい答えを取得します。
変更前にTTLを下げておけば早く反映されます。
そうでなければ、元のタイマーが切れるまで古い値が残ることがあります。
HungaryのユーザーはどのDNSサーバーを使うべきですか?
ほとんどの人にとっては、プロバイダーが割り当てるリゾルバーで問題なく、たいてい遅延も最小です。
別の選択肢が欲しい場合は、Hungaryから到達できるパブリックリゾルバー、たとえばCloudflare(1.1.1.1)やGoogle(8.8.8.8)を指定できます。
速度・プライバシー・フィルタリングのどれを重視するかで、適切な選択は変わります。
なぜわざわざHungaryからDNSを確認するのですか?
Hungaryの訪問者が実際に解決している内容がわかるからです。
これはグローバルなルックアップとは異なる場合があります。
オーディエンスがHungaryにいる場合や、ホスティングやメールをそこへ移した場合、国内のリゾルバーに対して確認すれば、それらのユーザーが頼るサーバーにレコードが届いたことを確かめられます。