![Dig DNS と Whois](https://rvso.com/image/717750/Dig%20DNS%20%E3%81%A8%20Whois.png)
あるクライアントが、サードパーティを通じてネーム サービスを運営しています。ドメインは、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 にアクセスする必要があるという事実は変わりません。