DNSハイジャック

不正な DNS サーバーは、望ましい Web サイト (検索エンジン、銀行、証券会社など) のドメイン名を、意図しないコンテンツを持つサイト、さらには悪意のある Web サイトの IP アドレスに変換します。ほとんどのユーザーは、ISPによって自動的に割り当てられた DNS サーバーに依存しています。ルーターに割り当てられた DNS サーバーは、ルーターのファームウェア内の脆弱性をリモートで悪用することによって変更されることもあります。^{[ 2 ]}ユーザーが Web サイトにアクセスしようとすると、代わりに同じドメインを使用しているように見える偽のページにリダイレクトされます。この攻撃はファーミングと呼ばれます。リダイレクトされたサイトが、機密情報を不正に入手するために正規の Web サイトを装った悪意のある Web サイトである場合、それはフィッシングと呼ばれます。^{[ 3 ]}

AT&T ^{[ 4 ]} 、CablevisionのOptimum Online ^{[ 5 ]} 、CenturyLink [ ^{6 ]}、Cox Communications、RCN ^{[ 7} ] 、Rogers ^{[ 8 ]}、Charter Communications (Spectrum)、Plusnet ^{[ 9 ]}、Verizon ^{[10]、Sprint [ 11 ]}、T ^{- Mobile US [12]}、Virgin ^{Media [ 13} ] [ ^{14 ] 、 Frontier Communications}、Bell Internet [ ^{15 ] 、} Deutsche Telekom AG ^{[ 16 ]}、Optus [17 ^] 、 Mediacom ^{[ 18 ]}、ONO ^{[ 19 ]}、TalkTalk ^{[ 20 ]}、Bigpond ( Telstra ) ^{[ 21 ] [ 22 ] [ 23 ] [ 24 ] 、} TTNETなど^{の多数の消費者向け}ISP Türksat、およびインドネシアのすべての顧客向けISPは、広告の表示^{[ 25 ]}や統計情報の収集など、独自の目的でDNSハイジャックを使用している、または使用していた。オランダのISPであるXS4ALLとZiggoは、裁判所の命令によりDNSハイジャックを使用している。彼らはThe Pirate Bayへのアクセスをブロックし、警告ページを表示するよう命じられた^{[ 26 ]。}一方、インドネシアのすべての合法的な顧客向けISPは、国家DNS法^{[ 27 ]}を遵守するためにDNSハイジャックを行っている。この法律は、インドネシアのすべての顧客向けISPに対し、ポート53をハイジャックして自社のサーバーにリダイレクトし、KominfoのTrustpositifに掲載されているウェブサイトをブロックすることを義務付けている。インターネットの健康キャンペーンの下で、これらの行為は DNS (NXDOMAIN - 存在しないドメイン) 応答の RFC 標準に直接違反し、クロスサイトスクリプティングなどのセキュリティ脆弱性を引き起こします。しかし、暗号化された DNS プロトコル、特に DNS over HTTPS (DoH) および DNS over TLS (DoT) が広く採用されたことにより、ISP レベルの DNS ハイジャックの効果は大幅に低下しました。最新の Web ブラウザとオペレーティングシステムは、デフォルトでこれらの暗号化されたチャネルを介してクエリをルーティングすることが増えており、ISP が DNS 応答を傍受または操作することを防いでいます。^{[ 28 ] [ 25 ]}

DNSハイジャックの懸念事項は、NXDOMAIN応答のハイジャックにあります。インターネットおよびイントラネットアプリケーションは、指定されたホストのDNSエントリが存在しない状態を示すためにNXDOMAIN応答に依存しています。無効なドメイン名（例えばwww.example.invalid）を照会すると、NXDOMAIN応答が返され、アプリケーションに名前が無効であることを通知し、適切なアクション（例えば、エラーを表示するか、サーバーへの接続を試みない）を実行します。しかし、これらの非準拠ISPのいずれかでドメイン名を照会すると、常にISPに属する偽のIPアドレスが返されます。Webブラウザでは、この動作は、このIPアドレスへの接続時に、適切なエラーメッセージの代わりに、プロバイダのISPリダイレクトページ（場合によっては広告付き）が表示されるため、煩わしい場合があります。しかし、NXDOMAINエラーに依存する他のアプリケーションは、代わりにこの偽のIPアドレスへの接続を開始しようとし、機密情報が漏洩する可能性があります。

ISPがDNSを乗っ取った際に機能しなくなる例：

• Windows Serverドメインに属するローミング中のノートパソコンは、ドメインコントローラー、メールサーバー、その他のインフラストラクチャなどのリソースが利用可能に見えるため、社内ネットワークに戻ったと誤って認識します。そのため、アプリケーションはこれらの社内サーバーへの接続を試みますが失敗し、パフォーマンスの低下、インターネット接続上の不要なトラフィック、タイムアウトが発生します。
• 多くの小規模オフィスやホームネットワークでは、独自の DNS サーバーがなく、代わりにブロードキャスト名前解決に依存しています。Microsoft Windows の多くのバージョンでは、デフォルトで NetBIOS 名前解決ブロードキャストよりも DNS 名前解決を優先します。そのため、ISP の DNS サーバーが LAN 上の目的のコンピュータ名に対して (技術的に有効な) IP アドレスを返すと、接続するコンピュータはこの誤った IP アドレスを使用し、LAN 上の目的のコンピュータへの接続に必ず失敗します。回避策としては、コンピュータ名の代わりに正しい IP アドレスを使用するか、DhcpNodeType レジストリ値を変更して名前解決サービスの順序を変更する方法があります。^{[ 29 ]}
• Firefoxなどのブラウザには、もはや「名前で検索」機能（アドレスバーにキーワードを入力すると、最も近い一致するサイトに移動できる機能）がありません。^{[ 30 ]}
• 最新のオペレーティングシステムに組み込まれているローカルDNSクライアントは、パフォーマンス上の理由からDNS検索結果をキャッシュします。クライアントがホームネットワークとVPNを切り替える場合、誤ったエントリがキャッシュに残ったままになり、VPN接続でサービス停止が発生する可能性があります。
• DNSBLのスパム対策ソリューションはDNSに依存しているため、誤ったDNS結果がその動作を妨害します。
• ISPによって、接続しようとしているサーバーが利用可能であると誤認させられたアプリケーションによって、機密性の高いユーザーデータが漏洩する可能性がある。
• ブラウザでURLを誤って入力した場合に、どの検索エンジンを参照するかというユーザーの選択肢は失われ、ISPがユーザーに表示される検索結果を決定するようになる。
• VPN接続でスプリットトンネルを使用するように構成されたコンピュータは、インターネットからNXDOMAIN応答を受信したときに、トンネルの外でパブリックインターネット経由で解決されるべきではないイントラネット名が、VPNトンネルを介してプライベートDNSサーバーで正しく解決される代わりに、架空のアドレスに解決され始めるため、動作しなくなります。たとえば、内部メールサーバーのDNS Aレコードを解決しようとするメールクライアントは、有料結果Webサーバーに誘導する誤ったDNS応答を受信し、再送信が無駄に試みられる間、メッセージが何日も配信待ちのキューに溜まる可能性があります。^{[ 31 ]}
• これは、WebブラウザがISPにプロキシサーバーが設定されていると誤って認識するように仕向けることで、Webプロキシ自動検出プロトコル（WPAD）を破綻させる。
• これは監視ソフトウェアの動作を阻害します。例えば、サーバーの状態を確認するために定期的にサーバーに接続している場合、監視ツールがサーバーの暗号鍵を検証しようとしない限り、障害を検知することはありません。

一部のISPでは、NXDOMAIN応答のハイジャックを無効にするための加入者設定オプションが提供されていますが、ほとんどの場合は提供されていません。正しく実装されていれば、このような設定によってDNSは標準動作に戻ります。しかし、他のISPでは、代わりにWebブラウザのCookieを使用して設定を保存します。この場合、根本的な動作は解決されません。DNSクエリは引き続きリダイレクトされ、ISPのリダイレクトページは偽のDNSエラーページに置き換えられます。Webブラウザ以外のアプリケーションは、Cookieを使用してこのスキームからオプトアウトすることはできません。オプトアウトはHTTPプロトコルのみを対象としており、実際にはプロトコルに依存しないDNSでこのスキームが実装されているためです。