DNS の名前解決は速くなるかもしれませんが、その後の接続先が遠くなって遅くなるかもしれません。 プライバシー重視なら切り替えて行っていいかもしれませんが、速度のために切り替えるのはちょっと待ってください。

Google Public DNS も初期の頃は同じ問題があったので、時間が経てば解決するような気がしますが、CDN を使っているサイトが遅くなる可能性があります。

以下、あるホストからの実測。 ここには結果を載せませんが、traceroute もしてみると、遠くなっているのがわかります。

DNS の正引き

DNS の応答は速いです。 これはうたい文句通りです。

Query time のところがかかった時間です。

% dig www.google.com @1.1.1.1

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.google.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13150
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1536
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         54      IN      A       172.217.194.99
www.google.com.         54      IN      A       172.217.194.103
www.google.com.         54      IN      A       172.217.194.104
www.google.com.         54      IN      A       172.217.194.105
www.google.com.         54      IN      A       172.217.194.106
www.google.com.         54      IN      A       172.217.194.147

;; Query time: 1 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Apr 04 21:21:57 JST 2018
;; MSG SIZE  rcvd: 139
% dig www.google.com @8.8.8.8

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25482
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         299     IN      A       172.217.161.228

;; Query time: 37 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Apr 04 21:22:06 JST 2018
;; MSG SIZE  rcvd: 59

ping 応答

2桁遅いです。 複数帰ってきていた他のIPアドレスも同じくらいでした。

% ping -c 5 172.217.194.99
PING 172.217.194.99 (172.217.194.99) 56(84) bytes of data.
64 bytes from 172.217.194.99: icmp_seq=1 ttl=44 time=79.3 ms
64 bytes from 172.217.194.99: icmp_seq=2 ttl=44 time=79.2 ms
64 bytes from 172.217.194.99: icmp_seq=3 ttl=44 time=79.4 ms
64 bytes from 172.217.194.99: icmp_seq=4 ttl=44 time=79.4 ms
64 bytes from 172.217.194.99: icmp_seq=5 ttl=44 time=79.2 ms

--- 172.217.194.99 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 79.264/79.348/79.441/0.364 ms
% ping -c 5 172.217.161.228
PING 172.217.161.228 (172.217.161.228) 56(84) bytes of data.
64 bytes from 172.217.161.228: icmp_seq=1 ttl=55 time=0.833 ms
64 bytes from 172.217.161.228: icmp_seq=2 ttl=55 time=0.742 ms
64 bytes from 172.217.161.228: icmp_seq=3 ttl=55 time=0.990 ms
64 bytes from 172.217.161.228: icmp_seq=4 ttl=55 time=0.800 ms
64 bytes from 172.217.161.228: icmp_seq=5 ttl=55 time=0.736 ms

--- 172.217.161.228 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.736/0.820/0.990/0.094 ms

まとめ

DNS 応答のような最初の少しの部分が速くなるよりも、実際の通信部分が遅くなる方が影響が大きいと思うので、 1.1.1.1 を使うのはまだ早いかもしれません。

Google Public DNS も初期の頃は同じ問題があったと記憶しているので、 CDN もやっている Cloudflare が対応しないとは思えないので、時間が経てば解決するのではないでしょうか。

別のインパクト

IP アドレスで証明書が発行されることはないと思っていたので、 https://1.1.1.1/ が正規の証明書で繋がるというのに驚きました。

これで DNS over HTTPS の最初の DNS サーバーのホスト名の解決問題が解消するので、 DNS over HTTPS が使われることが増えるかもしれません。 (ちなみに https://8.8.8.8/CN=*.c.docs.google.com の証明書で、普通にブラウザーで開くとエラーになるようなので、ちゃんと証明書の検証をする DNS over HTTPS クライアントだと使えなさそうです。)

Disqus Comments

Kazuhiro NISHIYAMA

Ruby のコミッターとかやってます。 フルスタックエンジニア(って何?)かもしれません。 About znzに主なアカウントをまとめました。

znz znz


Published