27 KiB
title, icon, description
| title | icon | description |
|---|---|---|
| DNSの概要 | material/dns | ドメインネームシステム（DNS）は「インターネットの電話帳」であり、ブラウザが探しているウェブサイトを見つけるのに役立ちます。 |
ドメイン・ネーム・システムは「インターネットの電話帳」です。 DNSはドメイン名をIPアドレスに変換しており、分散化されたサーバーのネットワークを通じ、ブラウザやその他のサービスはインターネットリソースをロードできるようになります。
DNSとは？
ウェブサイトにアクセスすると、数値のアドレスが返されます。 たとえば、 privacyguides.orgにアクセスすると、アドレス 192.98.54.105 が返されます。
DNSはインターネットの初期から存在しています。 DNSサーバーとの間で行われるDNSリクエストは、一般的には暗号化されていません。 住宅向けの設定では、DHCP経由でISPからサーバーが既定されます。
暗号化されていないDNSリクエストは、転送中簡単に監視し、変更することができます。 世界のいくつかの地域では、ISPは原始的なDNSフィルタリングを行うよう命じられています。 ブロックされているドメインのIPアドレスをリクエストすると、サーバーは応答しないか、別のIPアドレスで応答することがあります。 DNSプロトコルは暗号化されていないため、ISPは（またはどのネットワークオペレーターも） ディープ・パケット・インスペクションによって 、リクエストを監視できます。 ISPは、どのDNSサーバーが使われているかに関係なく、共通の特徴に基づいてリクエストをブロックすることもできます。
以下では通常の暗号化されていないDNSと暗号化DNSを用いて、外部の観察者が何を見ることができるかを説明します。
暗号化されていないDNS
-
tshark（Wiresharkプロジェクトの一部）を使い、インターネットのパケットフローを監視、記録します。 このコマンドは指定されたルールに合致するパケットを記録します：tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8 -
dig（Linux、macOSなど）やnslookup（Windows）を使ってDNSルックアップを両方のサーバーに送ります。 ウェブブラウザなどのソフトウェアは暗号化DNSの使用が設定されていない限り、自動的にルックアップを行います。=== "LinuxとmacOS"
``` dig +noall +answer privacyguides.org @1.1.1.1 dig +noall +answer privacyguides.org @8.8.8.8 ```=== "Windows"
``` nslookup privacyguides.org 1.1.1.1 nslookup privacyguides.org 8.8.8.8 ``` -
次に結果を分析します：
=== "Wireshark"
``` wireshark -r /tmp/dns.pcap ```=== "tshark"
``` tshark -r /tmp/dns.pcap ```
上記のWiresharkのコマンドを実行すると、上のペインはフレームが表示され、下のペインには選択したフレームに関するすべてのデータが表示されます。 企業向けフィルタリング・監視ソリューション（政府機関が購入するようなもの）は人手を介さずこの手順を自動的に行い、フレームを集約し、ネットワーク監視者にとって有用な統計データを作成することができます。
| 番号 | 時間 | 参照元 | 宛先 | プロトコル | 長さ | 詳細 |
|---|---|---|---|---|---|---|
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | DNS | 104 | Standard query 0x58ba A privacyguides.org OPT |
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | DNS | 108 | Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT |
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | DNS | 104 | Standard query 0xf1a9 A privacyguides.org OPT |
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | DNS | 108 | Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
監視者はこれらのパケットをいずれも変更することができます。
「暗号化されたDNS」とは？
暗号化DNSにはいくつかのプロトコルがあり、最も一般的なものはDNSCrypt、DNS over TLSとDNS over HTTPSです。
DNSCrypt
DNSCryptはDNSクエリを暗号化する初期の方法の一つでした。 DNSCryptは443ポートで動作し、TCPやUDP通信プロトコルの両方で動作します。 DNSCryptはインターネット技術特別調査委員会（IETF）に提出されず、リクエストフォーコメンツ（RFC）のプロセスも経ていないため、一部の実装以外では広く使用されていません。 そのため、より人気のあるDNS over HTTPSに大部分が取って代わられています。
DNS over TLS (DoT)
DNS over TLSはDNS通信を暗号化するもう一つの方法でRFC 7858で定められています。 Android9、iOS14、Linuxではsystemd-resolvedのバージョン237で初めて対応されました。 DoTは複雑なプロトコルであり、実装によってRFCへの準拠が異なるため、近年ではDoTよりもDoHが選ばれるようになっています。 また、DoTはファイアウォールで簡単にブロックできる853ポートのみで動作しています。
DNS over HTTPS (DoH)
DNS over HTTPSはRFC8484で定められ、HTTP/2プロトコルでクエリをパッケージ化し、HTTPSによるセキュリティで保護します。 ウェブブラウザではFirefox60やChrome83で初めて対応されました。
DoHのネイティブ実装はiOS14、macOS11、Microsoft WindowsやAndroid13（ただし、デフォルトでは有効になりません）で登場しました。 一般的なLinuxデスクトップの対応はsystemdの実装を待っているため、サードパーティのソフトウェアをインストールする必要がまだあります。
OSでのネイティブサポート
Android
Android 9以降ではDNS over TLSをサポートしています。 設定は以下にて確認できます： 設定 → ネットワーク & インターネット → プライベートDNS.
Appleデバイス
最新バージョンのiOS、iPadOS、tvOS、macOSはDoTとDoHのどちらにも対応しています。 構成プロファイルもしくはDNS設定APIでどちらのプロトコルもネイティブ対応しています。
構成プロファイルまたはDNS設定APIを使ったアプリをインストールした後、DNS設定を選択することができます。 VPNが有効な場合、VPNトンネル内での名前解決にはVPNのDNS設定が使われ、システム全体の設定は使われません。
Appleは暗号化DNSプロファイルを作成するためのネイティブインターフェースを提供していません。 Secure DNS profile creatorは暗号化DNSプロファイルを作成するための非公式のツールですが、署名はされません。 署名されたプロファイルが推奨されます。署名はプロファイルの発信元を検証し、整合性を確かめるのに役立ちます。 署名された構成プロファイルは緑色の「検証済み」ラベルがつけられます。 コード署名の詳細についてはAbout Code Signingを参照してください。
Linux
多くのLinuxディストリビューションがDNSルックアップに使用しているsystemd-resolvedはまだDoHに対応していません。 DoHを使いたい場合、dnscrypt-proxyのようなプロキシをインストールし、システムリゾルバからのすべてのDNSクエリを受け取り、HTTPS経由で転送するように設定する必要があります。
外部からは何が見えるのか？
この例では、DoHリクエストを行った際に何が起きているか記録します：
-
まず、
tsharkを起動：tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1" -
次に、
curlでリクエストをします：curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org -
リクエストした後、CTRL+Cでパケットキャプチャを終了します。
-
Wiresharkで結果を分析します：
wireshark -r /tmp/dns_doh.pcap
暗号化された接続で発生するコネクション確立とTLSハンドシェイクを見ることができます。 その後の「アプリケーションデータ」パケットにはリクエストしたドメインや返されたIPアドレスは含まれていません。
なぜ暗号化DNSを使うべきではないのか？
インターネットフィルタリング（もしくは検閲）が行われている場所で、禁止されている情報源にアクセスするために、脅威モデルに基づいて考慮すべきことになる可能性はあります。 この目的のために暗号化DNSをつかうことは推奨しません。 代わりにTorやVPNを使ってください。 VPNを使っているのであれば、VPNのDNSサーバーを使う必要があります。 VPNを使うことは、ネットワークアクティビティのすべてをVPNに任せることになります。
DNSルックアップをする際、一般的には情報源にアクセスするためです。 以下では暗号化DNSを使ったとしてもブラウジングのアクティビティが開示される可能性のある方法について説明します：
IPアドレス
ブラウジングアクティビティを調べる最も単純な方法は、デバイスがアクセスしているIPアドレスを調べることです。 例えば、監視人がprivacyguides.orgのIPアドレスは198.98.54.105であることを知っていて、あなたのデバイスが198.98.54.105からのデータを要求している場合、あなたはPrivacy Guidesを見ている可能性が高いと分かります。
IPアドレスが少数のウェブサイトをホストしているサーバーにある場合にのみ有効です。 サイトが共有プラットフォーム（GitHub Pages、Cloudflare Pages、Netlify、WordPress、Bloggerなど）上でホストされている場合はあまり役に立ちません。 また、サーバーがリバースプロキシの後段にホストされている場合も役に立ちません。リバースプロキシを使うことは現代のインターネットでは一般的な方法です。
サーバー名表示（SNI）
サーバー名表示は一つのIPアドレスに多くのウェブサイトをホストしている際によく使われます。 Cloudflareのようなサービスや、DoS攻撃対策の場合もあります。
-
tsharkで再度キャプチャをします。 Privacy GuidesのIPアドレスのフィルタを追加したため、多くのパケットはキャプチャしません：tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105 -
https://privacyguides.orgにアクセスします。
-
ウェブサイトを訪れた後、CTRL + Cでパケットキャプチャを終了します。
-
次に結果を分析します：
wireshark -r /tmp/pg.pcap接続の確立の後、Privacy GuidesのウェブサイトのTLSハンドシェイクが表示されています。 5フレーム目のあたりにあります。 「Client Hello」があります。
-
各フィールドの隣にある三角形▸を展開します：
▸ Transport Layer Security ▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello ▸ Handshake Protocol: Client Hello ▸ Extension: server_name (len=22) ▸ Server Name Indication extension -
訪れたウェブサイトが開示しているSNIを見ることができます。
tsharkコマンドでは、サーバー名表示を含むすべてのパケットの値を直接見ることができます：tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
つまり「暗号化DNS」を使っていたとしても、SNIを通じてドメインが開示される可能性があるということです。 TLS v1.3プロトコルはこのような漏洩を防ぐEncrypted Client Helloがあります。
各国政府、特に中国やロシアはすでにTLS v1.3をブロックしているかその意向を示しています。 最近、ロシアはHTTP/3標準を使用する外国のウェブサイトをブロックし始めました。 HTTP/3の一部であるQUICプロトコルがClientHelloの暗号化を必要としているためです。
Online Certificate Status Protocol (OCSP)
ブラウザがブラウジングアクティビティを開示し得る、別の方法はOnline Certificate Status Protocolが挙げられます。 HTTPSのウェブサイトにアクセスする際、ブラウザはウェブサイトの証明書が失効していないか確認することがあります。 通常はHTTPプロトコル経由で行われ、暗号化されていません。
OCSPリクエストには一意な証明書のシリアル番号が含まれています。 その状態を確認するため「OCSPレスポンダー」に送られます。
ブラウザの動作をopensslコマンドでシミュレートすることができます。
-
サーバーの証明書を取得し、
sedコマンドで重要な部分を残し、ファイルに書き出します：openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 | sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert -
中間証明書を取得。 認証局（CA）は通常、証明書に直接署名せず、「中間」証明書を使います。
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 | sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert -
pg_and_intermediate.certの最初の証明書は実際にはStep1のサーバー証明書です。sedで最初のENDまでを削除します：sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \ /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert -
サーバー証明書のOCSPレスポンダーを取得します：
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.certPrivacy Guidesの証明書はLet's Encryptの証明書レスポンダーを示しています。 証明書の詳細をすべて確認する場合、以下のコマンドを実行します：
openssl x509 -text -noout -in /tmp/pg_server.cert -
パケットキャプチャを開始します：
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http" -
OCSPリクエストを行います：
openssl ocsp -issuer /tmp/intermediate_chain.cert \ -cert /tmp/pg_server.cert \ -text \ -url http://r3.o.lencr.org -
キャプチャの内容を確認します：
wireshark -r /tmp/pg_ocsp.pcap「OCSP」プロトコルには「Request」と「Response」の２つのパケットがあります。 「Request」については、各フィールドの隣にある三角形▸を展開することで「シリアル番号」を確認することができます：
▸ Online Certificate Status Protocol ▸ tbsRequest ▸ requestList: 1 item ▸ Request ▸ reqCert serialNumber「Response」についても「シリアル番号」を確認することができます：
▸ Online Certificate Status Protocol ▸ responseBytes ▸ BasicOCSPResponse ▸ tbsResponseData ▸ responses: 1 item ▸ SingleResponse ▸ certID serialNumber -
また、
tsharkでシリアル番号のパケットをフィルタすることもできます：tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
ネットワークの監視者が一般的に公開されているパブリック証明書を持っていれば、シリアル番号と証明書を照合することで、訪問しているサイトを特定することができます。 このプロセスは自動化することができ、IPアドレスとシリアル番号を関連付けることができます。 また、証明書の透明性のログからシリアル番号を確認することもできます。
Should I use encrypted DNS?
We made this flow chart to describe when you should use encrypted DNS:
graph TB
Start[Start] --> anonymous{Trying to be<br> anonymous?}
anonymous--> | Yes | tor(Use Tor)
anonymous --> | No | censorship{Avoiding<br> censorship?}
censorship --> | Yes | vpnOrTor(Use<br> VPN or Tor)
censorship --> | No | privacy{Want privacy<br> from ISP?}
privacy --> | Yes | vpnOrTor
privacy --> | No | obnoxious{ISP makes<br> obnoxious<br> redirects?}
obnoxious --> | Yes | encryptedDNS(Use<br> encrypted DNS<br> with 3rd party)
obnoxious --> | No | ispDNS{Does ISP support<br> encrypted DNS?}
ispDNS --> | Yes | useISP(Use<br> encrypted DNS<br> with ISP)
ispDNS --> | No | nothing(Do nothing)
Encrypted DNS with a third party should only be used to get around redirects and basic DNS blocking when you can be sure there won't be any consequences, or you're interested in a provider that does some rudimentary filtering.
List of recommended DNS servers{.md-button}
DNSSECとは？
Domain Name System Security Extensions (DNSSEC) is a feature of DNS that authenticates responses to domain name lookups. It does not provide privacy protections for those lookups, but rather prevents attackers from manipulating or poisoning the responses to DNS requests.
In other words, DNSSEC digitally signs data to help ensure its validity. In order to ensure a secure lookup, the signing occurs at every level in the DNS lookup process. As a result, all answers from DNS can be trusted.
The DNSSEC signing process is similar to someone signing a legal document with a pen; that person signs with a unique signature that no one else can create, and a court expert can look at that signature and verify that the document was signed by that person. These digital signatures ensure that data has not been tampered with.
DNSSEC implements a hierarchical digital signing policy across all layers of DNS. For example, in the case of a privacyguides.org lookup, a root DNS server would sign a key for the .org nameserver, and the .org nameserver would then sign a key for privacyguides.org’s authoritative nameserver.
Adapted from DNS Security Extensions (DNSSEC) overview by Google and DNSSEC: An Introduction by Cloudflare, both licensed under CC BY 4.0.
What is QNAME minimization?
A QNAME is a "qualified name", for example discuss.privacyguides.net. In the past, when resolving a domain name your DNS resolver would ask every server in the chain to provide any information it has about your full query. In this example below, your request to find the IP address for discuss.privacyguides.net gets asked of every DNS server provider:
| サーバー | 質問 | 回答 |
|---|---|---|
| ルートサーバー | What's the IP of discuss.privacyguides.net? | わかりません。.netのサーバーに聞いてみてください。 |
| .netのサーバー | What's the IP of discuss.privacyguides.net? | わかりません、Privacy Guidesのサーバーに聞いてください…。 |
| Privacy Guidesのサーバー | What's the IP of discuss.privacyguides.net? | 5.161.195.190! |
With "QNAME minimization," your DNS resolver now only asks for just enough information to find the next server in the chain. In this example, the root server is only asked for enough information to find the appropriate nameserver for the .net TLD, and so on, without ever knowing the full domain you're trying to visit:
| サーバー | 質問 | 回答 |
|---|---|---|
| ルートサーバー | What's the nameserver for .net? | Provides .net's server |
| .netのサーバー | What's the nameserver for privacyguides.net? | Provides Privacy Guides' server |
| Privacy Guidesのサーバー | What's the nameserver for discuss.privacyguides.net? | This server! |
| Privacy Guidesのサーバー | What's the IP of discuss.privacyguides.net? | 5.161.195.190 |
While this process can be slightly more inefficient, in this example neither the central root nameservers nor the TLD's nameservers ever receive information about your full query, thus reducing the amount of information being transmitted about your browsing habits. Further technical description is defined in RFC 7816.
What is EDNS Client Subnet (ECS)?
The EDNS Client Subnet is a method for a recursive DNS resolver to specify a subnetwork for the host or client which is making the DNS query.
It's intended to "speed up" delivery of data by giving the client an answer that belongs to a server that is close to them such as a content delivery network, which are often used in video streaming and serving JavaScript web apps.
This feature does come at a privacy cost, as it tells the DNS server some information about the client's location, generally your IP network. For example, if your IP address is 198.51.100.32 the DNS provider might share 198.51.100.0/24 with the authoritative server. Some DNS providers anonymize this data by providing another IP address which is approximately near your location.
If you have dig installed you can test whether your DNS provider gives EDNS information out to DNS nameservers with the following command:
dig +nocmd -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
Note that this command will contact Google for the test, and return your IP as well as EDNS client subnet information. If you want to test another DNS resolver you can specify their IP, to test 9.9.9.11 for example:
dig +nocmd @9.9.9.11 -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
If the results include a second edns0-client-subnet TXT record (like shown below), then your DNS server is passing along EDNS information. The IP or network shown after is the precise information which was shared with Google by your DNS provider.
o-o.myaddr.l.google.com. 60 IN TXT "198.51.100.32"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet 198.51.100.0/24"
;; Query time: 64 msec
;; SERVER: 9.9.9.11#53(9.9.9.11)
;; WHEN: Wed Mar 13 10:23:08 CDT 2024
;; MSG SIZE rcvd: 130