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 等級才能用)。

ICANN 否決 .org 與 .ngo 的交易

ICANN 否決了 .org.ngo 網域控制權的交易:「ICANN Board Withholds Consent for a Change of Control of the Public Interest Registry (PIR)」。

Today, the ICANN Board made the decision to reject the proposed change of control and entity conversion request that Public Interest Registry (PIR) submitted to ICANN.

事情主要是起於 PIR (Public Interest Registry) 在 2019/11/13 宣佈他們的母單位 ISOC (Internet Society) 將被 Ethos Capital 併購,而這包含了 .org.ngo 網域的資產,這也代表了由 PIR 控制的網域會從非營利單位移到營利單位下 (總共有七個網域,其中最重要的是 .org,有超過一千萬個網域在上面),於是引發許多人的關注:

On 13 November 2019, PIR announced that ISOC, its parent organization, had reached an agreement with Ethos Capital, under which Ethos Capital would acquire PIR and all of its assets from ISOC. Under the agreement, PIR would also be converted from a Pennsylvania not-for-profit corporation to a for-profit Pennsylvania limited liability company. ISOC created and agreed to the transaction details that are under review.

而在隔天 2019/11/14,PIR 依照規定向 ICANN 送出「Notice of Indirect Change of Control and Entity Conversion」申請,依照規定,ICANN 需要在 2020/05/04 前批准或是否決,也就是這幾天就要做出決定。

而 ICANN 昨天宣佈了否決這項提案,暫時搞定了這件事情... 接下來看 Ethos Capital 會不會有什麼反擊 (上訴或是上法院)。

關於不推薦用 1.1.1.1 的事情...

最近剛好跟朋友有聊到 1.1.1.1,然後就有提到我不推薦使用 1.1.1.1 的原因。

主要是因為 Cloudflare 以隱私的理由所以不打算支援 EDNS Client Subnet (ECS),而 ECS 這項技術可以把 client 的 subnet 資訊帶給 DNS server,讓 DNS server 可以配出更精準的伺服器,而關於 Cloudflare 不支援的這點,可以在「1.1.1.1 supports ECS?」這邊看到一些討論。

這個問題在 Akamai 這種超大 CDN,在同一個地區的各 ISP 都有伺服器的情況下特別明顯。

以我家第四台的 cable 線路來說 (我的備用線路),是走亞太 (APOL) 的線路出去,如果從自己的 ISP 查 www.akamai.com 的位置,可以查到 23.76.81.151,用 mtr 可以發現是走到 EBIX (也是亞太) 裡面的伺服器:

gslin@rpi3p [~] [13:35] host www.akamai.com         
www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.76.81.151
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:594::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:58a::6a3
gslin@rpi3p [~] [13:35] mtr -w 23.76.81.151
Start: 2020-04-05T13:35:49+0000
HOST: rpi3p                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                             0.0%    10    0.5   0.5   0.4   0.6   0.0
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw            0.0%    10    7.8   8.2   6.1  11.9   1.7
  3.|-- 10.251.11.6                                         0.0%    10   19.3  25.6  19.3  33.5   4.7
  4.|-- 10.251.231.5                                        0.0%    10   25.4  23.4  19.8  29.1   3.7
  5.|-- 10.251.231.1                                        0.0%    10    8.0  10.7   5.7  24.0   5.7
  6.|-- 10.251.230.34                                       0.0%    10   26.6  20.6   5.9 110.0  32.1
  7.|-- 10.251.230.29                                       0.0%    10   58.4  35.4   6.6  81.2  30.9
  8.|-- 202-178-245-162.cm.static.apol.com.tw               0.0%    10    9.5  18.4   7.4  78.5  21.3
  9.|-- 203-79-250-201.static.apol.com.tw                   0.0%    10    8.5   8.2   6.4   9.8   1.0
 10.|-- 211.76.96.191                                       0.0%    10    7.2  10.2   6.7  15.6   2.7
 11.|-- 203-79-254-10.ebix.net.tw                           0.0%    10  2226. 3802. 2226. 6017. 1314.6
 12.|-- a23-76-81-151.deploy.static.akamaitechnologies.com  0.0%    10    6.4   9.4   6.3  16.4   3.3

但如果從 1.1.1.1 查,會查到在中華電信內的 Akamai 伺服器,於是在尖峰時間反而變得很慢:

gslin@rpi3p [~] [13:36] host www.akamai.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.48.142.132
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1ea7::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1e9f::6a3
gslin@rpi3p [~] [13:39] mtr -w 23.48.142.132
Start: 2020-04-05T13:39:42+0000
HOST: rpi3p                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                              0.0%    10    0.4   0.5   0.4   0.6   0.1
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw             0.0%    10    8.7  17.0   6.1  81.2  22.8
  3.|-- 10.251.11.6                                          0.0%    10   26.7  24.6  21.4  29.3   2.8
  4.|-- 10.251.231.5                                         0.0%    10   26.8  29.9  16.8  88.6  21.0
  5.|-- 10.251.231.1                                         0.0%    10    7.2   8.3   6.8  12.7   1.8
  6.|-- 10.251.230.34                                        0.0%    10   10.3   8.9   5.9  11.0   1.6
  7.|-- 10.251.230.29                                        0.0%    10    6.3  10.1   5.4  31.7   7.8
  8.|-- 202-178-245-162.cm.static.apol.com.tw                0.0%    10    8.8   9.1   7.3  13.2   1.8
  9.|-- 203-79-250-209.static.apol.com.tw                    0.0%    10   10.0   8.6   6.3  10.8   1.5
 10.|-- 211.76.96.67                                         0.0%    10    7.9   9.0   4.0  12.4   2.6
 11.|-- 109-84-21-113-static.chief.net.tw                    0.0%    10   18.3  11.7   7.0  25.1   5.7
 12.|-- 21-252-123-103-static.chief.net.tw                   0.0%    10    9.4  10.0   7.7  15.0   2.2
 13.|-- 203-75-228-5.HINET-IP.hinet.net                      0.0%    10   10.1  10.8   7.0  21.2   4.3
 14.|-- r4209-s2.hinet.net                                   0.0%    10    9.4  10.5   6.3  17.9   3.7
 15.|-- tpdt-3012.hinet.net                                  0.0%    10   92.0  61.6  11.1 141.6  53.8
 16.|-- tpdt-3301.hinet.net                                  0.0%    10   42.9  38.8   7.3 100.8  33.6
 17.|-- a23-48-142-132.deploy.static.akamaitechnologies.com  0.0%    10    8.2  15.5   8.2  46.6  12.4

跨 ISP 的線路品質通常都沒有同一個 ISP 內來的好,但因為沒有 EDNS Client Subnet (ECS) 的資訊,所以只能導去當地 (地理上) 預設的點,latency 應該還是夠低,但頻寬就未必足夠了。

8.8.8.8 會好一點,但目前最建議的還是用 ISP 自家的 DNS resolver,當 ISP 的 DNS Resolver 不支援 EDNS Client Subnet 時,CDN 也還是會正確讀到 ISP 的資訊,配到的伺服器的頻寬就不會太差...

透過 /etc/hosts 擋廣告與追蹤的軟體

Hacker News Daily 上看到 Maza ad blocking,這是一個擋廣告與追蹤的軟體,原理就是在 DNS 上檔掉某些網域。

運作方式跟 Pi-hole 接近,其中 Pi-hole 是提供一個 DNS server 擋,這套軟體則是透過 /etc/hosts 來擋。

目前只支援 macOSLinux,不過這樣看起來使用的族群有點怪,因為在 desktop 上有更多手段可以擋,透過 DNS 類的擋法主要還是拿來對手機上無法無天的 app...

不過先關注一下好了,之後也許會在某些場合下用到?

Let's Encrypt 在檢查 CAA 時出包

Let's Encrypt 發現在檢查 CAA 的程式碼有問題,發了說明:「2020.02.29 CAA Rechecking Bug」,以及預定的處理方式:「Revoking certain certificates on March 4」。

問題是當一個 certificate request 包含了 N 個 domain 時,本來的 CAA 檢查應該要對這 N 個檢查,但程式寫成只會抓一個,然後檢查了 N 次:

The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.

2020/02/29 發現的,就程式碼的部屬時間,發現應該從去年 2019/07/25 開始就有這個 bug:

We confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance at 03:10. We deployed a fix at 05:22 UTC and then re-enabled issuance.

Our preliminary investigation suggests the bug was introduced on 2019-07-25. We will conduct a more detailed investigation and provide a postmortem when it is complete.

然後決定要 revoke 這些可能會有問題的 SSL certificate,大約佔現有還有效的 SSL certificate 的 2.6%,大約三百萬筆:

Q: How many certificates are affected?
A: 2.6%. That is 3,048,289 currently-valid certificates are affected, out of ~116 million overall active Let’s Encrypt certificates. Of the affected certificates, about 1 million are duplicates of other affected certificates, in the sense of covering the same set of domain names.

在「Check whether a host's certificate needs replacement」這邊可以偵測線上使用的 SSL certificate 是否受到影響。

另外在「Download affected certificate serials for 2020.02.29 CAA Rechecking Incident」這邊可以抓到所有受到影響,預定要 revoke 的 SSL certificate 的序號。關於取得序號的方式,官方也有提供 CLI 的指令可以操作確認,對於有很多網域名稱需要確認的人可以用這組指令編寫程式判斷:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :

照目前的描述,如果申請時只有一個 domain 應該是不會中這個問題,再來是最壞的情況大概會維持三個月 (網站主人沒管他,等到時間到了自動 renew)。

Firefox 在美國將預設開啟 DNS over HTTPS

看到 Mozilla 在「Firefox continues push to bring DNS over HTTPS by default for US users」這邊的公告,另外也可以參考 Hacker News 上的討論:「Mozilla’s DNS over HTTPs (blog.mozilla.org)」。

這次的改變是將美國的 Firefox 使用者自動啟用 DNS over HTTPS (DoH),而預設是丟給 Cloudflare

By default, this change will send your encrypted DNS requests to Cloudflare.

這個作法非常粗暴而且侵犯使用者的隱私。

  • 對於進階而且有在跟重大消息的使用者,他們如果不信任 Cloudflare 的話,會主動關掉 DoH 的選項。
  • 但對於一般使用者,他們不知道這件事情,而他們本來也不會預期他們上網的 hostname 部份會被 Cloudflare 知道。

相較於 Google Chrome 是確認你現在用的 DNS 是不是在有支援 DoH 的清單內,如果是的話就會切過去使用 DoH,但不會因此改變 DNS provider,也就是不會有突然冒出來的第三者知道你瀏覽的網站。

來繼續看...

Google Chrome 也要打開 DoH

Google Chrome 也要支援 DNS over HTTPS (DoH) 了,不過 Google 的作法比 Firefox 軟 (大概這種東西都有經過反壟斷法的評估?),會先判斷系統的 DNS 是否在支援 DoH 的清單內,在不改變 DNS 服務商的情況下,從本來的 UDP 查詢變成 DoH 查詢:「Experimenting with same-provider DNS-over-HTTPS upgrade」。

清單可以從「DNS over HTTPS (aka DoH)」這邊看到,除了 Google 自己外,也有 Cloudflare 與其他支援 DoH 的 DNS 服務商。

這個功能會從 Chrome 78 生效 (現在 stable 與 beta 都還是 77):

We are aiming for an experiment in Chrome 78 (branch cut: Sept 5th; estimated Stable: Oct 22nd) followed by a launch if everything goes well.

OpenBSD 關掉 Firefox 預設的 DoH (DNS over HTTPS)

OpenBSD 決定關閉 Firefox 預設的 DoH (DNS over HTTPS):「DoH disabled by default in Firefox」。

原因是 OpenBSD 的人認為,DoH 本身 ok,但是預設導去 Cloudflare 不 ok:

Disable DoH by default. While encrypting DNS might be a good thing, sending all DNS traffic to Cloudflare by default is not a good idea. Applications should respect OS configured settings. The DoH settings still can be overriden if needed. ok landry@ job@

我覺得這槍開的很好 XD

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 量很大的則是要設長一點...

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