web-dev-qa-db-ja.com

ドメインがISPのデフォルトDNSサーバーで突然解決されない

ドメインは他のISPとGoogleDNS（8.8.8.8）で正常に解決されますが、ドメインをホストしているサーバーで突然問題が発生しているISPが1つあります。

私が彼らにいくつかのサンプルドメインを与えたとき、彼らはそれを修正することができましたが、私が言及しなかった残りのドメインはまだ解決していませんでした。したがって、彼らは「手動」のバンドエイド修正のみを行ったと思います（WindowsホストファイルのIPを手動で編集するようなものかもしれませんが、確かではありませんが、うまくいけません）。

私は彼らに問題を適切に修正してもらいたい。彼らの側で何が起こっているのかはわかりませんが、私が言及しなかった他のドメインが解決していないため、問題の本当の原因について彼らが無知であるという印象を与えます。

理想的には、問題を適切に修正するために、どのようなトラブルシューティング手順を実行する必要がありますか？

networkingdnsipconnectioninternet-connection
3
IMB

私は次の事実に基づいて答えます：

  • Dig mydomain.comを呼び出すとconnection timed out; no servers could be reachedが取得されますが、Dig +trace mydomain.comは期待される結果を取得します。

  • ドメインサーバーのネームサーバーを変更し、そのIPでAレコードを設定することは機能しました。ネームサーバーを元に戻すと、再び機能しなくなりました。

私の説明は、間違った glue record ネームサーバーの間違ったIPを指しているということです。信頼できる応答を必要とし、グルーレコードを使用しないDNSクエリのみが正しい応答を取得します。

example.comのIPアドレスを検索するDNSクエリは、ネームサーバー（たとえばns1.example.com）のみを取得します。ただし、クエリをns1.example.comに送信するには、そのIPアドレスが必要です。そのIPアドレスについては、親のexample.comに問い合わせる必要があります。ブラウザが接続が不可能であると判断するまで、もう一度やり直します。グルーレコードは、example.comのネームサーバーにns1.example.comのIPを通知するため、すぐに返すことができます。

私の理論では、ドメインのグルーレコードにネームサーバーの間違ったIPアドレスが含まれているため、ドメインとの接続を確立できません。信頼できる応答を要求するDNSクエリのみが機能します。これは、そのようなクエリがグルーレコードをバイパスするためと思われます。

これで、ISPが解決できない場合でも、ドメインサーバーのネームサーバーを変更し、ISPによって失敗したネームサーバーを放棄することで、問題を回避できる可能性があります。

参照：

1
harrymc