用 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 不會誤會。

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 拿到 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 的性質來說不是太重要,算是有機會拿掉就順便拿下來...

Wikimedia Commons 發現的印度異常流量

Hacker News Daily 上看到「Investigate unusual media traffic pattern for AsterNovi-belgii-flower-1mb.jpg on Commons」這個,維基百科拿來存放各種多媒體檔案的 Wikimedia Commons 發現有大量的印度流量都打進了 https://upload.wikimedia.org/wikipedia/commons/thumb/1/16/AsterNovi-belgii-flower-1mb.jpg/1280px-AsterNovi-belgii-flower-1mb.jpg 這張圖片,而這佔了 EQSIN (新加坡伺服器的代碼) 中 20% 的流量:

由於 User-AgentReferer 都沒有資訊,可以確認這不是瀏覽器造成的流量,但也因為沒有有用的資訊,變得很難查。

接下來有使用者提到時間點可能跟 TikTok 在印度被 ban 有關,因為在被 ban 後有很多使用者會去找替代的服務,而開發者有可能就直接拿這張圖來當啟動畫面或是背景畫面。

所以他們把熱門的替代服務都看了一輪,也都沒看到這張圖。後來他們猜測有可能是抓了但沒顯示在畫面上,所以開始交叉測試:在開 app 後就去 Hive 掃 HTTP log,然後找到一個 app。

後來為了要確認是不是這個 app,他們架了一組 DNS server 記錄查詢的網域名稱,看看 app 會不會觸發查詢 upload.wikimedia.org 這個網域名稱,而不出所料的確認了,而且真的就是在啟動時有抓,但是沒有顯示在畫面上。

接下來就是想辦法聯絡開發團隊,而目前 Wikimedia Commons 這邊先以 User-Agent 擋掉這些需求了。

另外在 Hacker News 上的討論「20% of requests for Wikimedia Commons are for one image of a flower (wikimedia.org)」也很有趣,有其他事件的苦主在當年遇到 MSN 直接用他網站上的圖片導致他的伺服器快掛,而且反應了很多次都沒用,然後他就把圖片換成「Netscape Now」,然後十五分鐘內就被解決了:

At the height of the browser wars I once woke up to Microsoft hotlinking a small button for downloading our software from the MSN homepage. I tried to reach someone there for hours but nobody cared enough to do something about it. The image was small (no more than a few K), but the millions of requests that page got were enough to totally kill our server.

Finally, I replaced the image on there with a 'Netscape Now' button. Within 15 minutes the matter was resolved.

找了一下圖片,看起來應該是類似這種的圖:

要直接反擊讓人會痛... XD

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

Amazon Route 53 支援 DNSSEC

也是個大家等蠻久的功能,AWS 總算在 Amazon Route 53 上推出 DNSSEC 了:「Announcing Amazon Route 53 support for DNSSEC」。

他需要掛 AWS KMS,這部份會有一些費用在裡面,不過應該是還好...

不過 web console 目前有個明顯的缺點:透過 Route 53 註冊的網域,又用 Route 53 自家服務的情況下,設定 DNSSEC 的整合沒有做的很好,不能直接快速設定。

現在得自己設定演算法,然後複製 public key 到另外一邊,當你有一堆網域要設定的時候就會覺得很煩了...

抓出正在使用的 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」。

Google Chrome 的顯示完整 URL 的方式又改了...

剛剛更新 Google Chrome 後發現 address bar 又被動手腳了 (我是 beta channel 的版本),在網址列上的 Protocol (Scheme) 與 www subdomain 不見了,而本來裝 Suspicious Site Reporter 可以讓 URL bar 恢復的方式也失效了。

翻了一下老問題「Chrome address bar no longer shows protocol or www subdomain」,裡面有提到新的解法 (他寫的當下) 是「The current solution in Chrome 83+」這個,直接在網址列上選右鍵,可以看到 Always show full URLs 這個選項,這是整個 Google Chrome 的選項,而非單一站台選項,選下去後就生效了:

而本來的 Suspicious Site Reporter 也可以拔掉了 (沒有用處了)。

ICANN 否決 .org 與 .ngo 的交易

ICANN 否決了 .org.ngo 網域控制權的交易:「ICANN Board Withholds Consent for a Change of Control of the Public Interest Registry (PIR)」。

Today, the ICANN Board made the decision to reject the proposed change of control and entity conversion request that Public Interest Registry (PIR) submitted to ICANN.

事情主要是起於 PIR (Public Interest Registry) 在 2019/11/13 宣佈他們的母單位 ISOC (Internet Society) 將被 Ethos Capital 併購,而這包含了 .org.ngo 網域的資產,這也代表了由 PIR 控制的網域會從非營利單位移到營利單位下 (總共有七個網域,其中最重要的是 .org,有超過一千萬個網域在上面),於是引發許多人的關注:

On 13 November 2019, PIR announced that ISOC, its parent organization, had reached an agreement with Ethos Capital, under which Ethos Capital would acquire PIR and all of its assets from ISOC. Under the agreement, PIR would also be converted from a Pennsylvania not-for-profit corporation to a for-profit Pennsylvania limited liability company. ISOC created and agreed to the transaction details that are under review.

而在隔天 2019/11/14,PIR 依照規定向 ICANN 送出「Notice of Indirect Change of Control and Entity Conversion」申請,依照規定,ICANN 需要在 2020/05/04 前批准或是否決,也就是這幾天就要做出決定。

而 ICANN 昨天宣佈了否決這項提案,暫時搞定了這件事情... 接下來看 Ethos Capital 會不會有什麼反擊 (上訴或是上法院)。