DNSの変更が反映されない

質問

DNSを変更しましたが、会社からの接続に反映されません。

・会社の中からnslookupを実行すると、変更前のアドレスが返ります
・スマホからホームページにアクセスすると、変更後のページが表示されます
・下記サイトからnslookupを実行すると、変更後のアドレスが返ります
　https://www.cman.jp/network/support/nslookup.html

上記のような感じで、会社の中からの接続だけ変更されていないようです。
nslookupは、DNSサーバーを指定しない場合も、ルーターに設定しているのと同じ
プロバイダのDNSサーバーを指定した場合も、同じ結果です。
一応、ルーターの電源を入れなおしてみましたが改善されません。

何か分かる方がいましたら、助けてください。
お願いします。

回答No.10

superside0 · ベストアンサー

> ** server can't find xxxxx.co.jp: REFUSED
> と表示されていました。
>昨日、自宅からコマンドプロンプトにてnslookupを実行した際も
>同じように、「見つからない」となりました。

具体的なプロバイダ名がわからないので、確定ではないですが、
一般的には、プロバイダのDNSは、プロバイダ以外のネットワークからは
利用することはできないようにされていることが多いです。
（allow-query設定で自社ネットワークのみからの利用に限定されています）
（プロバイダのDNSが、独自ドメインの権威DNSとしても
　公開しているゾーンがあるなら、それだけは例外ですが）

よって、refusedとなってしまうというのは、それで正常です。

結局、
社外からならプロバイダのDNSへの問い合わせは正常なIPアドレスを返すのに
同じDNSに社内からの問い合わせすると異常というのは誤りだった
ということは、問題としては、
自社が使用中のプロバイダのDNSキャッシュサーバーが、
独自ドメインのホストを正引きしたときに、変更前のIPアドレスを返してしまう
というだけのことなのですね。

ということなら単に、そのプロバイダのDNSキャッシュサーバーに
ゾーン定義の変更が伝播していないというだけのことになるので、
事前に設定していたTTL値
（今回の変更のとき一緒にTTL値を変更しても、それではなくて）
を越えていなければ、その時間を待つしかないかと。

なお、サーバー移転の１週間前ぐらいに事前にTTLだけを短くしておいて
実際の移転時の伝播をスムーズにするというのは、やったほうが良かったかもしれませんね。
ただ、DNSキャッシュサーバーのなかには
ゾーン個別のTTL設定を無視して、72時間とか１週間とか、
伝播にかかる場合もあるので、どうしようもないこともありますが。
(baidoのボットなんてずいぶん長いこと来ますし）

お礼

今朝、変更されていることが確認できました。
何度もご回答いただき、ありがとうございました。

確かに、外部からDNSは参照できないですね。
言われてみれば納得ですが、パニック状態の私には
気づけませんでした。
それが分かった上で改めて今までの検証を見ると
いろいろと理解できました。

ご回答いただいた全てがベストアンサーなんですが
早い段階から回答を頂き、その回数も多かった
superside0さんをベストアンサーにさせていただきます。
他の回答者の方、申し訳ありません。

回答No.13

bunjii

回答No.9の字句に誤変換がありましたので訂正します。
「伝搬」→「伝播」（どちらも同じ意味を含んでいますので訂正不要かも知れませんが厳密には用法が異なるようです）

回答者間で問題点の捉え方が異なり質問者が本来の問題点を取り違えているといけませんので問題点を整理してみましょう。

>DNSを変更しましたが、会社からの接続に反映されません。
回答No.3へのお礼に「今回、ホームページ公開用のホスティングサービスの業者変更でネームサーバーの設定変更をしています。」と言っています。
世界中のDNSが夫々どのような動作でドメイン名からIPアドレス変換するかをご存知でしょうか？
ご存じないための質問かと思います。

>・会社の中からnslookupを実行すると、変更前のアドレスが返ります
当たり前の応答なので会社がインターネット接続を契約しているプロバイダーのDNSサーバーのキャッシュが無効になるまで変更前のIPアドレスを返すでしょう。
強制的に変更後のIPアドレスを返せるようにするには対象のDNSのキャッシュの破棄（リフレッシュ）をさせることが必要です。

>・スマホからホームページにアクセスすると、変更後のページが表示されます
それも当たり前の動作と言えます。
スマホが使っているDNSには変更前のアクセスが無ければ初めてのアクセスなのでDNSの元締め（ルートDNS）から最新情報を得てIPアドレス変換を行うので変更後のページを表示できます。
因みに、変更前のWebサーバーは稼働していて古いコンテンツということですか？

>・下記サイトからnslookupを実行すると、変更後のアドレスが返ります
これも当然の結果です。
そのサイトは最新情報を提供していると思いますので現時点の正しいIPアドレスを返すでしょう。

>一応、ルーターの電源を入れなおしてみましたが改善されません。
ルーターのDNSキャッシュサーバーをリフレッシュしても新たに取り込む情報がISPのDNSからなのでISPのDNSキャッシュをリフレッシュしない限り同じになります。

DNSの動作に関してはすべて正しく動作しているので世界中のDNSキャッシュが無効になるまで待つしかないでしょう。
あなたが困っているのはDNSの問題では無く新旧のWebサーバーの情報提供内容が不一致になっていることであると思います。
ホスティングの移行には重複期間が必要であることをご存じなかったために起っている問題かと思われます。

お礼

再度のご連絡ありがとうございます。

ある程度は分かっている「つもり」だったんですが...

　・ISPのDNSが外部から参照できないことが頭になかった
　・外部サイトにて、DNSを指定してnslookupを実行した時に、
　　変更後を取得できていると思ってしまった

この2つの間違いから、社内のネットワーク上に問題があると
思い込んでしまいました。
特に社外から見にいった時に変更されていると思ってしまったので
ISPのDNSサーバーのキャッシュは更新済みだと思ってしまいました。

普段から「つもり」のままにしてしまい、勉強を怠っていることを痛感し、
反省しました。
みなさんのレベルには達せないと思いますが、もう少し勉強するようにします。

新旧のWebサーバーはしばらく重複させています。
同じコンテンツになっていますが、トップページの目立たない部分を
変更して、私にだけはどちらのサーバーを見ているか分かるように
してあります。

回答No.12

xmp

回答No.11「■適切なAレコードの変更手順：ネームサーバの変更を伴う場合」の(1.),(2.),(3.)を訂正します。

■適切なAレコードの変更手順：ネームサーバの変更を伴う場合
(*1) 旧NSレコードのTTLが48時間(172800秒)と仮定する
(*2) 旧AレコードのTTLが1時間(3600秒)と仮定する

(0.) 作業前
【ドメインレジストラ】NSレコード：(旧)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】NSレコード：(旧)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】Aレコード：古いWebサーバ(TTL=3600)

(1.) NSの移転を先に完了させる（Webサーバを移転したい時間の48時間前(*1)までに行う）
【ドメインレジストラ】NSレコード：『(新)』権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】NSレコード：『(新)』権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】Aレコード：古いWebサーバ(TTL=3600)
【(新)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】Aレコード：『古い』Webサーバ(TTL=3600)

《訂正点》
NSの移転だけ先に行うので、両方の権威DNSサーバには「古い」Aレコードを設定します。

(2.) AレコードのTTLを短くする（Webサーバを移転したい時間の1時間前(*2)までに行う。1.の作業タイミングで行ってもよい）
【ドメインレジストラ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】Aレコード：古いWebサーバ(TTL=3600)
【(新)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】Aレコード：古いWebサーバ(TTL=『60』)

《訂正点》
NSの移転後にAレコードの変更を行うため、旧権威DNSサーバのAレコードのTTLは短くしなくてもよいです。
（AのTTLよりNSのTTLの方が長いことを前提にしています。）

(3.) Webサーバを移転したい時間に、Aレコードを変更する
【ドメインレジストラ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)《使われない》
【(旧)権威DNSサーバ】Aレコード：古いWebサーバ(TTL=3600)《使われない》
【(新)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】Aレコード：『新しい』Webサーバ(TTL=60)

【キャッシュを持っていたキャッシュDNSサーバ】TTLを迎えているので新しいNSとAが使われる（長くても60秒待てばよい）
【キャッシュを持っていないキャッシュDNSサーバ】新しいNSとAが使われる

《訂正点》
Webサーバを移転したい時間にAレコードを「新しいWebサーバ」に変更します。
ネームサーバの移転設定（そして旧NSのTTLを待つこと）と、Webサーバの移転設定（Aレコードの向き先変更）を分けて行うことが重要です。

(4.) 問題ないことが確認されたらAレコードのTTLを適切な値に設定する
【ドメインレジストラ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)《使われない》
【(旧)権威DNSサーバ】Aレコード：古いWebサーバ(TTL=3600)《使われない》
【(新)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】Aレコード：新しいWebサーバ(TTL=『3600』)

(5.) 問題ないことが確認されたら旧権威DNSサーバの設定を削除する
【ドメインレジストラ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】Aレコード：新しいWebサーバ(TTL=3600)

■
以上、回答No.11の訂正です。

お礼

訂正までしていただき、ありがとうございます。

回答No.11

xmp

不正確な回答が多いですね。
nslookup、72時間、1週間、伝播、伝搬とかいう説明はアテにしない方がいいでしょう（ここの回答に限らず）。

まずnslookupを使うのはやめましょう。混乱の元です。digを使いましょう（drill, dnsqなどでもよい）。
あなたが調べたいのは権威DNSサーバに設定されている何のタイプのリソースレコードですか？
NSレコードですか？Aレコードですか？

質問者の方のコメントを読む限り、お使いのISPが持つキャッシュDNSサーバに「NS」のキャッシュが残っていると考えられます。（長いAレコードのキャッシュの可能性もありますが、どちらでも以下の説明に影響はないでしょう。）

読みやすさのため、移転前を「旧、古い」、移転後を「新、新しい」と書きます。

■あなたの作業前
【ドメインレジストラ】NSレコード：(旧)権威DNSサーバ
【(旧)権威DNSサーバ】NSレコード：(旧)権威DNSサーバ
【(旧)権威DNSサーバ】Aレコード：古いWebサーバ

■あなたの作業後
【ドメインレジストラ】NSレコード：(新)権威DNSサーバ
【(旧)権威DNSサーバ】NSレコード：(旧)権威DNSサーバ
【(旧)権威DNSサーバ】Aレコード：古いWebサーバ
【(新)権威DNSサーバ】NSレコード：(新)権威DNSサーバ
【(新)権威DNSサーバ】Aレコード：新しいWebサーバ

■社内で使われるISPのキャッシュDNSサーバ
NS：「(旧)権威DNSサーバ」のキャッシュあり
A：「（旧NS経由で）古いWebサーバ」のキャッシュあり《このIPアドレスが返される》

■他のキャッシュDNSサーバ（古いキャッシュを持たない場合）
NS：「(新)権威DNSサーバ」のキャッシュあり
A：「（新NS経由で）新しいWebサーバ」のキャッシュあり

そしてNSのTTLを調整していなければ、NSのキャッシュは1日あるいは2日という値になっているのでしょう。
「DNSの設定変更（レコードの変更）」をする場合はTTLの調整をしないと変更が反映されるまで待たされることになりますが、ネームサーバの移転を伴う場合にはキャッシュDNSサーバの挙動を理解した上で、待たされることがないように適切な手順で「DNSの設定変更」をする必要があります。

■適切なAレコードの変更手順：ネームサーバの変更を伴う場合
(*1) 旧NSレコードのTTLが2日(172800秒)と仮定する
(*2) 旧AレコードのTTLが1時間(3600秒)と仮定する

(0.) 作業前
【ドメインレジストラ】NSレコード：(旧)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】NSレコード：(旧)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】Aレコード：古いWebサーバ(TTL=3600)

(1.) NSの移転を先に完了させる（Webサーバを移転したい時間の2日前(*1)までに行う）
【ドメインレジストラ】NSレコード：『(新)』権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】NSレコード：『(新)』権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】Aレコード：『新しい』Webサーバ(TTL=3600)
【(新)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】Aレコード：新しいWebサーバ(TTL=3600)

(2.) AレコードのTTLを短くする（Webサーバを移転したい時間の1時間前(*2)までに行う。1.の作業タイミングで行ってもよい）
【ドメインレジストラ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】Aレコード：新しいWebサーバ(TTL=『60』)
【(新)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】Aレコード：新しいWebサーバ(TTL=『60』)

(3.) Webサーバを移転したい時間を迎える
【キャッシュを持っていたキャッシュDNSサーバ】TTLを迎えているので新しいNSとAが使われる（長くても60秒待てばよい）
【キャッシュを持っていないキャッシュDNSサーバ】新しいNSとAが使われる

(4.) 問題ないことが確認されたらAレコードのTTLを適切な値に設定する
【ドメインレジストラ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(旧)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)《使われない》
【(旧)権威DNSサーバ】Aレコード：新しいWebサーバ(TTL=60)《使われない》
【(新)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】Aレコード：新しいWebサーバ(TTL=『3600』)

(5.) 問題ないことが確認されたら旧権威DNSサーバの設定を削除する
【ドメインレジストラ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】NSレコード：(新)権威DNSサーバ(TTL=172800)
【(新)権威DNSサーバ】Aレコード：新しいWebサーバ(TTL=3600)

このような手順を踏まずに「あなたの作業後」のような状態にしてしまったため、ネームサーバの変更後にも古いNSレコードやAレコードが2日間ほど使われる状況になっていると思われます。

(1.) や (2.) の作業後にその設定がきちんとできているか確認するためには（nslookupではなく）digコマンドやdrillコマンドを用いて、権威DNSサーバに「非再起問い合わせ(+norec)」を行ってください。
dig +norec domain.example.com -t a @ns.example.net
この例では、新しい権威DNSサーバ ns.example.net に対して a タイプ（Aレコード）を問い合わせています。

この設定が完了する前にキャッシュDNSサーバ経由で名前解決を行ってしまうと古い情報がキャッシュされてしまい、TTLの時間だけ待つ必要が生じてしまいます。
またレコードが設定されていない場合でも、レコードが存在しないという情報がキャッシュされてしまいます（ネガティブキャッシュ）。ネガティブキャッシュのTTLはSOAレコードで指定されています。

■どうすればいいか
旧NSレコードと旧AレコードのTTLのうち、長い方の時間だけ経過することを待てば「DNSの変更が反映」された状態になります。待ちましょう。どれだけ待てばいいかは回答No.6で説明しています。
なぜ待たなければいけなかったのかは上記で説明しています。
適切な手段を取れば待つことなくネームサーバおよびウェブサーバの移転ができます。そのためにはDNSの仕組みを理解している必要があります。
「最長72時間待つ必要がある」といった説明はDNSを理解していない人の虚言です。信じてはいけません。

■
最後に。
（回答No.9）
> 一般的には全世界のDNSへ情報の伝搬するのは1週間程度とされています。
全世界のDNS（DNSとは何でしょうか）になんて何もアクションしません。1週間というのも何も根拠がありません。いい加減な説明をしないでください。

（回答No.10）
> ただ、DNSキャッシュサーバーのなかには
> ゾーン個別のTTL設定を無視して、72時間とか１週間とか、
> 伝播にかかる場合もあるので、どうしようもないこともありますが。
「DNSキャッシュサーバー」にはゾーン情報は伝播しません。伝播が行われるのはプライマリ権威DNSサーバからセカンダリへゾーン転送される動作だけです。
72時間や1週間というのも不正確です。一般に提供されているキャッシュDNSサーバにTTL上限を無視するようなものはありません。どうしようもないことはありません。いい加減な説明をしないでください。

お礼

今朝、変更されていることが確認できました。
何度もご回答いただき、ありがとうございました。

また、詳しい説明ありがとうございます。
digコマンドは、自宅からは試してみたのですが、
結果が理解できず、そのままにしていました。
No.10の方の回答の通り、外部から参照できないことが
原因だったと思います。
改めて、会社から試してみます。

回答No.9

bunjii

>ISPに問い合わせた結果は、改めてご報告させていただきます。
ISPは無数にありますが会社とインターネットの接続契約しているISPのことですか？
無意味ですよ。
Webサーバーのレンタル解約先に確認すべきことなので接続契約のISPはグローバルIPアドレスの貸与とDNSを停止させないことが責任範囲であなたの会社の独自ドメインのサイトが正しくアクセスできなくても責任を負いません。（回線のダウンについてはNTTやKDD等が責任を負います）
Webサーバーのレンタル会社はWebサーバーのドメインを管理するレジストラーと共同してドメイン用のDNSについて責任を負うでしょう。
従って、Webサーバー用のDNSが正しい動作になっていない場合はWebサーバーのレンタル会社に対応させる必要があります。
旧Webサーバーのレンタルが契約切れでアクセスできない状態であればあなたの会社は社会的に信用を失うでしょう。
旧Webサーバーが1週間以上使えるのであれば新Webサーバーとコンテンツの内容を同一にすることで会社の信用を保てます。
一般的には全世界のDNSへ情報の伝搬するのは1週間程度とされています。
レンタルサーバーを振り替えるときはこれらのことに注意を払うべきです。
ISPのDNSへnslookupの応答が実態と異なることを申し出るのは恥の上塗りになります。

お礼

今朝、変更されていることが確認できました。
何度もご回答いただき、ありがとうございました。

蛇足ですが、新旧のWebサーバーは、1か月程度は重複して使える状態です。

回答No.8

bunjii

回答No.3へのお礼に次のような記述があります。
「今回、ホームページ公開用のホスティングサービスの業者変更で
ネームサーバーの設定変更をしています。」
これが最大の原因です。
公開中のWebサーバーはホスティングサービスの業者切り替え時に新旧を1週間ほど重複稼働させるのが常識です。
つまり、旧ホスティングサーバーも新ホスティングサーバーと同じコンテンツに更新し、nslookupでルーターAから新ホスティングサーバーのIPアドレスが帰るようになったら旧ホスティングサービスを解約すれば世間での信頼を失うことなく新旧移行が完了します。

>特に、プライマリとかセカンダリとかの設定はなさそうですが、
>セカンダリの設定は必ず必要になるでしょうか？
「プライマリ」は「マスター」に「セカンダリ」は「スレーブ」と言い換えてください。
ドメインの管理者（レジストラー）はDNSサーバーを最低2台で運用するよう指導しているはずです。
ドメイン運用ではDNSのダウンで情報提供が停止されることを認めていません。
アクセスが多いサイトでは負荷分散のために多数のDNSを設置することもあります。

>つまり、社内環境から、ISPのDNSを見に行った時だけ
>古い情報を返しているような状態です。
ルーターAに繋がっているプロバイダーのDNSのキャッシュが最長のライフになるでしょう。
何故なら旧ホスティングのサーバーに社内から接続していると思われます。
他のアクセス経路は初めてのアクセスになっていればキャッシュが無いので新ホスティングから情報を引き出します。

あなたはTCP/IPの通信について知識が足りないようなので初歩から学習し直すことをお薦めします。
尚、後出し情報が解決の決め手になっているようです。
質問当初から回答No.3へのお礼にある前述の情報が提示されていれば無駄な回答で混乱しなかったでしょう。

お礼

回答ありがとうございます。
普段からの勉強不足を痛感しております。

また、情報が後出しになってしまい申し訳ありません。
パニック状態になりながらご質問させていただき、
その後で、みなさんからの回答などを参考にさせていただき
試行錯誤しているため、最初に適切な情報を出せませんでした。

更にで申し訳ありませんが、今までの私の説明に間違いがありました。

～～～～～　ここから、今までの情報の訂正になります　～～～～～

社外からISPのDNSに対してnslookupを行うと、
変更後の情報が取得できるとしておりましたが、
実際は取得できていませんでした。

私が社外からとしていたのは、
https://www.cman.jp/network/support/nslookup.html
このサイトを使って、nslookupを実行した際に、
結果ページ上部の「入力の逆引きまたは正引き」に
変更後のIPアドレスが表示されていたからです。

改めて確認したところ、結果ページ下部の結果部分に

** server can't find xxxxx.co.jp: REFUSED

と表示されていました。

昨日、自宅からコマンドプロンプトにてnslookupを実行した際も
同じように、「見つからない」となりました。
（会社から実行した場合は、変更前のIPアドレスを返してきます）

ISPに問い合わせをしようと思っておりますが、土日はお休みでした。
明日、改めてISPに問い合わせしてみます。

知識不足だけならまだしも、このような不注意による見落としで
皆さんを混乱させてしまい申し訳ありません。

ISPに問い合わせた結果は、改めてご報告させていただきます。

回答No.7

superside0

昨日の通信トラブルは、BGPルーティング関係の誤りとのことなので、
この場合の可能性として
　A地点からB地点やC地点へのアクセスはOK
　B地点からC地点へはルーティング不能ということは考えられます。
このときに、
　Aがクライアント側
　BがプロバイダのDNSキャッシュサーバー
　Cが権威DNS
だとすると、　Aから　BやCには問い合わせは出来るが
BからCに問い合わせできないので、いつまでたってもBのキャッシュが更新されないということはあり得ると思われます。
（とはいっても、これはあくまでも可能性の話ですし、
　これが原因だとしたら、いまだに解決しないというのは、おかしいですけど）

また、今回の場合、プロバイダ提供のDNSキャッシュサーバーに対して
社外のクライアントから問い合わせすると、更新後の正しい値が返ってくるのに
同じIPアドレスのDNSキャッシュサーバーに対して、
特定の通信経路（社内から特定のプロバイダ）を使ったときだけ
古い情報が返ってくるということなので、
もし本当にこの通りだとすると、　正直　問題が複雑なような気がします。

可能性として考えられるとすれば、
プロバイダのDNSキャッシュサーバーが、負荷分散の為に
応答先に合わせて複数のUDP応答サーバーを持っていて
その複数のキャッシュサーバー間で整合がとれていなくて
クライアントからの通信経路の違いだけで応答内容が変わる
というのはあり得るかもしれません。

お礼

回答ありがとうございます。

> もし本当にこの通りだとすると、　正直　問題が複雑なような気がします。

すみません、本当ではありませんでした。

私の今までの説明に間違いのあることが分かりましたので
現時点で最後のご回答を頂いているNo.8の方のお礼部分にて
ご説明させていただきます。

回答No.6

xmp

「DNSを変更した」というのは何の操作でしょうか。
リソースレコードを変更したという意味ですか？

理解が不十分なままでは話が進まないので、DNSの仕組みを確認していきましょう。
https://www.nic.ad.jp/ja/newsletter/No51/0800.html
上記URLのページの「名前解決の流れ」の「図3」を見てください。

「クライアントPC」―「キャッシュDNSサーバ」―「権威DNSサーバ群」

という図があります。
クライアントPC（操作するPC）で名前解決を行うと、キャッシュDNSサーバに問い合わせます。
キャッシュDNSサーバは、キャッシュがあればそれを返し、キャッシュがなければ権威DNSサーバに問い合わせてキャッシュした後、それを返します。

つまりキャッシュがある間は、権威DNSサーバの情報が変更されても、クライアントはそのキャッシュDNSサーバ経由で変更後の情報を受け取ることができません。

ISPはキャッシュDNSサーバを持っており、クライアントは、ISPに紐付くキャッシュDNSサーバを経由して名前解決を行います。
利用するネットワークが異なれば（ISPが異なれば）、通常は使われるキャッシュDNSサーバも異なります。
これが質問文の「会社では変更前、スマホや別ネットワークでは変更後のIPアドレスが返る」という現象を生じさせています。

ここまで分かったでしょうか。
ISPが持つキャッシュDNSサーバに、古いキャッシュがあるかどうかで動作が変わるということです。
「名前解決」が行われるタイミングでキャッシュが行われ、そのキャッシュはTTLの時間だけ保持されます。
（TTLはリソースレコードの種類ごとにそれぞれ設定されます。またネガティブキャッシュというものもありますがここではそれらを説明しません。）

■
これ以上DNSの説明を続けてもしょうがないので、既存の回答についてコメントをつけておきます。

（回答No.1について）
> それは分かっていますが、今回はISP側のDNSは変更されていると思います。
> うちの会社にはプロクシもDNSキャッシュサーバーもないのに、
何を分かっているのですか？
「DNSの変更」がゾーンファイルの更新であるとすれば、通常は即時反映されます。
ドメインレジストラ等のネームサーバを提供するサービス上での変更が、実際に権威DNSサーバに反映されるまでの時間であるとすれば、通常は長くても数分程度で済みます。（サービス次第ではあるが、2,3日かかるのが当たり前というサービスは使い物にならない）

（回答No.3について）
この質問文から「ゾーン転送の失敗」の可能性を説明するのは筋違いでしょう。
nslookup コマンドしか説明しないのは混乱の元です。

> また、ルーターに設定しているDNSを、
> 　8.8.8.8　8.8.4.4
> に変更すれば、正常に使えています。
ISPのキャッシュDNSサーバを使わず、パブリックなキャッシュDNSサーバを使うのは推奨しません。（もちろん意図があれば別ですが、今回のケースでは相応しくないでしょう。）

> つまり、社内環境から、ISPのDNSを見に行った時だけ
> 古い情報を返しているような状態です。
> 複数のパソコンで試しているので、パソコンではなくLAN上の
> どこかにキャッシュがありそうだと思っていますが、
> 思い当たるものがありません。
ISPが提供しているキャッシュDNSサーバにキャッシュがあるのです。

（回答No.5について）
> それと、昨日は、OCN等で大規模な通信障害がありましたが、
> それの影響はないですか？
全く関係ありません。質問者を混乱させています。

> 寝て起きたら変更されていることを期待して、今日はあきらめます。
キャッシュの生存時間は確認できます。
dig +norec domain.example.com a
とでも実行すれば残りのTTLが表示されるでしょう。
http://www.atmarkit.co.jp/ait/articles/1412/19/news015.html

最後に。
> 何か分かる方がいましたら、助けてください。
DNSを勉強することをお勧めします。

お礼

DNSの説明ありがとうございます。
改めて勉強させていただきます。

私の今までの説明に間違いのあることが分かりましたので
現時点で最後のご回答を頂いているNo.8の方のお礼部分にて
ご説明させていただきます。

回答No.5

superside0

> セカンダリの設定は必ず必要になるでしょうか？
業者のネームサーバーを使われているのなら、
セカンダリDNSは、通常はスレーブ設定なので設定変更は不要です。
（自前でネームサーバーを設置した場合には、設定ミスで
　No.3のようなこともあるよというだけです。）

そのドメインの大元のネームサーバー（プライマリ、セカンダリとも）を指定して
nslookupしてみれば　すぐに確認できますよ。

> ISPから指定されているDNSが
>　　●●●.●●●.●●●.●●●
>とした場合、会社のネットワーク内のパソコンから
>　nslookup xxx.co.jp ●●●.●●●.●●●.●●●
>とすると、古い情報が返ってきます。

問題を絞り込むために、nsloookupで調べた結果が
・ホスティングサーバ業者のDNSに対して問い合わせすると、プライマリ・セカンダリとも変更後が返る
・GoogleのDNS(8.8.8.8や8.8.4.4)に対して問い合わせすると、変更後が返る
・しかし、ISP　（＝プロバイダ）のDNSに対して問い合わせすると、　変更前が返る

ってことなら、ネームサーバーの設定変更には、問題なくて
単にISP(プロバイダ)のDNSが、再学習できていないだけじゃないかな。

該当ドメインのゾーン設定での　TTL値は何時間にになっています？
それと、昨日は、OCN等で大規模な通信障害がありましたが、
それの影響はないですか？

お礼

何度もすみません。

> ・ホスティングサーバ業者のDNSに対して問い合わせすると、プライマリ・セカンダリとも変更後が返る
> ・GoogleのDNS(8.8.8.8や8.8.4.4)に対して問い合わせすると、変更後が返る
> ・しかし、ISP　（＝プロバイダ）のDNSに対して問い合わせすると、　変更前が返る

この通りになります。

> ってことなら、ネームサーバーの設定変更には、問題なくて
> 単にISP(プロバイダ)のDNSが、再学習できていないだけじゃないかな。

https://www.cman.jp/network/support/nslookup.html

このページで、ISPのDNSを指定すると変更後が返ります。
なので、ISPのDNSは変更されていると思うんですが...

きのうの障害はニュースを見るまで知らなかったくらいなので
うちには影響なかったと思います。
寝て起きたら変更されていることを期待して、今日はあきらめます。

ありがとうございました。

回答No.4

ballville

まさかとは思いますがhostsに書いてあったりしませんか

お礼

回答ありがとうございます。

hostsファイルには書いてません。
ファイル自体を削除しても同じでした。
逆に、書いてみても変化はありませんでした。

回答No.3

superside0

よくある失敗は、　プライマリDNSとセカンダリDNSのうちの
プライマリDNSのゾーン定義だけ書き換えて、
セカンダリDNSは、それが自動的に反映されるはずと思っていたら、
もともとセカンダリDNSをスレーブ設定でなくマスター設定にしてしまっていた
というのがありますね。

これだと、セカンダリDNSへ問い合わせしたケースでは、古いIPアドレスのままを返すので
いつまでたってもDNS変更が、反映されないことになります。

自ドメインのネームサーバーはプライマリ・セカンダリと複数あるはずなので、
まずは、そのドメインのネームサーバーのホスト名なりIPアドレスを調べて
nslookupでそのDNSサーバーを指定してみればはっきりするでしょう。

お礼

回答ありがとうございます。

今回、ホームページ公開用のホスティングサービスの業者変更で
ネームサーバーの設定変更をしています。
特に、プライマリとかセカンダリとかの設定はなさそうですが、
セカンダリの設定は必ず必要になるでしょうか？

また、私の調査で分かったことがありますので、
ここに書かせてもらいます。

ISPから指定されているDNSが
　　●●●.●●●.●●●.●●●
とした場合、会社のネットワーク内のパソコンから
　nslookup xxx.co.jp ●●●.●●●.●●●.●●●
とすると、古い情報が返ってきます。
これを、
　nslookup xxx.co.jp 8.8.8.8
とすると、新しい情報が返ってきます。

社外の環境から実行した場合は、どちらも新しい情報が返ってきます。

また、ルーターに設定しているDNSを、
　8.8.8.8　8.8.4.4
に変更すれば、正常に使えています。
この状態でnslookupを試しても、上記と同じ結果になります。

ルーターの再起動や、コマンドでのDNSキャッシュの削除をしても
症状は変わりません。

つまり、社内環境から、ISPのDNSを見に行った時だけ
古い情報を返しているような状態です。

複数のパソコンで試しているので、パソコンではなくLAN上の
どこかにキャッシュがありそうだと思っていますが、
思い当たるものがありません。

長文になってしまい申し訳ありませんが、
引き続きよろしくお願いします。