uv:用 Rust 寫的 Python Packaging 替代方案

社群好幾個地方都有提到的「uv: Python packaging in Rust」這個,文章開頭的說明有快速說明目標是 pip 的 drop-in replacement:

TL;DR: uv is an extremely fast Python package installer and resolver, written in Rust, and designed as a drop-in replacement for pip and pip-tools workflows.

這跟「Ruff:用 Rust 寫的 Python Linter」都是 Astral 下的專案,主打用 Rust 改善速度的專案。

馬上想到的是 package resolver,這指的是依照每個套件指定的相依條件,找出符合所有條件的版本組合。

這在各個語言的套件系統上都是痛點,而在「Dependency hell is NP-complete」這篇就有指出這是 NP-complete

這是因為 3SAT 問題可以 PTIME 轉成 package resolver 問題 (於是就 NP-hard 了),再加上有 PTIME 的驗證,就變成 NP-complete 了。

但看說明應該是不只這個部分,包括了一些 i/o 類操作的改善。

除了速度以外,uv 也提供了讓測試更方便的功能,像是在計算相容版本時,預設的演算法是儘量都裝最新版,但你可以指定要儘量裝最舊的版本,這樣對於相容性測試頗有用的:

But by passing --resolution=lowest, library authors can test their packages against the lowest-compatible version of their dependencies. (This is similar to Go's Minimal version selection.)

這個工具的出現也是頗有幫助,我記得寫 Python 專案時隨便引入個 Django,再多拉幾個套件,跑起 package resolver 就要花不少時間了,可以想像中大型專案在這塊的痛點...

另外剛剛回去看了 ruff,從去年四月 500+ 條規則增加到 700+ 條了,在發表受到注目後應該補了不少社群常用到的規則,說不定新專案可以無痛跳進去了,去年的時候試著用,有發現常見的規則還沒有支援...

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 問題應該會變成過去式...

透過 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"

如果是用有支援 ECSGoogle 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"

翻了一下,AS1239SprintAS9680 是中華在美國的 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"

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

用 Poetry 的相依性演算法解數獨 (Sudoku)

Daily Lobsters 上看到「Solving Sudoku with Poetry's dependency resolver」這篇完全是惡搞 PythonPoetry 套件 XDDD

作者搞出來的方法是這樣,指定 81 個版號來表示題目,然後跑 Poetry 找可以的版本組合:

[tool.poetry.dependencies]
python = "^3.6"
sudoku-cell11 = "*"
sudoku-cell12 = "2.0.0"
sudoku-cell13 = "*"
sudoku-cell14 = "8.0.0"
sudoku-cell15 = "*"
sudoku-cell16 = "9.0.0"
sudoku-cell17 = "*"
sudoku-cell18 = "*"
sudoku-cell19 = "*"
sudoku-cell21 = "3.0.0"
sudoku-cell22 = "7.0.0"
sudoku-cell23 = "*"
sudoku-cell24 = "6.0.0"
...

另外作者有提到,本來是打算用 Yarn 來解,但看起來各種嘗試都會搞爆 Yarn,才換到 Python 上面玩 XD

自動偵測 DNS over HTTPS 或是 DNS over TLS 的 Discovery of Designated Resolvers (DDR)

看到 Cloudflare 宣佈支援 Discovery of Designated Resolvers (DDR):「Announcing experimental DDR in 1.1.1.1」。

看了一下這以後會是新的標準 (現在還在 draft),可以自動偵測現在用的 DNS resolver 是否支援 DNS over HTTPS 或是 DNS over TLS,如果有的話就 upgrade 到 DoH 或 DoT:

This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.

目前的 spec 是去查 _dns.resolver.arpa,下面第一個是支援 DoH 的回應,第二個則是支援 DoT 的回應:

_dns.resolver.arpa  7200  IN SVCB 1 doh.example.net ( alpn=h2 dohpath=/dns-query{?dns} )
_dns.example.net  7200  IN SVCB 1 dot.example.net ( alpn=dot port=8530 )

實際上拿 1.1.1.1 測試,在 Ubuntu 20.04 下用 dig 可以看到一堆亂碼 XDDD

;; ANSWER SECTION:
_dns.resolver.arpa.     300     IN      TYPE64  \# 104 0001036F6E65036F6E65036F6E65036F6E6500000100060268320268 330003000201BB000400080101010101000001000600202606470047 00000000000000000011112606470047000000000000000000100100 0700112F646E732D71756572797B3F6E616D657D
_dns.resolver.arpa.     300     IN      TYPE64  \# 81 0002036F6E65036F6E65036F6E65036F6E65000001000403646F7400 03000203550004000801010101010000010006002026064700470000 00000000000000111126064700470000000000000000001001

改用 Docker 開了 Ubuntu 22.04 (jammy) 的 image 後,裡面的 dig 可以用 SVCB 查詢 (本來的 type64 也還是會動),另外也把內容解出來了:

;; ANSWER SECTION:
_dns.resolver.arpa.     300     IN      SVCB    1 one.one.one.one. alpn="h2,h3" port=443 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001 key7="/dns-query{?name}"
_dns.resolver.arpa.     300     IN      SVCB    2 one.one.one.one. alpn="dot" port=853 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001

這樣就不需要寫死在系統內,但要注意這樣還是會有 attacker 擋住讓你 upgrade 的問題...

用 Akamai 提供的 akahelp 分析 DNS Resolver 的資訊

整理資料的時候看到以前就看到的資訊,Akamai 有提供工具,可以看 DNS resolver 的資訊:「Introducing a New whoami Tool for DNS Resolver Information」。

這拿來分析 168.95.1.1 或是 8.8.8.8 這些服務還蠻好用的,這些對外雖然有一個 IP address 在服務,但後面是一整個 cluster,所以可以利用 Akamai 的這個工具來看分析。

像是 8.8.8.8 會給接近的 EDNS Client Subnet (ECS) 資訊 (ip 的部份看起來是隨便給一個):

$ dig whoami.ds.akahelp.net txt @8.8.8.8

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "172.217.43.194"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.35.0/24/24"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "111.250.35.149"

1.1.1.1 會給假的 ECS 資訊:

$ dig whoami.ds.akahelp.net txt @1.1.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ip" "2400:cb00:80:1024::a29e:f134"
whoami.ds.akahelp.net.  20      IN      TXT     "ecs" "111.250.0.0/24/24"

然後 168.95.1.1 則是連 ECS 都不給 XDDD

$ dig whoami.ds.akahelp.net txt @168.95.1.1

[...]

;; ANSWER SECTION:
whoami.ds.akahelp.net.  20      IN      TXT     "ns" "2001:b000:180:8002:0:2:9:114"

之前在找 DNS 類問題的時候還算可以用的工具...

AWS 推出 Amazon Route 53 Resolver DNS Firewall

長久以來的洞總算有比較好的方法補上了,AWS 推出了 Amazon Route 53 Resolver DNS Firewall:「Introducing Amazon Route 53 Resolver DNS Firewall」。

Route 53 Resolver 是 AWS 官方提供的 DNS Resolver,沒有特殊的設定的話通常會在 x.x.x.2 (/24 或是更大的網段),先前一直沒有辦法解決 data leak 的問題,也就是透過 DNS 把敏感資料從 private network 裡丟出去。

以前的作法是透過 security group 擋掉對 Route 53 Resolver 的流量 (或是透過 VPC 的 Firewall 擋),然後自己架設兩台 DNS resolver 過濾,現在 Route 53 Resolver 支援 DNS Firewall,提供 allowlist 與 blocklist 這兩個功能使用,總算是把這件事情解的比較乾淨了:

Route 53 Resolver DNS Firewall lets you create “blocklists” for domains you don’t want your VPC resources to communicate with via DNS. You can also take a stricter, “walled-garden” approach by creating “allowlists” that permit outbound DNS queries only to domains you specify. You can also create alerts for when outbound DNS queries match certain firewall rules, allowing you to test your rules before deploying for production traffic.

另外這次的 DNS Firwall 提供了兩組由 AWS 維護的清單讓人使用,包括了 malware 與 botnet:

Route 53 Resolver DNS Firewall offers two managed domain lists—malware domains and botnet command and control domains—enabling you to get started quickly with managed protections against common threats.

這樣省事多了...

抓出正在使用的 DNS Server

Hacker News 上看到的方式:「Which DNS」,另外在「Show HN: Which DNS servers are you pointing to? (nameserve.rs)」這邊也有一些討論。

這個方式是去抓 DNS server 對外的 IP,像 HiNet168.95.1.1 這種 DNS server 後面都有一堆 resolver,這個方式可以知道出去的 IP 是哪個,可以幫助分析 routing 之類的問題...

記得 Akamai 有類似的服務,不過查了一下沒找到之前有印象的那個,反倒是查到另外一組可以用的:「Introducing a New whoami Tool for DNS Resolver Information」。

AWS 推出 Route 53 Resolver Query Logs

AWS 推出可以讓你 debug 的功能:「Log your VPC DNS queries with Route 53 Resolver Query Logs」。

這個功能可以記錄 VPC 內的 DNS query:

然後也可以統計與分析:

主要是很多 debug 會需要 DNS query,但 AWS 上不太容易看到 DNS query 資訊 (常見的方式是自己另外架 DNS Resolver),這個功能可以緩解這個問題...