Tag: name

ICANN 總算是同意將 .internal 保留起來了

在「Reserving .INTERNAL for Private-Use Applications」這邊總算是看到通過保留 .internal 的決議了。

整個程序意外的長，大致上有幾個時間區塊，第一個區塊是 2020 年的時候提案以及告知相關單位 (IETF 以及 IAB)，並且得到配合的回覆。

然後就到 2022 年的時候 (2021 年不見了，不確定是不是與 COVID-19 有關) 收取公眾意見，2023 年又再收取一次意見，最後決定選 .internal 保留，然後 2024 年七月決議。

另外文件裡剛好提到「IANA-managed Reserved Domains」，看起來是由 IANA 管理的 reserved domains，可以看到很多 IDN...

超長網域名稱會遇到的 TLS certificate 問題

在「L(O*62).ONG: Make your URL longer (looooooooooooooooooooooooooooooooooooooo...)」這邊看到的有趣東西，網站是「L(o*62).ong - Make your URL longer」，網站的主人還在搞事就被貼到 Hacker News 上，所以他就上來說明一下發生了什麼事情...

在 id=40543697 這邊提到網域名稱過長導致撞到 TLS certificate 中 commonName (CN) 欄位長度限制的問題：

The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.

This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.

Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.

不過後面有人提到 commonName 在網頁用的 TLS certificate 已經 deprecated 很久了，而 Let's Encrypt 在 2023 年的時候已經支援 commonName 留空，改用 Subject Alternative Name，可以到 255 chars。

留言裡面所連結的 Let's Encrypt 公告上面也提到了類似的事情：「Simplifying Issuance for Very Long Domain Names」。

Additionally, the CN is limited to at most 64 characters, while SANs can be significantly longer. This means that the CN is not only redundant, but actively restrictive: a certificate which has a Common Name cannot contain only very long domain names, because none of them would fit in the CN. For these reasons, the BRs state that for Domain Validated certificates, the Common Name field is "not recommended".

所以看起來是各家系統還沒有跟著改 (因為 Let's Encrypt 先前需要 CN 有值)，但如果是自己申請的應該是可以自己避開了 (生 csr 的時候就改用 SAN)？

.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 要被放進去算是補一些決議？真的有公司想要申請這六組任何一個應該都不會過...

歌曲與專輯名稱的各種變化

Hacker News 上看到「Horrible edge cases to consider when dealing with music (2022) (dustri.org)」這篇，講音樂產業各種奇怪種奇怪的 case，2022 年的原文在這邊：「Horrible edge cases to consider when dealing with music」，裡面有蠻大的篇幅都在講名稱的問題...。

這讓我想到這則推：

基本上會遇到各種 escaping 與 UTF-8 的處理，另外文章裡面提到會遇到超長名稱，也就是 VARCHAR(255) 的剋星... 不確定之前在 K 社大量取得授權的時候有沒有遇到這張 1999 年的專輯 (下面這是一張專輯的名字)：

When the Pawn Hits the Conflicts He Thinks Like a King What He Knows Throws the Blows When He Goes to the Fight and He'll Win the Whole Thing 'Fore He Enters the Ring There's No Body to Batter When Your Mind Is Your Might So When You Go Solo, You Hold Your Own Hand and Remember That Depth Is the Greatest of Heights and If You Know Where You Stand, Then You Know Where to Land and If You Fall It Won't Matter, Cuz You'll Know That You're Right.

其他文章裡面提到的應該都算是見怪不怪的情境，像是單曲七個小時... 這種在 server side 還拼的過去，但在行動平台上面比較苦命，直接把整曲都放進 memory 裡面的話有可能會炸。

320kbps 七個小時差不多是 1GB，如果沒注意這點，直接處理 DRM 的話瞬間就會吃到 2GB RAM；如果拉到 CD quality 的資料量就更明顯了。

然後你會發現，把音樂創作人的任何資料都當作 untrusted input 的態度來設計系統 (但你不能 reject)，問題通常就不會太大 XD

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 這樣的網域，所以應該是還有不少東西要改...

用 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 上去應該就會動了 (只是沒有兩台互相備援)。

Akamai Shared Domains 加入 PSL (Public Suffix List)

Akamai 把自家的 shared domains 申請加入 PSL (Public Suffix List)：「Adding Akamai Shared Domains to the Public Suffix List」。

提到 PSL，常被拿來舉例的應該就是 supercookie 了，也就是把 cookie 的有效網域設到 .com 或是 .org 這種 top level domain，這樣就可以跨很多站台追蹤使用者了 (所以被稱為 supercookie)，而 PSL 則可以被拿來限制這些網域名稱。

而在 Akamai 的例子來說，edgekey.net 下面的使用者都會共用 cookie，對於安全與隱私的考量其實不太好。這次把這些網域加到 PSL 之後，變成 edgekey.net 這層無法設定 cookie，而 one.edgekey.net 與 two.edgekey.net 各自有自己的 cookie namespace，這樣就好一些了...

順帶一提，除了瀏覽器會引入 PSL 來過濾外，使用者端可以靠 Privacy Badge 來過濾掉這類的 cookie，因為 Privacy Badge 會針對這類網域清掉 cookie 再送出 HTTP request。

Akamai 的文章裡面也有提到這件事情：

The PSL contains multi-party domain suffixes and is used by a wide range of client software (for example, web browsers) to implement policy decisions, such as to prevent cookies from being set on public or multi-party domains.

要求參數名稱要加上單位的請願

在 Hacker News 上看到「Please put units in names (ruudvanasseldonk.com)」這邊的討論，看到的時候已經超過 900 點了 (好像還在急遽成長)，算是爆紅狀態，可以感覺到超多 developer 們的怒氣 XDDD

原文在「Please put units in names」這篇，在講參數的命名要加上單位，尤其是時間相關的參數。

時間相關的參數根本沒有共識，你不查資料不會知道是 ns、ms 還是 seconds，所以就會出現象在這三個程式語言跑出來的時間是不一樣的：

然後你就翻桌了 XDDD

Hacker News 拿到 hackernews.com 了

在 Hacker News 上看到「Hackernews.com (hackernews.com)」這則消息，有人注意到 hackernews.com 被指到 news.ycombinator.com...

一開始有人猜測只是第三方指過來：

LeoPanthera 1 day ago

With a different registrar to ycombinator.com, this is likely not owned by Y Combinator, and therefore difficult to trust that it won't start being malicious in the future.

不過後來 dang (Hacker News 的管理員) 有出來證實這個網域名稱目前是在他們旗下了：

dang 1 day ago

It's owned by YC now. We got it earlier this year. That's why it redirects to HN!

以 Hacker News 的性質來說不是太重要，算是有機會拿掉就順便拿下來...