Dig DNS と Whois

Dig DNS と Whois

あるクライアントが、サードパーティを通じてネーム サービスを運営しています。ドメインは、Godaddy (別のサードパーティ) を通じて登録されました。ネーム サービス プロバイダーのドメイン名が乗っ取られたため (理由は不明)、クライアントが使用しているネーム サーバーにアクセスできなくなったり、セキュリティが侵害されたりしました。

提供されたネーム サービスは、何らかの方法で、異なるネーム サーバーを使用して DNS を解決できました。困惑しています。サービス プロバイダーがクライアントのドメインのネーム サーバーを変更できるのはなぜですか?

簡略化された説明: * example.com の Godaddy Registrar は、ns2.ispnameserver.com と ns2.ispnameserver.com をネーム サーバーとしてリストします。

*ISPはexample.comのネームサーバーを提供し、ns1.ispnameserver.comとns2.ispnameserver.comを管理します。

ISP は *ispnameserver.com の制御を失います。何らかの方法で ISP は新しいネーム サーバー ns1.newispname.com ns2.newispname.com を提供することができ、DNS は魔法のように ns1.newispname.com と ns2.newispname.com を使用して example.com のクエリを解決します。

本質的に、ISP はクライアントの example.com ドメインの制御を乗っ取ることができました。Whois には依然として ns1.ispnameserver.com がリストされています。

ISP はどのようにしてそれを実現できたのでしょうか? どの組織がそのサービスを提供できるのでしょうか?

実績dig と whois から。少なくとも 1 週間はこの状態が続いています。

答え1

実績質問の内容は完全ではありませんが、私には次のように見えます。

投稿された内容には、委任情報が実際に変更されたことを示すものはなく、委任内のネームサーバーのゾーンに、NSゾーンの異なる (矛盾した) レコードがあることを示しています。

dig トレースは、委任レコードと権限レコードの両方を表示するので役立つ場合があります (「実際の結果」には、権限レコードのみが表示されると思われます)。

dig +trace +add example.com NS

レジストラを通じて管理できるのは委任情報、つまり、NS(および必要に応じてグルーA/ AAAA)ネームサーバーが管理するレコードです。親ゾーン紹介応答を送信する必要があります。
このレコード セットは実際の権限ゾーンのレコードNSと一致するはずですNSが、質問のシナリオを見ると、この点に関しては権限ゾーンのみが変更されているようです。


WHOIS と DNS に関する補足:

WHOIS は、登録されたドメイン名に関するレジストリおよび/またはレジストラ (レジストリの運用方法によって異なります) のメタ情報を表示するものです。実際の運用では役に立ちませんが、ドメイン名に関する人間が利用できる情報を提供します。

現在の運用上の現実を確認するには、常に WHOIS ではなく DNS を参照してください。質問では、委任の表現は DNS ではなく WHOIS からのものになっています (上記の dig trace コマンドで利用できるもの)。これにより、ある程度の不確実性が生じますが、WHOIS 出力が DNS で見つかった委任と実際に一致することがわかると思います (その場合、DNS は変更されません)。

答え2

こんなふうになります

  • レジストラは、ドメインに応答するDNSサーバーを制御/指定します。これはSOA(Start Of Authority)と呼ばれます。

  • ネームサーバーが指しているDNSプロバイダーは、その情報を変更することはできません。DNSに関しては、すべてを制御します。

具体的なシナリオに戻ります。考えられるシナリオの 1 つは、DNS プロバイダーが Godaddy にアクセスでき、またはアクセスしていたことがあり、ネーム サーバーを変更するためにログインしたというものです。

よくあるシナリオの 1 つは、サードパーティ企業がすべての制御権を持っている (つまり、DNS プロバイダーがクライアントの設定を行った) か、ある時点でレジストラへのアクセス権を付与されていることです。いずれにしても、GoDaddy のパスワードを変更する必要があります。

一方、クライアントが godaddy のパスワードを持っていない場合、おそらく最初からパスワードを持っておらず、DNS プロバイダーまたは他の誰かがこの設定をすべて実行し、問題を解決するために必要なことを行った可能性があります。問題が解決したのは良いことですが、それでも、クライアント以外の誰かが godaddy にアクセスする必要があるという事実は変わりません。

関連情報