Tag: dns

處理 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"

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 條款...

用 dig 查瑞士的 top domain 剛好會遇到的 "feature"

在 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 查不到反解的問題

就如同標題所說的，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 上去應該就會動了 (只是沒有兩台互相備援)。

Curl 的 --socks5 與 --socks5-hostname

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:// 也有異曲同工之妙...