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

用 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.

照著作者說的,ukdig 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.ccns1.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.ccns1.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.nettwo.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 的性質來說不是太重要,算是有機會拿掉就順便拿下來...

Neovim 在選擇檔案名稱時的操作按鍵

Neovim 時操作檔案名稱時會是下拉選單,在 insert mode 時的畫面是這樣 (進到 insert mode 後 Ctrl-X + F):

這時候可以用上下鍵選擇檔案名稱。

在 command mode 下也有類似的功能,像是 :sp 後按 tab 選擇檔案名稱:

問題在於只能用 Ctrl-N 與 Ctrl-P 移動,而不能用上下鍵操作,兩者的 UI 類似但是操作的方式不一樣,於是就翻了翻 manual,找出對應的模式,得到是 command mode,然後用 <expr> + pumvisible() 判斷是否是在 popup menu,接著把上下鍵對應到 Ctrl-N 與 Ctrl-P:

cnoremap <expr> <Down> pumvisible() ? "\<C-n>" : "\<Down>"
cnoremap <expr> <Up> pumvisible() ? "\<C-p>" : "\<Up>"

這樣就搞定了...

Chromium (Google Chrome) 修正 DNS 查詢問題後對 Root name servers 的壓力減輕不少

先前在「Chromium (Google Chrome) 實做對 Root DNS 的影響」這邊有提過 Chromium (以及 Google Chrome) 判斷所在的網路是不是有 NXDOMAIN hijack 的程式碼反而對 Root name servers 產生了巨大的 NXDOMAIN 流量。

因為上新聞所以才動了起來 (本來都沒什麼在動),後來提供的方法是變成可以設定的選項,但預設是關閉的,這樣一來就可以改善 Root name servers 的壓力:「Add multi-state DNS interception policy - functionality piece.」。

而後在 Google Chrome 87 版進入 stable channel 後開始大幅緩解 (各平台分別在 2020/11/17 與 2020/11/18 釋出),在繼續觀察幾個月後,上個禮拜 Verisign 的人在 APNIC 這邊更新了消息:「How Chromium reduced Root DNS traffic」。

這是去年八月時丟出來的資料,可以看到趨勢往上:

這是後續的資料,從 87 版釋出後開始往下:

另外我覺得比較好玩的是這個,在「Issue 1090985: Disable Intranet Redirect Detector by default」這邊看到這樣的說明:

看起來沒什麼問題,先 merge 再說... 是這樣玩嗎 XDDD