Tag: resolver

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 比較)，可以看到平均速度快不少：

在台灣的話，HiNet 非固定制 (也就是 PPPoE 連線的使用者) 連到 8.8.8.8 有奇怪的 latency：

可以比較同一台機器對 168.95.1.1 的反應速度：

不過如果你是 HiNet 固定制 (固 2 或是固 6 IP 那種，不透過 PPPoE，直接設定 IP address 使用 bridge mode 連線的使用者)，兩者的 latency 就差不多，不知道是 Google 還是 HiNet 的架構造成的。

另外比較奇怪的一點是在文章最後面提到的 https://1.1.1.1/，理論上不會發 IP-based 的 SSL certificate 才對？不知道 CEO 老大是有什麼誤解... XD

Visit https://1.1.1.1/ from any device to get started with the Internet's fastest, privacy-first DNS service.

Update：查了資料發現是可以發的，只是大多數的 CA 沒有提供而已...

所以 HiNet DNS Resolver 至少有三段...？

剛剛看到「HiNet DNS系統設備維護作業」：

範圍：苗栗(含)以南至雲林(含)以北HiNet上網用戶

加上之前在「中華的 DNS 架構」提到的公告，這樣看起來 HiNet DNS Resolver 至少是切成三段？

靠著公告在猜架構...

PChome 修正了問題，以及 RFC 4074 的說明

早些時候測試發現 PChome 已經修正了之前提到的問題：「PChome 24h 連線會慢的原因...」、「PChome 24h 連線會慢的原因... (續篇)」，這邊除了整理一下以外，也要修正之前文章裡的錯誤。

在 RFC 4074 (Common Misbehavior Against DNS Queries for IPv6 Addresses) 裡面提到了當你只有 IPv4 address 時，DNS server 要怎麼回應的問題。

在「3. Expected Behavior」說明了正確的作法，當只有 A RR 沒有 AAAA RR 的時候，應該要傳回 NOERROR，而 answer section 裡面不要放東西：

Suppose that an authoritative server has an A RR but has no AAAA RR for a host name. Then, the server should return a response to a query for an AAAA RR of the name with the response code (RCODE) being 0 (indicating no error) and with an empty answer section (see Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that there is at least one RR of a different type than AAAA for the queried name, and the stub resolver can then look for A RRs.

在「4.2. Return "Name Error"」裡提到，如果傳回 NXDOMAIN (3)，表示查詢的這個名稱完全沒有 RR，而不僅僅限於 AAAA record，這就是我犯的錯誤 (在前面的文章建議傳回 NXDOMAIN)：

This type of server returns a response with RCODE 3 ("Name Error") to a query for an AAAA RR, indicating that it does not have any RRs of any type for the queried name.

With this response, the stub resolver may immediately give up and never fall back. Even if the resolver retries with a query for an A RR, the negative response for the name has been cached in the caching server, and the caching server will simply return the negative response. As a result, the stub resolver considers this to be a fatal error in name resolution.

Several examples of this behavior are known to the authors. As of this writing, all have been fixed.

PChome 這次的修正回應了正確的值 (而不是我提到的 NXDOMAIN)：

$ dig shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw

; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<<<- opcode: QUERY, status: NOERROR, id: 40767
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;shopping.gs1.pchome.com.tw.    IN      AAAA

;; AUTHORITY SECTION:
gs1.pchome.com.tw.      5       IN      SOA     ns1.gs1.pchome.com.tw. root.dns.pchome.com.tw. 20171123 3600 3 3600 5

;; Query time: 16 msec
;; SERVER: 210.242.216.91#53(210.242.216.91)
;; WHEN: Fri Nov 24 01:44:52 CST 2017
;; MSG SIZE  rcvd: 134

另外 RFC 也有一些其他的文件可以參考，像是 RFC 2308 (Negative Caching of DNS Queries (DNS NCACHE))、RFC 4697 (Observed DNS Resolution Misbehavior) 以及 RFC 8020 (NXDOMAIN: There Really Is Nothing Underneath)，這些文件描述了蠻多常見的問題以及正確的處理方法，讀完對於現在愈來愈複雜的 DNS 架構有不少幫助。