幹壞事是進步最大的原動力
看到 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」。
還看不太懂這家公司在搞什麼...
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"
前幾天在 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 裡面...
在「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 這種套件的話，從頭自己搞差不多就是這樣：「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 台北區只能開 *.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 了。
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 條款...
在 Hacker News 上看到「DNS Esoterica - Why you can't dig Switzerland」這篇，裡面提到 dig 的 "feature"。
拿來查 tw 的 NS 會這樣下：
$ dig tw ns
結果會是列出所有的 NS server：
;; ANSWER SECTION: tw. 3600 IN NS h.dns.tw. tw. 3600 IN NS a.dns.tw. tw. 3600 IN NS g.dns.tw. tw. 3600 IN NS d.dns.tw. tw. 3600 IN NS anytld.apnic.net. tw. 3600 IN NS f.dns.tw. tw. 3600 IN NS b.dns.tw. tw. 3600 IN NS e.dns.tw. tw. 3600 IN NS c.dns.tw. tw. 3600 IN NS ns.twnic.net.
照著作者說的，uk 的 dig uk ns 可以得到類似的結果：
;; ANSWER SECTION: uk. 86400 IN NS dns1.nic.uk. uk. 86400 IN NS dns4.nic.uk. uk. 86400 IN NS nsa.nic.uk. uk. 86400 IN NS nsb.nic.uk. uk. 86400 IN NS nsc.nic.uk. uk. 86400 IN NS nsd.nic.uk. uk. 86400 IN NS dns3.nic.uk. uk. 86400 IN NS dns2.nic.uk.
但如果你下 dig ch ns 就會出現錯誤，像是這樣：
; <<>> DiG 9.16.1-Ubuntu <<>> ch ns ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 5019 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. CH NS ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 15 06:54:24 CST 2022 ;; MSG SIZE rcvd: 28
原因是因為 CH 這個關鍵字是 Chaosnet 的縮寫，而被特殊解讀：
Set the query class. The default class is IN; other classes are HS for Hesiod records or CH for Chaosnet records.
要避開這個解讀需要加上一個 dot (.)，採用 FQDN 的方式列出：
dig ch. ns
就會得到正確的結果：
;; ANSWER SECTION: ch. 86400 IN NS a.nic.ch. ch. 86400 IN NS b.nic.ch. ch. 86400 IN NS f.nic.ch. ch. 86400 IN NS d.nic.ch. ch. 86400 IN NS e.nic.ch.
另外的方式是 dig -c IN -t NS ch，透過參數的方式讓 dig 不會誤會。
就如同標題所說的，Ptt 對外寄信的伺服器 node.ptt.cc 查不到反解的問題：
$ host node.ptt.cc node.ptt.cc has address 140.112.172.16 $ host 140.112.172.16 Host 16.172.112.140.in-addr.arpa not found: 2(SERVFAIL)
情況大概是這樣，Ptt 使用的 140.112.172.0/27 這個網段 (尾碼從 0～31) 不是 /24 以上的範圍，而 140.112.172.0/24 是台大計中管轄範圍，所以台大就把 140.112.172.x 這段的反解 PTR record 用 CNAME 的方式指到 x.0-31.172.112.140.in-addr.arpa，像是 140.112.172.16 這樣：
;; ANSWER SECTION: 16.172.112.140.in-addr.arpa. 86400 IN CNAME 16.0-31.172.112.140.in-addr.arpa.
然後再針對 0-31.172.112.140.in-addr.arpa 設定 NS RR 到 ns0.ptt.cc 與 ns1.ptt.cc 兩台 NS server：
;; AUTHORITY SECTION: 0-31.172.112.140.in-addr.arpa. 86400 IN NS ns1.ptt.cc. 0-31.172.112.140.in-addr.arpa. 86400 IN NS ns0.ptt.cc.
但是 ns0.ptt.cc 與 ns1.ptt.cc 都不見了：
$ host ns0.ptt.cc Host ns0.ptt.cc not found: 3(NXDOMAIN) $ host ns1.ptt.cc Host ns1.ptt.cc not found: 3(NXDOMAIN)
導致反解查不到對應的資料 (會是 SERVFAIL)：
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58463
猜了一下，看起來 ns0.ptt.cc 還活著，只是 Cloudflare 上面的 DNS record 沒設定過去：
$ dig ns0.ptt.cc @140.112.172.16 ;; ANSWER SECTION: ns0.ptt.cc. 300 IN A 140.112.172.16
不過 ns1.ptt.cc (140.112.172.10) 看起來就沒服務了，但至少在 Cloudflare 上補個 DNS record 上去應該就會動了 (只是沒有兩台互相備援)。
SOCKS5 支援用 hostname 連線，而且是透過 SOCKS server 查 IP address，然後查資料的時候翻到「Curl: Re: ��: Why resolve the dns locally when using a socks5 proxy」這篇，發現 Curl 的 --socks5 原來有雷，一般人會想要用的應該是 --socks5-hostname 才對 XDDD
這是 --socks5：
Use the specified SOCKS5 proxy - but resolve the host name locally. If the port number is not specified, it is assumed at port 1080.
而這是 --socks5-hostname：
Use the specified SOCKS5 proxy (and let the proxy resolve the host name). If the port number is not specified, it is assumed at port 1080.
另外也有 --socks4 與 --socks4a，不過 SOCKS4a 的協定最主要就是加上 hostname 的連線：
SOCKS4a extends the SOCKS4 protocol to allow a client to specify a destination domain name rather than an IP address; this is useful when the client itself cannot resolve the destination host's domain name to an IP address.
然後隔壁棚的 socks5:// 與 socks5h:// 也有異曲同工之妙...