Category: DNS

musl 的 DNS reolsver 支援 TCP fallback

在 Facebook 上看到這篇：

剛好想起前陣子在 Hacker News 上看到「Musl 1.2.4 adds TCP DNS fallback (openwall.com)」這個消息，裡面的連結是今年五月 musl 1.2.4 的出版公告：「musl 1.2.4 released」(話說 openwall 網站似乎有擋 HiNet 的 IP，我是走第四台網路看的，或是參考 Internet Archive 上面的連結)。

musl 1.2.4 一個很重要的改變是在 DNS resolver 上支援了 TCP fallback (也就是支援 DNS over TCP)，這改善了長久以來在 container 裡面使用 Alpine Linux 偶而會因為 DNS 遇到沒有照標準做的 server 而中雷的問題：

This release adds TCP fallback to the DNS stub resolver, fixing the longstanding inability to query large DNS records and incompatibility with recursive nameservers that don't give partial results in truncated UDP responses. It also makes a number of other bug fixes and improvements in DNS and related functionality, including making both the modern and legacy API results differentiate between NODATA and NxDomain conditions so that the caller can handle them differently.

查了一下對應的標準，跑去問 ChatGPT 的 GPT-4：

但 ChatGPT 引用的東西都不能直接當作是實際的文字，只能當作一個起點去找。實際翻 RFC 1035 可以翻到：

Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header.

所以的確在 UDP response 的規範是 512 bytes，要取得完整的資料只能往 TCP 查詢。而 musl 有了這個 TCP fallback 總算是補掉了 Alpine Linux 的一個大坑。

而 musl 1.2.4 則是在 Alpine Linux 3.18 才開始使用：「Alpine 3.18.0 released」。

musl libc 1.2.4 – now with TCP fallback in DNS resolver

所以回到開頭，提到 Alpine Linux 3.16 還是有問題的人，是應該會遇到問題沒錯，因為 3.16 的 musl 本來就沒 TCP fallback？遇到不標準的 DNS server 的確是會噴...

Anyway，Alpine Linux 的 DNS 問題應該會變成過去式...

Tails 換網域名稱，從 tails.boum.org 換到 tails.net

看到 Tails 換了一個新的網域名稱，從本來的 tails.boum.org 換到了 tails.net 上：「Welcome to tails.net!」。

看了 tails.net 的 WHOIS 可以發現這也是個老域名了，甚至比 Tails 軟體出現的 2009 年還早：

Updated Date: 2022-08-09T10:30:42
Creation Date: 2002-12-18T11:36:37
Registrar Registration Expiration Date: 2024-12-18T11:36:37

理所當然的，本來的 tails.boum.org 也還會動，目前是重導到 tails.net 上面。

然後研究了一下 boum.org 是什麼，用「site:boum.org -site:tails.boum.org」翻了一下各家搜尋引擎：「Kagi 的」、「DuckDuckGo 的」、「Google 的」。

其實還不少東西？看起來像是某個業餘團體或是組織...

另外如果是用 site:tails.boum.org 找，可以發現除了主站以外，下面其實還不少 subdomain，像是 gitlab.tails.boum.org 這樣的網域，所以應該是還有不少東西要改...

處理 rTorrent 會卡頓的問題

用 rTorrent 算是很久了，在 CLI 下的 BitTorrent client。

但 rTorrent 一直有卡頓的問題，這個週末決定還是找一下怎麼解，而在 Reddit 上面可以看到討論：「Rtorrent stalling / freezing caused by bad tracker? I fixed my problem but I'm a bit puzzled.」，其中就有提到是 libtorrent 因為 DNS 查詢 blocking 的問題。

不過這邊有些人已經提出了解法，其中一個是使用 libudns 達成 async DNS query 來解決這個問題，這個 branch 有進到官方的 git repository 裡面 (但沒有被 merge 到 master 上)：「rakshasa/libtorrent at slingamn-udns.10」。

看了一下雖然最後 commit 是 2019 年，但其實不算太舊，因為 master 從 2019 年到現在 2023 年也沒幾個 commit，不過直接用 slingamn-udns.10 的 libtorrent 搭最新版的 rtorrent 是編不起來的，主要是因為 IPv6 的支援改變了一些程式的 API 介面。

最後一個可以搭 rtorrent 的版本是 2021 年六月的 582e4e40256b43d3e5322168f1e1ed71ca70ab64，也已經比目前最近的正式 release 0.9.8 (2019/07/19) 還新。

把這些組合弄起來後跑了幾個小時，看起來順不少，暫時沒有遇到卡住的問題了...

Gandi 被併購

看到 Hacker News Daily 上面的消息才知道被並夠了：「Domain registrar Gandi gets bought out, removes free mailboxes (afront.org)」。翻了維基百科後看到「Gandi & TWS Join Forces to Form Your.Online」這篇新聞稿。

Total Webhosting Solutions 這家公司可以從 Crunchbase 查到是 2017 成立的：「Total Webhosting Solutions - Crunchbase Company Profile & Funding」，另外找了一下新聞，會發現這家公司在 2020 年的時候買了一堆公司，然後 2021 年沈寂了一陣子，又在 2022 年開始買：「Total Webhosting Solutions Archives - Hosting Journalist.com」。

還看不太懂這家公司在搞什麼...

透過 DNS 找自己 IP、查詢 ASN 資訊以及匯率

Hacker News 上看到「Bizarre and unusual uses of DNS (fosdem.org)」這篇，裡面把 DNS 的各種創意性的服務都整理出來了。原文在「Bizarre and Unusual Uses of DNS」，是今年 FOSDEM 的演講內容，PDF 投影片在「Bizarre and unusual uses of DNS」這邊。

裡面提到兩個服務可以抓自己的 IP address，第一組是 Google 的服務，像是這樣：

$ dig o-o.myaddr.l.google.com txt
;; ANSWER SECTION:
o-o.myaddr.l.google.com. 60     IN      TXT     "114.34.121.114"

但可以抓到我真正的 IP 是因為我自己有架設 DNS resolver。如果一般用中華電信的 DNS resolver 168.95.192.1，會出現中華的 IP address 資訊：

$ dig o-o.myaddr.l.google.com txt @168.95.192.1
;; ANSWER SECTION:
o-o.myaddr.l.google.com. 5      IN      TXT     "2001:b000:180:8001:0:1:10:143"

如果是用有支援 ECS 的 Google Public DNS (像是 8.8.8.8)，則是會帶出 ECS 資訊：

$ dig o-o.myaddr.l.google.com txt @8.8.8.8
;; ANSWER SECTION:
o-o.myaddr.l.google.com. 60     IN      TXT     "172.217.43.204"
o-o.myaddr.l.google.com. 60     IN      TXT     "edns0-client-subnet 114.34.121.0/24"

這算是技術限制了。另外一方面，OpenDNS 提供的 myip.opendns.com 就沒那麼好用了。

第二個是 Team Cymru 提供的 DNS 服務，可以透過 DNS 查某些 IP 的 ASN 資訊，像是以中華電信 168.95.192.1 這個 IP 為例：

$ dig 1.192.95.168.origin.asn.cymru.com txt
;; ANSWER SECTION:
1.192.95.168.origin.asn.cymru.com. 14400 IN TXT "3462 | 168.95.0.0/16 | TW | apnic | 1997-04-09"

$ dig 1.192.95.168.peer.asn.cymru.com txt
;; ANSWER SECTION:
1.192.95.168.peer.asn.cymru.com. 14400 IN TXT   "1239 9680 | 168.95.0.0/16 | TW | apnic | 1997-04-09"

翻了一下，AS1239 是 Sprint，AS9680 是中華在美國的 ASN。

第三個有趣的是匯率，沒有直接開 public domain 讓大家查，你需要把 DNS 指過去查：

$ dig 100USD-TWD.fx @dns.toys
;; ANSWER SECTION:
100USD-TWD.             3600    IN      TXT     "100.00 USD = 3066.41 TWD" "2023-02-26"

Let's Encrypt 支援 ACME-CAA，可以再進一步限縮可以申請的使用人

前幾天在 Hacker News 上看到 Let's Encrypt 支援 ACME-CAA 的新聞：「Let's Encrypt now supports ACME-CAA: closing the DV loophole (devever.net)」，原文在「Let's Encrypt now supports ACME-CAA: closing the DV loophole」。

先前的「RFC 6844 - DNS Certification Authority Authorization (CAA) Resource Record」已經先定義了 DNS 上 CAA record 的規範，另外在 CA/Browser Forum 的 Baseline Requirements 裡面也要求了 CA 簽發單位必須遵守 CAA 設定。

但這邊還是有一些風險，像是當網站被其他人控制後 (或是中間有 BGP hijacking 的方式取得 TCP 層的控制權)，控制人就可以透過 http-01 的方式通過認證申請到 SSL certificate。而這次 Let's Encrypt 實做的 ACME-CAA 則是試著降低這個風險。

第一個是 accounturi 參數，可以指定只有某個 CA 裡的某個帳號可以申請，像是這樣：

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://some/lets-encrypt/account-id"

第二個是限制 validationmethods 參數，限制只有某些方式可以申請，像是這邊限制只能透過 dns-01 申請：

example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"

不過支援 http-01 的不只 Let's Encrypt，至少也還有 ZeroSSL 與 Buypass，後續可以看看其他家會不會跟上，以及會不會放到 Baseline Requirements 裡面...

AS112 計畫

在「Cloudflare is joining the AS112 project to help the Internet deal with misdirected DNS queries」這邊看到的東西：「AS112 Project」，在維基百科上面也有條目：「Blackhole server」。

Cloudflare 宣佈 2022/12/15 參與 AS112 Project：

We are going to announce the AS112 prefixes starting December 15, 2022.

針對 private network 的反解 (像是 192.168.x.x 這些網段)，目前的 NS RR 會丟到 IANA 的 blackhole server 上：

;; AUTHORITY SECTION:
10.in-addr.arpa.        86400   IN      NS      blackhole-1.iana.org.
10.in-addr.arpa.        86400   IN      NS      blackhole-2.iana.org.

這兩的 domain name 分別是 192.175.48.6 與 192.175.48.42。

而 IANA 的 blackhole server 的負荷愈來愈重，所以就有了透過 anycast 打散負荷的想法，也因為在發 anycast 時的 ASN 是 112，後來也就變成了 AS112 計畫，在 RFC 7534 裡面解釋了要怎麼做：「AS112 Nameserver Operations」。

另外在 AS112 Project 的網站上也有提到 anycast 的範圍：

The address blocks are 192.175.48.0/24 and 2620:4f:8000::/48 and its origin AS is 112.

昨天 HiNet 線路連到 AS112 的 192.175.48.x 網段會丟到日本的 WIDE，剛剛看發現已經是 Cloudflare 在台灣的點了：

;; ANSWER SECTION:
hostname.as112.arpa.    604800  IN      TXT     "Cloudflare DNS, TPE"
hostname.as112.arpa.    604800  IN      TXT     "See http://www.as112.net/ for more information."

但如果是用 Google Public DNS 查詢的話則是會到 STUIX，先前也有在其他地方看到這個有趣的組織：

;; ANSWER SECTION:
hostname.as112.arpa.    300     IN      TXT     "Taiwan Digital Streaming Co. with STUIX"
hostname.as112.arpa.    300     IN      TXT     "Taipei, TW"
hostname.as112.arpa.    300     IN      TXT     "Unicast IP: 103.147.22.82"
hostname.as112.arpa.    300     IN      TXT     "See http://as112.net/ for more information."

回過頭來看這次 Cloudflare 的加入，他們手上的機房與點都很多，這次跳進去看起來會分擔掉不少其他節點的 loading。

但另外隱憂 privacy 的考量，他們手上等於是可以看到一堆 invalid DNS query log...

自己從頭搞整套 Pi-hole 方案 (DNS 阻擋廣告的方案)

如果不用 Pi-hole 這種套件的話，從頭自己搞差不多就是這樣：「Ads blocking with OpenBSD unbound(8)」。

作者除了阻擋的必要功能部份以外，還把 log 導出來丟進 InfluxDB，透過 Grafana 可以看狀態，這類似於 Pi-hole 提供的方案：

Grafana to render the statistics ;
InfluxDB to store the information ;
syslogd(8) and awk(1) to turn DNS queries into statistics ;
collectd(1) and shell script to store unbound statistics and logs ;
unbound(8) and shell script to get and block DNS queries.

對應的 diagram 長這樣 (但為什麼作者要用 comic sans 呢...)：

瀏覽器可以用 uBlock Origin 這類方案來做，可以擋的更細緻，而手機 app 一般就只能靠這種方法過濾掉部份的廣告。

如果想要擋更多的話 (像是只擋某個 url，而不是整個 domain)，得用自建的 root CA 加上 MITM 的方式攔 HTTPS 連線，這通常都是在手機上面跑 virtual VPN，像是 iOS 上的 Surge 5 或是 Quantumult X。

AWS 台北區的網路狀況 (Routing & CDN 的情況)

在「目前 AWS 台北區只能開 *.2xlarge 的機器」這邊把機器開起來了，所以先測一下 AWS 台北區對台灣各家的 ISP 的網路狀況。

先看台灣內的點，看起來都有 peering，用 IP 測可以看到 latency 都很低：

再來試看海外 internet 的部份，美國蠻多點是從東京 AWS 過去，但測了香港的部份 www.three.com.hk，是從 TPIX 換出去，看起來台灣這邊也有一些出口，peering 與 transit 目前沒看到大問題。

但幾乎所有透過 GeoDNS-based 的查詢都會被丟到東京：

走 anycast 的 Cloudflare 就好不少，像是付費版本的 www.plurk.com 就是台北的 PoP，而免費版本的 wiki.gslin.org 也會丟到亞洲的某個點上？(看不出來是不是東京，出現 jtha 這個有點像是日本，但也有可能是泰國的點？)

這應該主要還是因為這段 IP 目前還是被認到東京的 ap-northeast-1 上，得等各家調整才有機會放到台灣的 PoP 上，不然就是要故意用沒有 EDNS Client Subnet 的 DNS resolver 了。

Route 53 提供 100% SLA，而 Route 53 Resolver 提供 99.99% SLA

AWS 宣佈 Route 53 提供 100% 的 SLA，而 Route 53 Resolver 則提供 99.99% 的 SLA：「Amazon Route 53 Resolver Endpoints announces 99.99% Service Level Agreement and updates its Service Level Agreement for Route 53 hosted zones」。

Route 53 的部份指的是 hosted zone，參考「Amazon Route 53 Service Level Agreement」這邊，可以看到是 2022/08/29 更新的條款。

Route 53 Resolver 的部份可以參考「Amazon Route 53 Resolver Endpoints Service Level Agreement」這邊，也是 2022/08/29 更新的條款。

要注意 99.99% 是指 Multi-AZ Resolver Endpoints SLA；如果是 Single-AZ Resolver Endpoints SLA 看起來是設定在 99.5%。

不確定是不是 AWS 的第一個 100% SLA 條款...