DNS 運用のさまざまな側面については、著者がすでに多くの記事で繰り返し触れています。 ブログの一部として公開されました。 同時に、この主要なインターネット サービスのセキュリティを向上させることに常に重点が置かれてきました。

最近まで、DNS トラフィックの明らかな脆弱性にもかかわらず、コンテンツに広告を埋め込むことで収入を増やそうとするプロバイダー側の悪意のある行為、政府のセキュリティ機関、検閲によって、依然としてほとんどの部分が平文で送信されています。単なる犯罪者だけでなく、そのプロセス は、DNSSEC/DANE、DNScrypt、DNS-over-TLS、DNS-over-HTTPS などのさまざまなテクノロジーが存在するにもかかわらず、停滞しました。 また、サーバー ソリューション (およびその一部は非常に長い間存在しているもの) が広く知られ、利用できるようになったとしても、クライアント ソフトウェアからのサポートにはまだ不十分な点が多く残されています。
幸いなことに、状況は変わりつつあります。 特に、人気のある Firefox ブラウザの開発者は、 デフォルトでサポートモードを有効にする計画について (DoH) すぐに。 これは WWW ユーザーの DNS トラフィックを上記の脅威から保護するのに役立ちますが、新たな脅威が発生する可能性があります。
1. DNS-over-HTTPS の問題
一見すると、インターネット ソフトウェアへの DNS-over-HTTPS の大量導入の始まりは、肯定的な反応しか引き起こしません。 しかし、よく言われるように、悪魔は細部に宿ります。
DoH の普及範囲を制限する最初の問題は、DoH が Web トラフィックのみに焦点を当てていることです。 実際、DoH のベースとなる HTTP プロトコルとその現在のバージョン HTTP/2 は、WWW の基礎です。 しかし、インターネットは単なるウェブではありません。 電子メール、さまざまなインスタント メッセンジャー、ファイル転送システム、マルチメディア ストリーミングなど、HTTP を使用しない人気のあるサービスは数多くあります。 したがって、DoH の多くが万能薬として認識しているにもかかわらず、ブラウザ テクノロジ以外には追加の (そして不必要な) 努力なしには適用できないことが判明しました。 ちなみに、安全な標準 TLS プロトコルで標準 DNS トラフィックのカプセル化を実装する DNS-over-TLS は、この役割のより価値のある候補のように見えます。
XNUMX 番目の問題は、XNUMX 番目の問題よりも潜在的にはるかに重大ですが、ブラウザ設定で指定された単一の DoH サーバーの使用を優先して、DNS の固有の分散化が設計により実際に放棄されていることです。 特に、Mozilla は Cloudflare のサービスを使用することを推奨しています。 同様のサービスは、他の著名なインターネット界の人物、特に Google によっても開始されました。 現在提案されている形式での DNS-over-HTTPS の実装は、最大規模のサービスに対するエンド ユーザーの依存度を高めるだけであることがわかりました。 DNS クエリの分析によって提供される情報によって、そのクエリに関するさらに多くのデータが収集され、その精度と関連性が向上することは周知の事実です。
この点において、著者は、DNS-over-HTTPS ではなく、普遍的で安全で、インターネットのさらなる集中化を助長しない手段として、DNSSEC/DANE とともに DNS-over-TLS の大規模実装を支持し続けています。 DNS トラフィックのセキュリティを確保します。 残念ながら、明らかな理由により、DoH 代替手段のサポートをクライアント ソフトウェアに迅速に大量に導入することは期待できず、それは依然としてセキュリティ テクノロジ愛好家の領域です。
しかし、今では DoH があるのですから、企業による潜在的な監視を自社のサーバーを介して自社の DNS-over-HTTPS サーバーに逃れてから、DoH を使用してみてはいかがでしょうか?
2. DNS-over-HTTPS プロトコル
基準で見ると DNS-over-HTTPS プロトコルについて説明すると、これが実際には、標準の DNS パッケージを HTTP/2 プロトコルでカプセル化できる Web API であることがわかります。 これは、特別な HTTP ヘッダーと、送信される DNS データのバイナリ形式の変換を通じて実装されます (「. および後続のドキュメント)を、送信および受信できる形式に変換し、必要なメタデータを操作できるようにします。
標準に従って、HTTP/2 と安全な TLS 接続のみがサポートされます。
DNS リクエストの送信は、標準の GET メソッドと POST メソッドを使用して実行できます。 最初のケースでは、リクエストは Base64URL でエンコードされた文字列に変換され、XNUMX 番目のケースでは、バイナリ形式の POST リクエストの本文を通じて変換されます。 この場合、DNS 要求と応答中に特別な MIME データ タイプが使用されます。 アプリケーション/DNSメッセージ.
root@eprove:~ # curl -H 'accept: application/dns-message' 'https://my.domaint/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE' -v
* Trying 2001:100:200:300::400:443...
* TCP_NODELAY set
* Connected to eprove.net (2001:100:200:300::400) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=my.domain
* start date: Jul 22 00:07:13 2019 GMT
* expire date: Oct 20 00:07:13 2019 GMT
* subjectAltName: host "my.domain" matched cert's "my.domain"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x801441000)
> GET /dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE HTTP/2
> Host: eprove.net
> User-Agent: curl/7.65.3
> accept: application/dns-message
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< server: h2o/2.3.0-beta2
< content-type: application/dns-message
< cache-control: max-age=86274
< date: Thu, 12 Sep 2019 13:07:25 GMT
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< content-length: 45
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 45)
* stopped the pause stream!
* Connection #0 to host eprove.net left intactタイトルにも注目 キャッシュ制御: Web サーバーからの応答に含まれます。 パラメータで 最大年齢 返される DNS レコードの TTL 値 (または、それらのセットが返される場合は最小値) が含まれます。
上記に基づいて、DoH サーバーの機能はいくつかの段階で構成されます。
- HTTPリクエストを受信します。 これが GET の場合は、base64URL エンコードからパケットをデコードします。
- このパケットを DNS サーバーに送信します。
- DNSサーバーから応答を取得する
- 受信したレコードの最小 TTL 値を見つけます。
- HTTP 経由でクライアントに応答を返します。
3. 独自の DNS-over-HTTPS サーバー
独自の DNS-over-HTTPS サーバーを実行する最も簡単、最速、効果的な方法は、HTTP/2 Web サーバーを使用することです。 、それについては著者がすでに簡単に書いています(「」を参照)«)。
この選択は、H2O 自体に統合されたインタープリタを使用して、独自の DoH サーバーのすべてのコードを完全に実装できるという事実によって裏付けられます。 。 DNS サーバーとデータを交換するには、標準ライブラリに加えて、(mrbgem) ソケット ライブラリが必要です。幸いなことに、これは、H2O 2.3.0-beta2 の現在の開発バージョンにすでに含まれています。 FreeBSD ポート内。 ただし、リポジトリを複製することで以前のバージョンに追加することは難しくありません。 カタログへ /deps コンパイル前。
root@beta:~ # uname -v
FreeBSD 12.0-RELEASE-p10 GENERIC
root@beta:~ # cd /usr/ports/www/h2o
root@beta:/usr/ports/www/h2o # make extract
===> License MIT BSD2CLAUSE accepted by the user
===> h2o-2.2.6 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by h2o-2.2.6 for building
===> Extracting for h2o-2.2.6.
=> SHA256 Checksum OK for h2o-h2o-v2.2.6_GH0.tar.gz.
===> h2o-2.2.6 depends on file: /usr/local/bin/ruby26 - found
root@beta:/usr/ports/www/h2o # cd work/h2o-2.2.6/deps/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # git clone https://github.com/iij/mruby-socket.git
Клонирование в «mruby-socket»…
remote: Enumerating objects: 385, done.
remote: Total 385 (delta 0), reused 0 (delta 0), pack-reused 385
Получение объектов: 100% (385/385), 98.02 KiB | 647.00 KiB/s, готово.
Определение изменений: 100% (208/208), готово.
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # ll
total 181
drwxr-xr-x 9 root wheel 18 12 авг. 16:09 brotli/
drwxr-xr-x 2 root wheel 4 12 авг. 16:09 cloexec/
drwxr-xr-x 2 root wheel 5 12 авг. 16:09 golombset/
drwxr-xr-x 4 root wheel 35 12 авг. 16:09 klib/
drwxr-xr-x 2 root wheel 5 12 авг. 16:09 libgkc/
drwxr-xr-x 4 root wheel 26 12 авг. 16:09 libyrmcds/
drwxr-xr-x 13 root wheel 32 12 авг. 16:09 mruby/
drwxr-xr-x 5 root wheel 11 12 авг. 16:09 mruby-digest/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-dir/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-env/
drwxr-xr-x 4 root wheel 9 12 авг. 16:09 mruby-errno/
drwxr-xr-x 5 root wheel 14 12 авг. 16:09 mruby-file-stat/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-iijson/
drwxr-xr-x 5 root wheel 11 12 авг. 16:09 mruby-input-stream/
drwxr-xr-x 6 root wheel 11 12 авг. 16:09 mruby-io/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-onig-regexp/
drwxr-xr-x 4 root wheel 10 12 авг. 16:09 mruby-pack/
drwxr-xr-x 5 root wheel 10 12 авг. 16:09 mruby-require/
drwxr-xr-x 6 root wheel 10 12 сент. 16:10 mruby-socket/
drwxr-xr-x 2 root wheel 9 12 авг. 16:09 neverbleed/
drwxr-xr-x 2 root wheel 13 12 авг. 16:09 picohttpparser/
drwxr-xr-x 2 root wheel 4 12 авг. 16:09 picotest/
drwxr-xr-x 9 root wheel 16 12 авг. 16:09 picotls/
drwxr-xr-x 4 root wheel 8 12 авг. 16:09 ssl-conservatory/
drwxr-xr-x 8 root wheel 18 12 авг. 16:09 yaml/
drwxr-xr-x 2 root wheel 8 12 авг. 16:09 yoml/
root@beta:/usr/ports/www/h2o/work/h2o-2.2.6/deps # cd ../../..
root@beta:/usr/ports/www/h2o # make install clean
...Web サーバーの構成は通常標準です。
root@beta:/usr/ports/www/h2o # cd /usr/local/etc/h2o/
root@beta:/usr/local/etc/h2o # cat h2o.conf
# this sample config gives you a feel for how h2o can be used
# and a high-security configuration for TLS and HTTP headers
# see https://h2o.examp1e.net/ for detailed documentation
# and h2o --help for command-line options and settings
# v.20180207 (c)2018 by Max Kostikov http://kostikov.co e-mail: max@kostikov.co
user: www
pid-file: /var/run/h2o.pid
access-log:
path: /var/log/h2o/h2o-access.log
format: "%h %v %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i""
error-log: /var/log/h2o/h2o-error.log
expires: off
compress: on
file.dirlisting: off
file.send-compressed: on
file.index: [ 'index.html', 'index.php' ]
listen:
port: 80
listen:
port: 443
ssl:
cipher-suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
cipher-preference: server
dh-file: /etc/ssl/dhparams.pem
certificate-file: /usr/local/etc/letsencrypt/live/eprove.net/fullchain.pem
key-file: /usr/local/etc/letsencrypt/live/my.domain/privkey.pem
hosts:
"*.my.domain":
paths: &go_tls
"/":
redirect:
status: 301
url: https://my.domain/
"my.domain:80":
paths: *go_tls
"my.domain:443":
header.add: "Strict-Transport-Security: max-age=15768000; includeSubDomains; preload"
paths:
"/dns-query":
mruby.handler-file: /usr/local/etc/h2o/h2odoh.rb唯一の例外は URL ハンドラーです / dns-query これは、mruby で書かれ、ハンドラー オプションを通じて呼び出される DNS-over-HTTPS サーバーが実際に担当します。 mruby.ハンドラーファイル.
root@beta:/usr/local/etc/h2o # cat h2odoh.rb
# H2O HTTP/2 web server as DNS-over-HTTP service
# v.20190908 (c)2018-2019 Max Kostikov https://kostikov.co e-mail: max@kostikov.co
proc {|env|
if env['HTTP_ACCEPT'] == "application/dns-message"
case env['REQUEST_METHOD']
when "GET"
req = env['QUERY_STRING'].gsub(/^dns=/,'')
# base64URL decode
req = req.tr("-_", "+/")
if !req.end_with?("=") && req.length % 4 != 0
req = req.ljust((req.length + 3) & ~3, "=")
end
req = req.unpack1("m")
when "POST"
req = env['rack.input'].read
else
req = ""
end
if req.empty?
[400, { 'content-type' => 'text/plain' }, [ "Bad Request" ]]
else
# --- ask DNS server
sock = UDPSocket.new
sock.connect("localhost", 53)
sock.send(req, 0)
str = sock.recv(4096)
sock.close
# --- find lowest TTL in response
nans = str[6, 2].unpack1('n') # number of answers
if nans > 0 # no DNS failure
shift = 12
ttl = 0
while nans > 0
# process domain name compression
if str[shift].unpack1("C") < 192
shift = str.index("x00", shift) + 5
if ttl == 0 # skip question section
next
end
end
shift += 6
curttl = str[shift, 4].unpack1('N')
shift += str[shift + 4, 2].unpack1('n') + 6 # responce data size
if ttl == 0 or ttl > curttl
ttl = curttl
end
nans -= 1
end
cc = 'max-age=' + ttl.to_s
else
cc = 'no-cache'
end
[200, { 'content-type' => 'application/dns-message', 'content-length' => str.size, 'cache-control' => cc }, [ str ] ]
end
else
[415, { 'content-type' => 'text/plain' }, [ "Unsupported Media Type" ]]
end
}この場合、ローカル キャッシュ サーバーが DNS パケットの処理を担当することに注意してください。 標準の FreeBSD ディストリビューションから。 セキュリティの観点からは、これが最適なソリューションです。 ただし、交換を妨げるものは何もありません ローカルホスト 使用する予定の別の DNS アドレスに変更します。
root@beta:/usr/local/etc/h2o # local-unbound verison
usage: local-unbound [options]
start unbound daemon DNS resolver.
-h this help
-c file config file to read instead of /var/unbound/unbound.conf
file format is described in unbound.conf(5).
-d do not fork into the background.
-p do not create a pidfile.
-v verbose (more times to increase verbosity)
Version 1.8.1
linked libs: mini-event internal (it uses select), OpenSSL 1.1.1a-freebsd 20 Nov 2018
linked modules: dns64 respip validator iterator
BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl
root@eprove:/usr/local/etc/h2o # sockstat -46 | grep unbound
unbound local-unbo 69749 3 udp6 ::1:53 *:*
unbound local-unbo 69749 4 tcp6 ::1:53 *:*
unbound local-unbo 69749 5 udp4 127.0.0.1:53 *:*
unbound local-unbo 69749 6 tcp4 127.0.0.1:53 *:*残っているのは、H2O を再起動して、何が起こるかを確認することだけです。
root@beta:/usr/local/etc/h2o # service h2o restart
Stopping h2o.
Waiting for PIDS: 69871.
Starting h2o.
start_server (pid:70532) starting now...4.テスト
そこで、テストリクエストを再度送信し、ユーティリティを使用してネットワークトラフィックを調べて結果を確認してみましょう tcpdump.
root@beta/usr/local/etc/h2o # curl -H 'accept: application/dns-message' 'https://my.domain/dns-query?dns=q80BAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE'
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
...
root@beta:~ # tcpdump -n -i lo0 udp port 53 -xx -XX -vv
tcpdump: listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes
16:32:40.420831 IP (tos 0x0, ttl 64, id 37575, offset 0, flags [none], proto UDP (17), length 57, bad cksum 0 (->e9ea)!)
127.0.0.1.21070 > 127.0.0.1.53: [bad udp cksum 0xfe38 -> 0x33e3!] 43981+ A? example.com. (29)
0x0000: 0200 0000 4500 0039 92c7 0000 4011 0000 ....E..9....@...
0x0010: 7f00 0001 7f00 0001 524e 0035 0025 fe38 ........RN.5.%.8
0x0020: abcd 0100 0001 0000 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01 mple.com.....
16:32:40.796507 IP (tos 0x0, ttl 64, id 37590, offset 0, flags [none], proto UDP (17), length 73, bad cksum 0 (->e9cb)!)
127.0.0.1.53 > 127.0.0.1.21070: [bad udp cksum 0xfe48 -> 0x43fa!] 43981 q: A? example.com. 1/0/0 example.com. A 93.184.216.34 (45)
0x0000: 0200 0000 4500 0049 92d6 0000 4011 0000 ....E..I....@...
0x0010: 7f00 0001 7f00 0001 0035 524e 0035 fe48 .........5RN.5.H
0x0020: abcd 8180 0001 0001 0000 0000 0765 7861 .............exa
0x0030: 6d70 6c65 0363 6f6d 0000 0100 01c0 0c00 mple.com........
0x0040: 0100 0100 0151 8000 045d b8d8 22 .....Q...].."
^C
2 packets captured
23 packets received by filter
0 packets dropped by kernel出力は、リクエストがアドレスを解決する方法を示しています。 example.com が受信され、DNS サーバーによって正常に処理されました。
あとは、Firefox ブラウザでサーバーをアクティブにするだけです。 これを行うには、構成ページでいくつかの設定を変更する必要があります 約:設定.

まず、これはブラウザが DNS 情報をリクエストする API のアドレスです。 network.trr.uri。 また、DNS にアクセスせずにブラウザ自体を使用して安全な IP 解決を行うために、この URL からドメイン IP を指定することをお勧めします。 network.trr.bootstrapAddress。 そして最後にパラメータ自体 ネットワーク.trr.モード DoH の使用を含む。 値を「3」に設定すると、ブラウザは名前解決に DNS-over-HTTPS のみを使用するように強制されます。一方、より信頼性が高く安全な「2」は DoH を優先し、標準の DNS ルックアップをフォールバック オプションとして残します。
5 利益!
記事は役に立ちましたか? それでは、恥ずかしがらずに、寄付フォーム(下記)を通じてお金で支援してください。
出所: habr.com
