停止使用 Spamhaus DNSBL

剛剛看到「If you query Spamhaus Projects’ legacy DNSBLs via DigitalOcean move to the free Data Query Service」這篇,覺得愈來愈詭異了,研究了目前的情況後決定停用 Spamhaus

現在已經愈來愈少自己架設 mail server 了,不過我自己還是留了幾個 domain 跑在自己架設的 Postfix 上面,最主要是 command line 下面用 Mutt 讀信還是蠻方便的,另外一方面是確保一個信箱是不受到大企業的管制。

如果不是拿套裝軟體直接架設的話,自己架設 mail server 會有不少東西要設定:在 MTA 這端通常會使用 DNSBL 擋掉已知會發 spam 的 IP address。

DNSBL 的原理不難,就是拿 IPv4 address 組合一個 hostname,透過 DNS 查詢就會知道這個 IPv4 address 是否在清單;換句話說,就是拿 DNS protocol 當作 API,當作資料庫查詢。

舉個例子來說,假設我要查 188.235.18.134 這個位置的情況 (從「Worst /24 blocks based on total spam count」這邊翻出來的),這邊使用 SpamCop 的清單,我先把 IPv4 address 反過來變成 134.18.235.188,然後再加上 SpamCop 所指定的 bl.spamcop.net,變成 134.18.235.188.bl.spamcop.net,接下來查詢就可以查到:

134.18.235.188.bl.spamcop.net has address 127.0.0.2

如果是 168.95.1.1 的話,同樣方法組合成 1.1.95.168.bl.spamcop.net 可以看到沒有在 SpamCop 清單內:

Host 1.1.95.168.bl.spamcop.net not found: 3(NXDOMAIN)

這邊選擇用 DNS 的好處包括了 DNS resolver 及 DNS library 自然的 cache,不需要 Postfix 這類 MTA 再自己實作 cache 層,對於有大量信件 (無論是正常的或是 spam) 進來的時候也不會造成提供清單的服務大量的負載。

回頭來說 Spamhaus 的情況,他們公告要擋 DigitalOcean 的理由很奇怪,因為 DigitalOcean 架設了自己的 mirror 所以他們不知道使用的量,要使用者去 Spamhaus 上註冊申請後拿到一個自己的 your_DQS_key.zen.dq.spamhaus.net 使用。

有了 unique key 在 query,這樣就給了 Spamhaus 很清晰追蹤資料,加上 Privacy Policy 裡面的資訊:

We may have to share your personal data with the parties set out below for the purposes set out in the table in paragraph 4.
[...]
– Third parties to whom we may choose to sell, transfer, or merge parts of our business or our assets. Alternatively, we may seek to acquire other businesses or merge with them. If a change happens to our business, then the new owners may use your personal data in the same way as set out in this privacy notice.

這樣就知道他們想要做什麼了...

另外一方面,查資料的時候發現他們已經擋掉 Google Public DNS 以及 Cloudflare DNS

這是我自己架設 Unbound 的查詢:

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
2.0.0.127.zen.spamhaus.org has address 127.0.0.4
2.0.0.127.zen.spamhaus.org has address 127.0.0.2

這是 Google Public DNS (8.8.8.8):

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

Host 2.0.0.127.zen.spamhaus.org not found: 3(NXDOMAIN)

這是 Cloudflare DNS (1.1.1.1):

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

2.0.0.127.zen.spamhaus.org has address 127.255.255.254

在 Spamhaus 的「Frequently Asked Questions (FAQ)」這篇裡面有提到 127.255.255.254 的回應是「Query via public/open resolver」:

127.255.255.252	Any	Typing error in DNSBL name
127.255.255.254	Any	Query via public/open resolver
127.255.255.255	Any	Excessive number of queries

所以還蠻清楚這家的東西已經不能碰了...

.internal 被提案要列入 Reserved Top-Level Domain

意外看到「Proposed top-level domain string for private use: ".internal" (icann.org)」這篇,發現 .internal 還沒被 ICANN 列入 reserved top-level domain?原文在 ICANN 的網站上:「Proposed Top-Level Domain String for Private Use」。

這邊有兩個不同的權力組織 (團體),一邊是掌握著 root name server 規範的非營利組織 ICANN,不過 ICANN 也決定了有哪些 top-level domain 可以賣...;另外一邊是社群與 IETF 在寫下各種建議與制定標準。

現在看起來是在 RFC 6762 (Multicast DNS) 這邊講 Multicast DNS 的地方,意外的在附錄的提到了 .internal 這組 domain:

We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose:

然後列出了六個 domain:

      .intranet.
      .internal.
      .private.
      .corp.
      .home.
      .lan.

看起來也不是說這六組要被保留,比較像是講個現象?現在 .internal 要被放進去算是補一些決議?真的有公司想要申請這六組任何一個應該都不會過...

microsoft.com 的 DNS 出包

Hacker News Daily 上的「Tell HN: Microsoft.com added 192.168.1.1 to their DNS record」這邊看到的,看起來是某種 misconfiguration 造成 microsoft.comA record 除了給正常的 IPv4 address 外,還給出了 192.168.1.1192.168.1.0 的 IPv4 address。

不過裡面比較有趣的是 id=38704301 這個,提到他反而查不到,看 log 發現被 dnsmasq 認定是 DNS rebinding 的攻擊而擋下來不回應任何 IP address:

I was getting an empty answer for microsoft.com. Turns out my dnsmasq is blocking it:

  $ dig microsoft.com. | grep EDE
  ; EDE: 15 (Blocked)

  resolver.log:Dec 20 00:43:57 router dnsmasq[8172]: possible DNS-rebind attack detected: microsoft.com

翻了 dnsmasq 的 manpage,可以看到這個功能:

--stop-dns-rebind

Reject (and log) addresses from upstream nameservers which are in the private ranges. This blocks an attack where a browser behind a firewall is used to probe machines on the local network. For IPv6, the private range covers the IPv4-mapped addresses in private space plus all link-local (LL) and site-local (ULA) addresses.

id=38704159 這邊也有類似的情況,不過這邊是提到 OpenWrt

microsoft.com is currently IPv6-only on my network, because OpenWrt's DNS rebinding protection filters out the A records:

  $ ping -4 microsoft.com
  ping: microsoft.com: Address family for hostname not supported

  $ ping -6 microsoft.com
  PING microsoft.com(2603:1030:c02:8::14 (2603:1030:c02:8::14)) 56 data bytes
  64 bytes from 2603:1030:c02:8::14 (2603:1030:c02:8::14): icmp_seq=1 ttl=112 time=68.4 ms

用 bubblewrap (bwrap) 針對特定程式抽換 /etc/resolv.conf

我家裡的桌機有兩個有線網路,一個是 HiNet 光世代,另外一個是社區網路 (其實出去也是光世代),像是這篇提到的架構 (只是當時還住在後山埤,另外那條是北都的第四台網路):「Ubuntu 下面搞 Multi-home 架構」。

我在上面那篇提到要怎麼以 source ip address 來決定 routing,然後我就可以跑 Squid,並且在 Squid 上面指定 source ip 來達到目標。

後來有做了一些改變,最主要是換成 microsocks

一個原因個是 Squid 比較「重」(heavy),microsocks 比較清量;第二個是 Squid 走的 CONNECT 支援的程式比較少,SOCKS 支援度高一些。

不過當 HiNet 線路有問題的時候,會發現 DNS 的查詢失敗,主要的原因是 microsocks 會讀 /etc/resolv.conf 的資料,裡面是 168.95.192.1168.95.1.1,而且 microsocks 呼叫的 getaddrinfo() 沒有 IP binding,還是會試著走原來的線路出去。

所以這邊就得想辦法把 /etc/resolv.conf 換成我們自己加工的版本,這邊我用了 bubblewrap 來做:

/usr/bin/bwrap --unshare-all --share-net --ro-bind /usr /usr --ro-bind /lib /lib --ro-bind /lib64 /lib64 --ro-bind ~/microsocks/resolv.conf /etc/resolv.conf /usr/sbin/microsocks -i 0.0.0.0 -p 11080 -b 192.168.2.123

先把所有東西都隔開 (--unshare-all),再把網路開通 (--share-net),接著把 /usr/lib 以及 /lib64 掛上來 (因為 microsocks 需要這些 library),然後 /etc 下的東西只掛了一個自己建的 /etc/resolv.conf 上來,裡面指到 router 上 (我的 router 有 DNS proxy):

nameserver 192.168.2.254

這邊因為是 subnet traffic,自動選定的 source ip 會是本機 192.168.2.x 的 IP,就剛好避開這個問題,這樣無論 HiNet 線路的情況都不會影響到 microsocks 了。

這邊有個小插曲,因為追問題所以用 strace 看了半天才發現一開始我用 bubblewrap 時是這樣寫:

/usr/bin/bwrap --bind / / --bind ~/microsocks/resolv.conf /etc/resolv.conf /usr/sbin/microsocks -i 0.0.0.0 -p 11080 -b 192.168.2.123

結果發現 microsocks 第一次讀 /etc/resolv.conf 的時候的確是讀到 ~/microsocks/resolv.conf,但網路斷掉後 (/etc/resolv.conf 會被改動) 他會讀到原始的 /etc/resolv.conf (i.e. 沒有被替換掉),判讀 strace log 到這邊的時候差點罵出來... @_@

沒有往下追的太細,但猜測可能是 --bind / /--bind ~/microsocks/resolv.conf /etc/resolv.conf 有處理上的衝突?總之我後來改成 --unshare-all,再把要掛的東西掛上去,就沒這個問題了...

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.netWHOIS 可以發現這也是個老域名了,甚至比 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 這樣的網域,所以應該是還有不少東西要改...

透過 mDNS 建立內部網路的 fingerprint

Hacker News 上看到透過 mDNS 建立 fingerprint 的方式,進而定位使用者身分:「Brute-forcing a macOS user’s real name from a browser using mDNS (fingerprint.com)」,原文在「Demo: Brute-forcing a macOS user’s real name from a browser using mDNS」。

利用發 HTTP(s) request 出去時,雖然都是傳回 Failed to fetch 錯誤,但因為 hostname 存在時會是 connection timeout,而不存在時會直接因為 DNS 查不到而很快 failed 掉,這個時間差異產生了 side channel,可以透過時間差異知道某個 hostname 是否存在。

這個技巧配合字典就可以大量掃描 *.local 的 mDNS 網段,進而產生出內部網路的 fingerprint。

這個問題應該是有標準解法 (或是有被提案過的解法),就是不讓 internet domain 存取 local domain 的東西,像是避免 internet 上的網站透過 JavaScript 碰到 http://127.0.0.1:xxx/ 的機制。

應該是把 *.local 用同樣方式對待就能避開這個問題?

處理 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」。

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