Chromium (Google Chrome) 修正 DNS 查詢問題後對 Root name servers 的壓力減輕不少

先前在「Chromium (Google Chrome) 實做對 Root DNS 的影響」這邊有提過 Chromium (以及 Google Chrome) 判斷所在的網路是不是有 NXDOMAIN hijack 的程式碼反而對 Root name servers 產生了巨大的 NXDOMAIN 流量。

因為上新聞所以才動了起來 (本來都沒什麼在動),後來提供的方法是變成可以設定的選項,但預設是關閉的,這樣一來就可以改善 Root name servers 的壓力:「Add multi-state DNS interception policy - functionality piece.」。

而後在 Google Chrome 87 版進入 stable channel 後開始大幅緩解 (各平台分別在 2020/11/17 與 2020/11/18 釋出),在繼續觀察幾個月後,上個禮拜 Verisign 的人在 APNIC 這邊更新了消息:「How Chromium reduced Root DNS traffic」。

這是去年八月時丟出來的資料,可以看到趨勢往上:

這是後續的資料,從 87 版釋出後開始往下:

另外我覺得比較好玩的是這個,在「Issue 1090985: Disable Intranet Redirect Detector by default」這邊看到這樣的說明:

看起來沒什麼問題,先 merge 再說... 是這樣玩嗎 XDDD

Amazon Route 53 支援 DNSSEC

也是個大家等蠻久的功能,AWS 總算在 Amazon Route 53 上推出 DNSSEC 了:「Announcing Amazon Route 53 support for DNSSEC」。

他需要掛 AWS KMS,這部份會有一些費用在裡面,不過應該是還好...

不過 web console 目前有個明顯的缺點:透過 Route 53 註冊的網域,又用 Route 53 自家服務的情況下,設定 DNSSEC 的整合沒有做的很好,不能直接快速設定。

現在得自己設定演算法,然後複製 public key 到另外一邊,當你有一堆網域要設定的時候就會覺得很煩了...

Cloudflare 與 ISP 合作推出 ODoH 加強隱私,然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft:「Oblivious DNS Over HTTPS」):「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」,在 Hacker News 上面也有討論:「 Improving DNS Privacy with Oblivious DoH (cloudflare.com)

基本上就是 DNS over HTTPS 在上面架一層 Proxy,但這層 Proxy 不能是 Cloudflare 自己:

這樣一來 Cloudflare 知道 IP address 的機會就會比較小,藉以達到要求,先前要達到這樣的效果必須透過 ISP 提供的 HTTP/HTTPS Proxy (像是已經淘汰的 proxy.hinet.net:「HiNet 宣佈年底關閉 Proxy 服務」),或是透過 Tor,但 Tor 的效能會讓 query 速度慢不少。這次的這個服務的確是好不少...

技術上來說,當 Cloudflare 與 ISP 都把所有的 packet 記錄下來後,兩邊合作還是可以取得原始的 IP 資訊,以這個例子來說,你跟總部在香港的 PCCW 集團合作,看起來就不怎麼吸引人啊...

不過隔壁棚的 Google 則是讓人吐血中,打算用 Prefetch 名義看到你的 HTTPS 流量:「Continuing our journey to bring instant experiences to the whole web」,這樣一來,就有不少的機會 Google 可以分析出來使用者在看什麼 Netflix 影片了 (要看 Prefetch 到什麼程度,2017 年的時候做出來有 99.99% 的準確度):「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」。

來坐著等看 Google 這邊的好戲...

Smart TV 與遊戲主機的 DNS 經常是設死的

Hacker News Daily 上看到「Your Smart TV is probably ignoring your PiHole」,裡面提到了很多遊戲主機並不會依照從 DHCP 拿到的 DNS 設定使用,而是直接設死:

Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

裡面提到的論文是「Characterizing Smart Home IoT Traffic in the Wild」這篇,裡面分析了不同種類的裝置 DNS 的狀況,以及 HTTP/HTTPS 的比率:

回到原來的文章,裡面提到了用 NAT 的方式把 1.1.1.1 的 TCP/UDP Port 53 導到 Pi-hole 上面過濾,這樣看起來還行,下面的 DNS over TLSDNS over HTTPS 因為走其他特定的 TCP port,應該是不受影響...

Ubuntu 20.04 下用 resolvconf 取代 systemd-resolved (因為 PPPoE)

如同在「升級跳板機」這邊提到的,這台跳板機是跑 Ubuntu 20.04,加上需要跑 PPPoE,我就遇到透過 PPPoE 拿到的 DNS 無法套用的系統內。

這點在「add pppoe support to systemd-networkd」這邊有被提到,而且看起來 Debian 那邊已經套用 patch 上去了,但 Ubuntu 這邊似乎還沒...

我看了看還是決定先暫時先回頭用 resolvconf,可以只用指令解決:

sudo apt install -y resolvconf
sudo systemctl disable systemd-resolved

然後重開確認後就可以收工...

抓出正在使用的 DNS Server

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

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

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

讓瀏覽器直接連 HTTPS 的 SVCB/HTTPS

Cloudflare 的「Speeding up HTTPS and HTTP/3 negotiation with... DNS」這篇裡面提到了一個新的標準 (目前是 draft):「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」。

從文件上可以看到這個標準是由 GoogleAkamai 的人提出來的,想要透過 DNS 的方式告訴瀏覽器這個網站可以直接用 HTTPS 連線 (以及其他資訊)。

這樣有兩個好處,第一個是安全性上的好處,HSTS 只保證了第二次以及之後的連線會強制用 HTTPS,但不能保證第一次連線時是 HTTPS。透過 DNS 查到後可以第一次就用 HTTPS 連線。

第二個是效能上的好處,降低了一個 3xx redirect 的時間,雖然 DNS 多了一些查詢,但 DNS 查詢這邊通常會比 TCP connection 建立連線來說快不少,再加上 HTTP protocol 需要先等瀏覽器端送出 HTTP header 後才有回應,這樣應該是快蠻多的。

文章裡有提到 iOS 14 好像有開始在嘗試,但我好像沒看到其他資料:

We began investigating and found these to be a part of Apple’s iOS14 beta release where they were testing out a new SVCB/HTTPS record type.

先繼續觀望看看標準怎麼發展...

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),這個功能可以緩解這個問題...

Chromium (Google Chrome) 實做對 Root DNS 的影響

前幾天在 APNIC 上的這篇文章受到社群注意:「Chromium’s impact on root DNS traffic」,在 Hacker News 上也有對應的討論:「Chromium's Impact on Root DNS Traffic (apnic.net)」。

文章作者 Matthew ThomasVerisign 的員工 (Verisign Labs),可以看出來主力在 DNS 的部份。

Chromium (以及 Google Chrome) 會隨機產生一組 hostname,確認所在的網路是否有 DNS hijack:

這導致了在 Root DNS 上會看到大量不存在網域的 DNS query,這點隨著 Google Chrome 的市占率愈來愈高,在 Root DNS 上這些 DNS query 甚至佔到 40% 以上:

不過 Root Server 有上千台在跑,就目前的效能來說應該是還 OK:

As of 2020-08-27, the root server system consists of 1097 instances operated by the 12 independent root server operators.

把這個問題丟到 bugs.chromium.org 上翻,看起來有三張票在進行中:

瞄了一下裡面的討論,目前的方向有兩類,一種是主張完全關掉,這樣確定可以大幅減少對 Root DNS 的壓力,另外一種是設計 cache,使得 Root DNS 的 loading 降低。

這次有不少新聞都有報導,受到 PR 壓力看起來是動起來了... (這三張票看起來之前都沒什麼人有動力要處理)

Cloudflare 的 Enterprise 客戶可以用 Secondary DNS 服務了

Cloudflare 宣佈了新,提供 Enterprise 客戶使用 Secondary DNS:「Secondary DNS — A faster, more resilient way to serve your DNS records」。

先前 Cloudflare 的客戶只能透過網頁或是 Cloudflare 提供的 API 管理 DNS,現在則是可以透過標準協定直接建出 Secondary DNS:

Starting today, enterprise customers who are entitled to secondary DNS will be able to configure their zone in the Cloudflare Dashboard.

這樣對於自己在管理 DNS 的客戶會方便不少 (像是用 BIND 的單位),不過因為安全性的考量,需要啟用 TSIG 確保資料不會被竄改:

Zone transfers between a primary and secondary server are unauthenticated on their own. TSIGs (Transactional Signatures) were developed as a means to add authentication to the DNS protocol, and have mostly been used for zone transfers.

另外就會想到 StackOverflow (「StackOverflow 對於多 DNS 商的同步方式...」) 與 GitHub (「GitHub 也自己搞了一套管理多家 DNS 的程式...」) 的方式,是直接在不同的系統之間疊管理抽象層,這種搞法應該會更穩定,畢竟是直接丟到兩個不同系統管理。

然後我記得市場上有一些 Secondary DNS 的服務可以選,Cloudflare 目前看起來算是補產品線而不是進來殺市場 (畢竟是掛在 Enterprise 等級才能用)。