パブリックDNSサーバーはどのようにして悪い結果を返すのでしょうか？
私は多くの制裁下にある国に住んでいます。内部制裁（人に対する政府）と外部制裁（私たちの人に対する米国）の両方。
私たちの国では、YouTube、Twitter、Facebookおよびその他の多くのサイトがデフォルトでブロックされており、VPN経由でのみアクセスできます。
しかし、機能するはずの1つがあります。DNSです。 DNSを8.8.8.8に設定すると、理論的にはwww.youtube.comの正しいIPアドレスが返され、そのIPアドレスがISPによってブロックされるはずです。
そうではありません。私たちの政府がDNSサーバーを操作しているようです、それは公共のサーバーも同様です。
Ubuntu 18.04（Bionic Beaver）を使用していて、Network Manager DNSを無効にしています。 resolvconfとsystemd-resolveを無効にしました。これは、私のシステムのどのエンティティも/etc/resolv.confを変更できないことを意味します。
/etc/resolv.confの内容を次のように変更しました：
nameserver 8.8.8.8
およびonlyこのネームサーバー。したがって、すべてのアプリケーションがデフォルトでこのサーバーを使用し、WebサーバーのIPアドレスをこのサーバーに照会する必要がありますが、残念ながらユーザーはそうしていません！
kasra@ubuntu:~$ nslookup google.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: google.com
Address: 216.58.214.110
Name: google.com
Address: 2a00:1450:4001:812::200e
kasra@ubuntu:~$ nslookup youtube.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: youtube.com
Address: 10.10.34.35
Name: youtube.com
Address: 10.10.34.35
kasra@ubuntu:~$ nslookup Twitter.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: Twitter.com
Address: 10.10.34.35
Name: Twitter.com
Address: 10.10.34.35
kasra@ubuntu:~$ █
10.10.34.35は、フィルタリング機関のイントラネットIPアドレスです。
ISPはこれをどのように達成していますか？彼らは本当に盗んでいて MITM-ing8.8.8.8のトラフィックですか？ [〜＃〜] bgp [〜＃〜] ハイジャックのようなものですか？
VPNなしでこれを回避するにはどうすればよいですか？
彼ら（ISP）はこれをどのように達成していますか？彼らは本当に8.8.8.8のトラフィックを盗んでMITMしていますか？
おそらく、宛先ポート53（DNS）のすべてのパケットを独自のサーバーにリダイレクトし、クエリ自体に応答します。これは難しいことではありません。
VPNなしでこれを回避するにはどうすればよいですか？
適切に構成されたVPN（つまり、DNSリークがない）でこれを回避できます（VPNもブロックされていない場合）。また、HTTPプロキシまたはSOCKSプロキシを使用すると、HTTPおよびHTTPSトラフィックに役立ちます（最後の名前解決の外部名前解決を必ず構成してください）。また、dnscurve、dnscrypt、TLS経由のDNS、HTTPS経由のDNS（ Firefoxで既にサポートされています ）などのDNSプライバシー技術も役立ちます。
残念ながら彼らはそうしていません！
彼らはそうしている、そしてあなたのTypeScriptはそれが起こっていることを示しており、nslookupがそのIPアドレスをクエリして回答を得る。
あなたの混乱は、8.8.8.8が何であるかについての誤解に部分的に起因しています。これはanycastIPアドレスです。送信されたトラフィックは、世界中の複数のマシンのネットワークインターフェースにルーティングされ、Googleによってさまざまなデータセンターで実行されます。そのルーティングは、送信先のすべてのノードによって行われ、自分のISPが自分のネットワークを離れた直後に含まれます。
まず、Google自体が、これらのマシンの動作を国によって異なるようにすることができます。ある国のマシンが他の国のマシンに対して異なる方法で応答するようにすることができます。
次に、GoogleパブリックDNSがバックエンドからクエリするコンテンツDNSサーバーは、さまざまなGoogleマシンに異なる応答をすることができます。それらのバックエンドIPアドレス、およびそれらが対応する国は、Google Public DNS docoの一部として公開されています。送信元IPアドレスに基づいて、さまざまなクライアント（ここではクライアントはプロキシDNSサーバーの解決のバックエンドです）にさまざまな回答を提供するコンテンツDNSサーバーは、いくつかのDNSサーバーソフトウェアの機能です。
第三に、特定の国の管轄下にあるISPは、エニーキャストを単にGoogle以外の誰かの制御下にある他のマシンにルーティングするように指示できます。 2014年にトルコで起こったように。台湾にも同様の計画があると主張されています。
イランはすでにトルコの1年前にこれを行っていました。イランのISPは、ルーティングされたすべてのDNS/UDPトラフィックを傍受し、イランの制御下にあるマシンからそれに応答します。興味深いことに、ダミーのTCP（sic！）パケットがまだ元のマシンに渡されるため、これは非常に適切に実行されていないようです。
（Cloudflareの1.1.1.1サービスでも同じことが起こりますが、政治的および検閲上の理由からではなく、人間の怠惰と愚かさのためです。テストIPアドレスまたは非公式のエクストラプライベートIPアドレス範囲として、人々のプログラミングによって長い間悪用されてきましたルータなど）。
もちろん、DNSトラフィックが自分のマシンを直接ISPにではなくVPN経由で離れるように調整すると、これら3つすべてが変化します。トラフィックはVPN経由で別の国の別のGoogleマシンに送信され、別の送信元IPアドレスからバックエンドクエリが送信され、ISPによって8.8.8.8にルーティングされません。
DNSサービスで別の国にいるかのように見えることの欠点は、2010年にGoogle Public DNSを使用しているオーストラリア人が発見したように、別の国にいるかのように見えることです。 CDNは、はるかに離れたローカルではないコンテンツHTTPサーバーに1つを誘導します。低価格または無料であるが、自分の国だけにあるサービスは、代わりに高価なコンテンツHTTPサーバーから突然提供されています。
参考文献
- スティーブン・カーステンセン（2014-03-29）。 トルコでインターセプトされたGoogleのパブリックDNS。 Googleセキュリティ。
- キーレン・マッカーシー（2017-05-11）。 " HiNetを支持してGoogleのパブリックDNSをブロックする台湾政府 "。 レジスタ。
- ダン・ウォーン（2010-05-19）。 " Google DNS/OpenDNSを使用するのは悪い考えです "。 APC Magazine。
- Aryan et al。 （2013-08）。 イランのインターネット検閲：初見。
- https://Twitter.com/billplein/status/981307410643148801
- https://news.ycombinator.com/item?id=1672807
- https://news.ycombinator.com/item?id=16728329
- https://news.ycombinator.com/item?id=16729845
要するに、あなたはMITMされています。あなたが直面している検閲は、8.8.8.8に向けられたDNSリクエストに対して何かを行っているため、正規でない応答が返されます。これを達成するには多くの方法があり、さまざまなエンティティがさまざまな方法でこの検閲を実行します。よく見るには、お気に入りのパケットキャプチャツール（Wiresharkまたはtcpdump）を使用してください。
デモンストレーションとして、「www.google.com」のアドレスを8.8.8.8にあるGoogleのDNSサーバーにクエリしているところをキャプチャーしました。
Wiresharkのスクリーンショットにあるように、私のコンピューターはDNSサーバーに2つのDNSクエリを送信します。1つはAレコード（IPv4アドレス）用で、もう1つはAAAAレコード（IPv6アドレス）用です。リクエストごとに、3つの応答が受信されました。最初の2つの応答には偽のアドレスが含まれており、興味深いことに、AAAAクエリの最初の2つの応答には回答にAレコードが含まれています。これは明らかに不正な形式の応答です。各リクエストの3番目と最後の応答には、www.google.comの実際のIPアドレスが含まれています。 nslookupツールは何も知らず、各要求の最初の応答を受け入れ、それらのアドレスを表示しました。
これは、私の国家検閲官が何をしているのかを示唆しています。明らかに、それらは完全に8.8.8.8へのネットワークトラフィックをブロックしていません。代わりに、そのようなトラフィックを監視し、ブロックされたドメインに対するDNS要求が見つかると、検閲者は偽の応答を挿入します。適切なAAAA応答を作成するために検閲を煩わすことはできません。したがって、不正な応答になります。実際のDNSサーバーからの本物の応答もドロップされません。ただし、初期の偽の応答は、DNS要求を行ったクライアントをだまして偽のアドレスを受け入れるのに十分です。
あなたの検閲者は似たようなことをしているかもしれませんし、まったく違うことをしているかもしれません。いくつかのパケットキャプチャを取得します。詳細を確認できる場合があります。
これを回避する方法に関しては、実用的な答えはおそらく DNSCrypt Proxy または Stubby などのローカルの暗号化されたDNSプロキシです。これらのツールはコンピューター上でDNSサーバーを実行し、それらに向けられたDNS要求は暗号化され、暗号化プロトコルを理解するDNSサーバーに送信されます。このようにして、検閲者は要求がどのドメインに対するものかを知ることができず、応答を偽造することができません。ただし、検閲者はこれらのサーバーを完全にブロックできます。
（全国的な検閲を回避しようとしている場合は、DNSポイズニングを倒すだけでは不十分な場合があります。場合によっては、さまざまなツールを使用する必要があります。）
Linuxを実行しているので、本格的なVPNなしでこれを回避する簡単な方法は、SSHチューニングです。中立でフィルタリングされていない場所にあるサーバーでアカウントを設定または取得できる場合は、いくつかのコマンドを使用して、SSHを使用してその場所にトラフィックをトンネルできます。ポート53のDNSトラフィックとリモートマシンを介したWebトラフィックの両方をトンネリングできます。
Amazon WebサービスやGoogle Compute Engineインスタンスを使用することも、通常のリモートvpsを使用することもできます。
https://www.ssh.com/ssh/tunneling/example#sec-What-Is-SSH-Port-Forwarding-aka-SSH-Tunneling