JPNIC Blog JPNIC

1.1.1.1 を DNS over HTTPS で試す

tech_team 

2018年4月、APNICとCloudflare社が共同でパブリックDNSサービスを開始しました。

1.1.1.1 — the Internet’s Fastest, Privacy-First DNS Resolver
(HTMLソースでもアピールしてますね)

使用するには、各種OSで問い合わせ先DNSサーバに 1.1.1.1 を使用するように設定すれば利用可能です。以下、Ubuntu Linux を用いて試してみましたのでご紹介します。

設定の前に、まずは名前解決できるかどうか確認します。

$ dig @1.1.1.1 www.apnic.net

;; QUESTION SECTION:
;www.apnic.net.			IN	A

;; ANSWER SECTION:
www.apnic.net.		194	IN	CNAME	www.apnic.net.cdn.cloudflare.net.
www.apnic.net.cdn.cloudflare.net. 194 IN A	104.20.22.173
www.apnic.net.cdn.cloudflare.net. 194 IN A	104.20.36.173

;; Query time: 7 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Apr 25 16:25:26 JST 2018
;; MSG SIZE  rcvd: 117

特に問題なさそうです。脱線しますが www.apnic.net は cloudflare を利用しているようです。

次にリゾルバの設定をします。 /etc/resolv.conf に一行記述します。

nameserver 1.1.1.1

確認します。

$ dig www.nic.ad.jp

;; QUESTION SECTION:
;www.nic.ad.jp.			IN	A

;; ANSWER SECTION:
www.nic.ad.jp.		300	IN	A	192.41.192.145

;; Query time: 27 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Apr 25 16:28:42 JST 2018
;; MSG SIZE  rcvd: 58

こちらも問題なく名前解決できました。

パブリックDNSとして 1.1.1.1 を利用するだけなら、これだけで終わりなのですが、利用可能なサービスとして DNS over HTTPS (DoH) もありますので試してみましょう。

1.1.1.1 のオフィシャル(?)クライアントとして 、 cloudflared というものが紹介されています。しかしこれは、 Cloudflare社 が提供している webサービス用のアプリケーションで、DoH専用というわけではないため今回は使用しません。代わりに dnscrypt-proxy というプログラムを使用します。

この dnscrypt-proxy は、元々 DNSCrypt という独自のDNS暗号化プロトコルを実装したものですが、最近のバージョンで DoH がサポートされました。

以下の場所からダウンロードし、展開します。

https://github.com/jedisct1/dnscrypt-proxy/releases/latest

$ wget -q https://github.com/jedisct1/dnscrypt-proxy/releases/download/2.0.10/dnscrypt-proxy-linux_x86_64-2.0.10.tar.gz
$ tar zxf dnscrypt-proxy-linux_x86_64-2.0.10.tar.gz

設定ファイルを変更します。

$ cd linux-x86_64
$ cp example-dnscrypt-proxy.toml dnscrypt-proxy.toml
$ vi dnscrypt-proxy.toml
ipv6_servers = true
dnscrypt_servers = false
doh_servers = true
server_names = ['cloudflare']

IPv6の問い合わせを有効にしてプロトコルを DoHのみにしています。また、参照先のキャッシュサーバとしてGoogle Public DNS も利用できますが、今回は cloudflare に限定します。

編集が終わったら起動します。

$ sudo ./dnscrypt-proxy

動作を確認してみます。

$ dig @127.0.0.1 www.nic.ad.jp

;; QUESTION SECTION:
;www.nic.ad.jp.			IN	A

;; ANSWER SECTION:
www.nic.ad.jp.		599	IN	A	192.41.192.145

;; Query time: 78 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Apr 25 16:44:46 JST 2018
;; MSG SIZE  rcvd: 71

無事引けました。port 53 ではなく port 443 が使われていることも確認します。tcpdump を起動し DNSを引いてみます。

$ sudo tcpdump -i wlp3s0 -n port 53 or port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:53:07.839399 IP 192.168.0.78.58794 > 1.0.0.1.443: Flags [S], seq 2130288138, win 29200, options [mss 1460,sackOK,TS val 1398542579 ecr 0,nop,wscale 7], length 0
16:53:07.859444 IP 1.0.0.1.443 > 192.168.0.78.58794: Flags [S.], seq 2047449329, ack 2130288139, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 10], length 0
16:53:07.859518 IP 192.168.0.78.58794 > 1.0.0.1.443: Flags [.], ack 1, win 229, length 0
16:53:07.859747 IP 192.168.0.78.58794 > 1.0.0.1.443: Flags [P.], seq 1:192, ack 1, win 229, length 191
16:53:07.870894 IP 1.0.0.1.443 > 192.168.0.78.58794: Flags [.], ack 192, win 30, length 0
16:53:07.876035 IP 1.0.0.1.443 > 192.168.0.78.58794: Flags [.], seq 1:1461, ack 192, win 30, length 1460
16:53:07.876063 IP 192.168.0.78.58794 > 1.0.0.1.443: Flags [.], ack 1461, win 251, length 0
16:53:07.876082 IP 1.0.0.1.443 > 192.168.0.78.58794: Flags [P.], seq 1461:2885, ack 192, win 30, length 1424
16:53:07.876095 IP 192.168.0.78.58794 > 1.0.0.1.443: Flags [.], ack 2885, win 274, length 0
16:53:07.905507 IP 192.168.0.78.58794 > 1.0.0.1.443: Flags [P.], seq 192:285, ack 2885, win 274, length 93
16:53:07.912123 IP 1.0.0.1.443 > 192.168.0.78.58794: Flags [P.], seq 2885:2936, ack 285, win 30, length 51
16:53:07.912168 IP 1.0.0.1.443 > 192.168.0.78.58794: Flags [P.], seq 2936:3005, ack 285, win 30, length 69
16:53:07.912198 IP 192.168.0.78.58794 > 1.0.0.1.443: Flags [.], ack 3005, win 274, length 0
16:53:07.912374 IP 192.168.0.78.58794 > 1.0.0.1.443: Flags [P.], seq 285:378, ack 3005, win 274, length 93
16:53:07.916913 IP 192.168.0.78.58794 > 1.0.0.1.443: Flags [P.], seq 378:687, ack 3005, win 274, length 309
16:53:07.921243 IP 1.0.0.1.443 > 192.168.0.78.58794: Flags [P.], seq 3005:3043, ack 378, win 30, length 38
16:53:07.925262 IP 1.0.0.1.443 > 192.168.0.78.58794: Flags [P.], seq 3043:3085, ack 687, win 31, length 42
16:53:07.925297 IP 1.0.0.1.443 > 192.168.0.78.58794: Flags [P.], seq 3085:3470, ack 687, win 31, length 385
16:53:07.925317 IP 1.0.0.1.443 > 192.168.0.78.58794: Flags [P.], seq 3470:3508, ack 687, win 31, length 38
16:53:07.925411 IP 192.168.0.78.58794 > 1.0.0.1.443: Flags [.], ack 3508, win 297, length 0

通信先が1.1.1.1ではなく冗長アドレスの 1.0.0.1 ではありますが port 443 宛と通信しており port 53 は使われていないことが分かります。(サービス用のIPアドレスは 1.1.1.1、1.0.0.1、2606:4700:4700::1111、2606:4700:4700::1001 です)

というわけで簡単ではありますが DNS over HTTPS を動かしてみたというご紹介でした。IETF の doh WGでは標準化に向け作業が進んでいます。ご紹介の通り、running codeとしてもいくつかの実装がすでに存在している状況です。昨今のプライバシーに関する話題も盛り上がっており、今後も注目すべき技術の一つだと思います。

この記事を評価してください

この記事は役に立ちましたか?
記事の改善点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、 お問い合わせ先 をご利用ください。