resolver

抓出正在使用的 DNS Server

在 Hacker News 上看到的方式：「Which DNS」，另外在「Show HN: Which DNS servers are you pointing to? (nameserve.rs)」這邊也有一些討論。

這個方式是去抓 DNS server 對外的 IP，像 HiNet 的 168.95.1.1 這種 DNS server 後面都有一堆 resolver，這個方式可以知道出去的 IP 是哪個，可以幫助分析 routing 之類的問題...

記得 Akamai 有類似的服務，不過查了一下沒找到之前有印象的那個，反倒是查到另外一組可以用的：「Introducing a New whoami Tool for DNS Resolver Information」。

AWS 推出 Route 53 Resolver Query Logs

AWS 推出可以讓你 debug 的功能：「Log your VPC DNS queries with Route 53 Resolver Query Logs」。

這個功能可以記錄 VPC 內的 DNS query：

然後也可以統計與分析：

主要是很多 debug 會需要 DNS query，但 AWS 上不太容易看到 DNS query 資訊 (常見的方式是自己另外架 DNS Resolver)，這個功能可以緩解這個問題...

Stripe 遇到 AWS 上 DNS Resolver 的限制

當量夠大就會遇到各種限制...

這次 Stripe 在描述 trouble shooting 的過程：「The secret life of DNS packets: investigating complex networks」。

其中一個頗有趣的架構是他們在每台主機上都有跑 Unbound，然後導去中央的 DNS Resolver，再決定導去 Consul 或是 AWS 的 DNS Resolver：

Unbound runs locally on every host as well as on the DNS servers.

然後他們發現偶而會有大量的 SERVFAIL：

接下來就是各種找問題的過程 (像是用 tcpdump 看情況，然後用 iptables 統計一些數字)，最後發現是卡在 AWS 的 DNS Resolver 在 60 秒內只回應了 61,385 packets，換算差不多是 1,023 packets/sec，這數字看起來就很雷：

During one of the 60-second collection periods the DNS server sent 257,430 packets to the VPC resolver. The VPC resolver replied back with only 61,385 packets, which averages to 1,023 packets per second. We realized we may be hitting the AWS limit for how much traffic can be sent to a VPC resolver, which is 1,024 packets per second per interface. Our next step was to establish better visibility in our cluster to validate our hypothesis.

在官方文件「Using DNS with Your VPC」這邊看到對應的說明：

Each Amazon EC2 instance limits the number of packets that can be sent to the Amazon-provided DNS server to a maximum of 1024 packets per second per network interface. This limit cannot be increased. The number of DNS queries per second supported by the Amazon-provided DNS server varies by the type of query, the size of response, and the protocol in use. For more information and recommendations for a scalable DNS architecture, see the Hybrid Cloud DNS Solutions for Amazon VPC whitepaper.

iptables 看到的量則是：

找到問題後，後面就是要找方法解決了... 他們給了一個只能算是不會有什麼副作用的 workaround，不過也的確想不到太好的解法。

因為是查詢 10.0.0.0/8 網段反解產生大量的查詢，所以就在各 server 上的 Unbound 上指定這個網段直接問 AWS 的 DNS Resolver，不需要往中央的 DNS Resolver 問，這樣在這個場景就不會遇到 1024 packets/sec 問題了 XDDD

在 Mac 上跑 DNS-over-TLS

主要是參考「Configuring DNS-over-TLS on macOS」這篇的方法做的：

brew install knot-resolver
echo "policy.add(policy.all(policy.TLS_FORWARD({{'1.1.1.1', hostname='1.1.1.1'}})))" | tee -a /usr/local/etc/kresd/config
sudo brew services restart knot-resolver

然後 127.0.0.1 就有 DNS resolver 可以用了，接下來就是把系統的 DNS 改過去...

AWS 允許 Hybrid Cloud 下的 DNS Query

AWS 對於 Hybrid Cloud (混合雲，通常是講與傳統機房的混搭應用，也就是雲端跟地端的混搭) 推出兩個功能，一個是讓 AWS 的 DNS Resolver 對於某些 domain 可以回機房端查詢 (雲端查詢地端 domain)。另外一種是反過來，讓機房端的 DNS Resolver 可以查 AWS 這邊的資料 (地端查詢雲端 domain)：「New – Amazon Route 53 Resolver for Hybrid Clouds」。

兩者都可以自己幹，但就得花功夫自己架設，而且有很多細節得處理：

建立 EC2 instance，在上面跑 Unbound，然後 EC2 instance 的 DNS servers 設定要指到這邊。
由於 EC2 的 DHCP 服務沒有辦法指定發放的 IP range，所以為了多重意外而中獎 (關機的時候剛好有其他機器 DHCP 拿到這組 IP)，需要開獨立的 subnet 只放固定 IP 的服務。
為了系統的穩定性，需要在兩個不同 AZ (或是三個) 架設這些 DNS Resolver，所以對應有兩個或是三個 subnet 得建立。

而地端到雲端通常會簡單一些，因為地端通常都已經有內部的 DNS Resolver 可以用，通常只需要在雲上面有 proxy 的角色就可以解決。

不過現在這些 AWS 都直接提供了：

常見的區域都可以用：

Hybrid Cloud is available today in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Sydney), Asia Pacific (Tokyo) and Asia Pacific (Singapore), with other commercial regions to follow.

費用的部分不算便宜 (跟自己弄三台 t3.nano 比起來)，但畢竟不需要自己管理，而且對於已經有機房的單位應該只是零頭而已：

Route 53 Resolver remains free for DNS queries served within your VPC. Resolver Endpoints use Elastic Network Interfaces (ENIs) costing $0.125 per hour. DNS queries that are resolved by a Conditional Forwarding Rule or a Resolver Endpoint cost $0.40 per million queries up to the first billion and $0.20 per million after that.

Cloudflare 的 DNS Resolver 也提供 Purge 功能了

Cloudflare 提供的 1.1.1.1 與 1.0.0.1 也提供 purge 功能了，在 https://cloudflare-dns.com/purge-cache/ 這邊：「Refresh Stale DNS Records on 1.1.1.1」。

跟 Google 的類似：「Flush Cache | Public DNS | Google Developers」。不小心弄錯東西，有需要 purge 的時候還蠻方便的...

用 Stubby 在 Ubuntu 上跑 DNS over TLS

透過 DNS over TLS 會損失一些效能 (我用 VDSL 的光世代測試，大約是從 10ms 變成 40ms)，但可以讓 ISP 看不到你查詢什麼，對於隱私有很大的幫助... 而先前是一直在看 Ubuntu 上的 Unbound 什麼時候會有 1.8.0+ 的版本可以用 (支援 DNS-over-TLS)，但一直沒看到，結果在「How to Protect Your DNS Privacy on Ubuntu 18.04 with DNS over TLS」這邊看到 Stubby 這個軟體。

Stubby 在 Ubuntu 18.04 上可以直接裝，但在 Ubuntu 16.04 上需要透過 PPA 裝，我是透過「DNS Utils : James Newell」這個安裝的，裝好後 /etc/stubby/stubby.yml 檔裡 upstream_recursive_servers 的設定改成：

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

就可以走 port 853 的 DNS over TLS 了，而 Stubby 預設會聽 127.0.0.1 與 ::1 的 port 53，所以把 /etc/resolv.conf 或是 NetworkManager 的設定改成 127.0.0.1 就可以了。

目前這樣設看起來沒辦法擋 MITM attack (偽造 SSL certificate)，Stubby 看起來只能用 tls_pubkey_pinset 鎖住，但實在不愛這個方法 (因為 Cloudflare 有可能會換成其他的 SSL certificate)，之後看看有沒有可以吃 Root CA 架構的認證再來調整...

Cloudflare 提供的 DNS Resolver 服務拓展到 Tor 上

Cloudflare 宣佈 DNS Resolver 提供 Tor 的版本，讓使用者可以在不暴露自己的 IP address 的情況下，使用 Cloudflare 提供的 DNS Resolver 服務：「Introducing DNS Resolver for Tor」。

不過沒看懂，如果使用者想要透過 Tor 保護自己的話，本來就可以透過 Tor 存取 1.1.1.1 與 1.0.0.1 甚至是其他家有提供 DNS-over-TLS 或是 DNS-over-HTTPS 的服務了？(像是 Google 的 8.8.8.8)

好像找不到什麼使用的理由...

Cloudflare 推出 1.1.1.1 的 DNS Resolver 服務

Cloudflare 推出了 1.1.1.1 上的 DNS Resolver 服務：「Announcing 1.1.1.1: the fastest, privacy-first consumer DNS service」，主打項目是隱私以及效能。

然後因為這個 IP 的特殊性，上面有不少奇怪的流量... 而 Cloudflare 跟 APNIC 交換條件後取得這個 IP address 的使用權 (然後 anycast 發出去)：

APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.
We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born.

Cloudflare 做了效能比較表 (與 Google Public DNS 及 OpenDNS 比較)，可以看到平均速度快不少：