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

用 GPT-3 直接產生對應的 SQL query

Hacker News Daily 上看到的東西,直接給 GPT-3 條件,叫 GPT-3 給出對應的 SQL query,這就有點誇張了...:「Automating My Job with GPT-3」。

這樣丟進去:

Instruction: Given an input question, respond with syntactically correct PostgreSQL. Be creative but the SQL must be correct.

Input: how many users signed up in the past month?

然後這樣出來:

GPT-3 Response: SELECT COUNT(*) FROM users
WHERE signup_time > now() - interval '1 month'

把欄位名稱替換掉就可以用了... 而且接下來就更誇張了,直接要求 GPT-3 也要照著設定的 table schema 給答案:

Instruction: Given an input question, respond with syntactically correct PostgreSQL. Be creative but the SQL must be correct. Only use tables called "users" and "charges". The "users" table has columns: id (integer), signup_dt (timestamp), email (character varying), and plan_type (character varying). The "charges" table has columns: amount (bigint), user_id (integer), and charge_dt (timestamp).

Input: how much revenue did we have in the past 7 days?

然後輸出了:

GPT-3 Response: SELECT SUM(amount) FROM charges WHERE charge_dt > now() - interval '7 days'

接下來是在同樣 instruction 下,跨表格的問題:

Input: how much revenue have we had from users that signed up in the last 6 months?

這時候 INNER JOIN 就跑出來了:

.8 Temperature GPT-3 Response: SELECT SUM(charges.amount) FROM users INNER JOIN charges ON users.id = charges.user_id WHERE signup_dt >= DATE_SUB(now(), INTERVAL '6 months')

後面的問題也很精彩,看起來之後可以接上 BI dashboard,直接丟句子進去,然後拉各種資料出來視覺化?

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 壓力看起來是動起來了... (這三張票看起來之前都沒什麼人有動力要處理)

Amazon Route 53 增加了即時的 Query 數量資訊

AWSRoute 53 增加了 Query 數量的資訊 (加到 CloudWatch 內):「Amazon Route 53 Now Publishes Query Volume Metrics for Public Hosted Zones」。

下午的時候連進去看沒看到,回家後想起來 Route 53 是全球性服務,切到 us-east-1 上就看到了...

算是很基本的功能,這樣可以很方便的看一下使用情況,然後就可以透過這些資料調整 TTL,有些為了要快速切換的可以設短一點,有些不太變動但 query 量很大的則是要設長一點...

PostgreSQL 裡的 B-tree 結構

在「Indexes in PostgreSQL — 4 (Btree)」這邊看到講 PostgreSQLB-tree 結構以及常見的查詢會怎麼使用 B-tree。

裡面講了三種查詢,第一種是等號的查詢 (Search by equality),第二種是不等號的查詢 (Search by inequality),第三種是範圍的查詢 (Search by range)。再後面講到排序與 index 的用法。

雖然是分析 PostgreSQL,但裡面是一般性的概念,其他使用 B-tree 結構的資料庫也是類似作法...

RFC8482 廢掉 DNS 查詢的 ANY query 了...

看到 Cloudflare 的「RFC8482 - Saying goodbye to ANY」這篇,裡面提到 RFC8482 廢掉了 ANY 查詢:「Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY」。

The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.

對 Cloudflare 的痛點主要在於營運上的困難,因為 ANY 回應的 UDP packet size 很大,很容易造成放大攻擊:

把拒絕 ANY 查詢變成標準後,讓 DNS provider 手上多了一把武器可以用。

從二月開始不回應 EDNS 的 DNS server 將會無法查詢

在「DNS flag day」這邊看到 EDNS 的 workaround。

目前的 workaround 是在 DNS server 對於 EDNS 查詢沒有回應時,就改用不帶 EDNS 的查詢再問一次,以確保相容於不支援 EDNS 而且會直接過濾掉這些封包的環境。

而從今年二月開始,這個 workaround 將會被拿掉,當帶 EDNS 的查詢沒有回應時就直接當作伺服器死掉,不會再用沒有 EDNS 的查詢問一次:

The main change is that DNS software from vendors named above will interpret timeouts as sign of a network or server problem. Starting February 1st, 2019 there will be no attempt to disable EDNS as reaction to a DNS query timeout.

This effectivelly means that all DNS servers which do not respond at all to EDNS queries are going to be treated as dead.

往下可以看到會做出改變的廠商包括了 GoogleCloudflare,可以預期 8.8.8.8 (8.8.4.4) 與 1.1.1.1(1.0.0.1) 都會進行更新。

網站上面有可以查詢的工具,剛剛查了一下以前的公司與競爭對手,發現 1111.com.tw 看起來會掛掉,不知道二月前會不會修正這個問題... XD

Mixnode:又一個可以搜尋整個 Web 的服務

看到「Turn the web into a database: An alternative to web crawling/scraping」這篇,在介紹自家 Mixnode 這個產品,看起來是提供 SQL 界面分析整個 Web 的服務...

這類服務最重要的反而不是搜尋界面 (有可以讓程式接的 API 其實就 ok 了),重要的是後面的資料庫有多豐富...

在「用 PublicWWW 分析網站」這邊有提到類似的服務 PublicWWW,而且也一樣有提供 API,先把 Mixnode 丟著記錄起來就好,等有需要的時候再去申請 trial account...

Amazon Aurora 支援 Parallel Query 加速

Amazon Aurora 推出了 Parallel Query,可以加速計算速度:「New – Parallel Query for Amazon Aurora」。原理是利用 Aurora 把 storage 層打散的前提,所以有機會透過螞蟻雄兵處理:

官方給的範例可以連到原文去看,可以看到有打開 aurora_pq 與沒打開的效能差異:

15 rows in set (1 min 53.36 sec)
15 rows in set (1 hour 25 min 51.89 sec)

打開後大約是原來的 1/45 時間,提昇超多...

不過還是有些限制,我最在意的就是目前只支援相容於 MySQL 5.6 的版本 (居然不是先支援 5.7):

Engine Support – We are launching with support for MySQL 5.6, and are working on support for MySQL 5.7 and PostgreSQL.

然後沒有多餘費用,只是 i/o cost 可能會增加:

Cost – You can make use of Parallel Query at no extra charge. However, because it makes direct access to storage, there is a possibility that your IO cost will increase.