看起來 Apple 是打算繼續蒐集 OCSP 資訊...

在「Apple memory holed its broken promise for an OCSP opt-out (lapcatsoftware.com)」這邊看到的,原文是「Apple memory holed its broken promise for an OCSP opt-out」。

Apple 的系統機制會在每次啟動應用程式的時候去 Apple 自家的 OCSP 伺服器確認這個應用程式是否被 Apple 註銷了:

When you launch an app, macOS connects to Apple's OCSP service to check whether the app's Developer ID code signing certificate has been revoked by Apple.

本來 Apple 有說要改善,但看起來吃書了...

這有明顯的 privacy 問題,所以我的作法是參考 Apple 自家的「Use Apple products on enterprise networks」這份官方資料,把裡面所有 ocsp 相關的 record 都設到 /etc/hosts 內,目前是:

127.0.0.1 ocsp.apple.com ocsp.digicert.cn ocsp.digicert.com ocsp.entrust.net ocsp2.apple.com

可以重開機確保生效,然後用 ping ocsp.apple.com (或是其他 domain) 看看是不是 127.0.0.1

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

OpenDNS 停止在法國的 DNS Resolver 服務

前陣子法國法院要求在 DNS 層阻擋的事情 (參考「Google Public DNS 接受法國法院的阻擋要求」) 有新的進度了,OpenDNS 直接停止在法國的 DNS Resolver 服務:「OpenDNS Suspends Service in France Due to Canal+ Piracy Blocking Order」。

不是把法國當地的服務停掉改由其他地區的 anycast 提供服務,而是在服務本身上面直接阻擋法國的使用者:

Reports of problems with the OpenDNS service seemed to begin on Friday, and it didn’t take long to discover the cause. The technical issues were isolated to France and apparently parts of Portugal too, with an explanation having appeared on the OpenDNS website, perhaps as early as Thursday evening.

網站上的公告則是:

Effective June 28, 2024: Due to a court order in France issued under Article L.333-10 of the French Sport code and a court order in Portugal issued under Article 210-G(3) of the Portuguese Copyright Code, the OpenDNS service is not currently available to users in France and certain French territories and in Portugal. We apologize for the inconvenience.

這下衝突升級了...

Google Public DNS 接受法國法院的阻擋要求

看到「Google, Cloudflare & Cisco Will Poison DNS to Stop Piracy Block Circumvention」這篇,法國在 2022 年通過的體育法律反過來干涉 ISP 或是服務提供商需要配合阻擋:

Tampering with public DNS is a step too far for many internet advocates but for major rightsholders, if the law can be shaped to allow it, that’s what will happen. In this case, Article L333-10 of the French Sports Code (active Jan 2022) seems capable of accommodating almost anything.

拿文章裡面提到的 footybite.cc 測試,實際在法國開一台 Vultr 的 VPS 測試各家 Public DNS 服務,看起來目前 Google Public DNS 已經實作了,而且傳回了 RFC 8914: Extended DNS Errors 內的 EDE 16:

$ dig footybite.cc @8.8.8.8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 16 (Censored): (The requested domain is on a court ordered copyright piracy blocklist for FR (ISO country code). To learn more about this specific removal, please visit https://lumendatabase.org/notices/41606068.)
;; QUESTION SECTION:
;footybite.cc.                  IN      A

目前拿 1.1.1.1 (Cloudflare)、9.9.9.9 (Quad9) 以及 208.67.222.222 (OpenDNS) 都還沒有看到被擋。

另外實際測試,自己架設 Unbound 看起來就可以繞過去了,不知道後續會不會要求更多,像是直接要求在 internet backbone 上面過濾 DNS?(當年推 DNS over TLSDNS over HTTPS 總算要派上用場了?)

另外就是看 Cloudflare 以及其他 Public DNS 服務有沒有反對的動作...

Now-DNS 的服務

在翻 public_suffix_list.dat 的時候翻到的服務 (參考之前寫的「Mozilla 維護的 Public Suffix List」,或是維基百科上面 Public Suffix List)。

看了一下是 2017 年左右提供 Dynamic DNS 服務:「Creating a Free DDNS Service」服務,似乎沒有限制多少 record?

要說缺點的話,第一個是列出來的 domain 不算漂亮,不過如果是自己有 domain,掛 CNAME 上去的話也已經夠用了。

另外一個是看起來他的 DNS 伺服器都放在 OVH 的機房?雖然地域上是放不同位置,不過還是有滅掉的風險?

看起來可以把一些小東西掛上去用看看?

Porkbun 的網域註冊服務

在「Tell HN: I think there are major issues with Google –> Squarespace domains」這篇裡面提到 Google 把網域註冊服務賣給了 Squarespace 後發生的問題,結果下面有很多人都提到 Porkbun 這家註冊商。

看了一下留言,主要的缺點是沒有支援所有的 tld,所以有些 domain 可能沒辦法轉移到 Porkbun,不過大多數常見的都有支援。

在台灣的話... 因為 Gandi 在台灣有公司可以直接開發票報帳,對很多台灣公司來說方便不少。

先記錄起來看看...

Route 53 Resolver DNS Firewall 的 chain 處理

在「Stop the CNAME chain struggle: Simplified management with Route 53 Resolver DNS Firewall」這邊看到的新功能。

說實話... 我早就忘記 Route 53 Resolver DNS Firewall 這個產品了,我查資料才發現我在 2021 年的時候寫過:「AWS 推出 Amazon Route 53 Resolver DNS Firewall」。

這個產品的用途是避免透過 DNS 將敏感資訊打出去,不過先前的產品的條件很死,遇到 CNAME 或是 DNAME 的情況,你必須事先把可能後續的 record 也放進白名單才行,所以如果遇到類似於 X (Twitter) 用的 pbs.twimg.com 的情況就很麻煩了:

;; ANSWER SECTION:
pbs.twimg.com.          300     IN      CNAME   cs196.wac.edgecastcdn.net.
cs196.wac.edgecastcdn.net. 3409 IN      CNAME   cs2-wac.apr-8315.edgecastdns.net.
cs2-wac.apr-8315.edgecastdns.net. 110 IN CNAME  cs2-wac-us.8315.ecdns.net.
cs2-wac-us.8315.ecdns.net. 110  IN      CNAME   cs45.wac.edgecastcdn.net.
cs45.wac.edgecastcdn.net. 725   IN      A       117.18.237.70

理想上是你放行 pbs.twimg.com 就好,但因為 CNAME 的關係,你可能會需要多放行 *.edgecastcdn.net 以及 *.ecdns.net

可是這是第三方的服務,你無法控制對方怎麼切換 (沒有 API contract 的概念),像是有時候他會跳到 Fastly

;; ANSWER SECTION:
pbs.twimg.com.          290     IN      CNAME   dualstack.twimg.twitter.map.fastly.net.
dualstack.twimg.twitter.map.fastly.net. 290 IN A 151.101.40.159

如果之後又跑出 Akamai 或是 CloudFront 的話就沒完沒了。

另外一種常見的情況是第三方的 API endpoint,對方有可能有多個不同的點做 DR 切換,有可能 CNAME 到 AWSELB 或是 GCPCloud Load balancing 上。

所以為了「保險」,這個方式通常都是開整個 CDN 的服務,但這麼一來攻擊者可以透過租用這些服務 (像是 *.cloudfront.net),搭配一些其他比較鬆的 rule 鑽出來。

這次的這個功能有點 stateful firewall 的概念,第一個啟動的 record 是被放行的,那 CNAME 或是 DNAME 延伸出來的 record 也跟著放行,這樣算是補強了這個問題...

停止使用 Spamhaus DNSBL

剛剛看到「If you query Spamhaus Projects’ legacy DNSBLs via DigitalOcean move to the free Data Query Service」這篇,覺得愈來愈詭異了,研究了目前的情況後決定停用 Spamhaus

現在已經愈來愈少自己架設 mail server 了,不過我自己還是留了幾個 domain 跑在自己架設的 Postfix 上面,最主要是 command line 下面用 Mutt 讀信還是蠻方便的,另外一方面是確保一個信箱是不受到大企業的管制。

如果不是拿套裝軟體直接架設的話,自己架設 mail server 會有不少東西要設定:在 MTA 這端通常會使用 DNSBL 擋掉已知會發 spam 的 IP address。

DNSBL 的原理不難,就是拿 IPv4 address 組合一個 hostname,透過 DNS 查詢就會知道這個 IPv4 address 是否在清單;換句話說,就是拿 DNS protocol 當作 API,當作資料庫查詢。

舉個例子來說,假設我要查 188.235.18.134 這個位置的情況 (從「Worst /24 blocks based on total spam count」這邊翻出來的),這邊使用 SpamCop 的清單,我先把 IPv4 address 反過來變成 134.18.235.188,然後再加上 SpamCop 所指定的 bl.spamcop.net,變成 134.18.235.188.bl.spamcop.net,接下來查詢就可以查到:

134.18.235.188.bl.spamcop.net has address 127.0.0.2

如果是 168.95.1.1 的話,同樣方法組合成 1.1.95.168.bl.spamcop.net 可以看到沒有在 SpamCop 清單內:

Host 1.1.95.168.bl.spamcop.net not found: 3(NXDOMAIN)

這邊選擇用 DNS 的好處包括了 DNS resolver 及 DNS library 自然的 cache,不需要 Postfix 這類 MTA 再自己實作 cache 層,對於有大量信件 (無論是正常的或是 spam) 進來的時候也不會造成提供清單的服務大量的負載。

回頭來說 Spamhaus 的情況,他們公告要擋 DigitalOcean 的理由很奇怪,因為 DigitalOcean 架設了自己的 mirror 所以他們不知道使用的量,要使用者去 Spamhaus 上註冊申請後拿到一個自己的 your_DQS_key.zen.dq.spamhaus.net 使用。

有了 unique key 在 query,這樣就給了 Spamhaus 很清晰追蹤資料,加上 Privacy Policy 裡面的資訊:

We may have to share your personal data with the parties set out below for the purposes set out in the table in paragraph 4.
[...]
– Third parties to whom we may choose to sell, transfer, or merge parts of our business or our assets. Alternatively, we may seek to acquire other businesses or merge with them. If a change happens to our business, then the new owners may use your personal data in the same way as set out in this privacy notice.

這樣就知道他們想要做什麼了...

另外一方面,查資料的時候發現他們已經擋掉 Google Public DNS 以及 Cloudflare DNS

這是我自己架設 Unbound 的查詢:

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
2.0.0.127.zen.spamhaus.org has address 127.0.0.4
2.0.0.127.zen.spamhaus.org has address 127.0.0.2

這是 Google Public DNS (8.8.8.8):

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

Host 2.0.0.127.zen.spamhaus.org not found: 3(NXDOMAIN)

這是 Cloudflare DNS (1.1.1.1):

gslin@home [~] [05:09/W4] host 2.0.0.127.zen.spamhaus.org 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

2.0.0.127.zen.spamhaus.org has address 127.255.255.254

在 Spamhaus 的「Frequently Asked Questions (FAQ)」這篇裡面有提到 127.255.255.254 的回應是「Query via public/open resolver」:

127.255.255.252	Any	Typing error in DNSBL name
127.255.255.254	Any	Query via public/open resolver
127.255.255.255	Any	Excessive number of queries

所以還蠻清楚這家的東西已經不能碰了...

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

microsoft.com 的 DNS 出包

Hacker News Daily 上的「Tell HN: Microsoft.com added 192.168.1.1 to their DNS record」這邊看到的,看起來是某種 misconfiguration 造成 microsoft.comA record 除了給正常的 IPv4 address 外,還給出了 192.168.1.1192.168.1.0 的 IPv4 address。

不過裡面比較有趣的是 id=38704301 這個,提到他反而查不到,看 log 發現被 dnsmasq 認定是 DNS rebinding 的攻擊而擋下來不回應任何 IP address:

I was getting an empty answer for microsoft.com. Turns out my dnsmasq is blocking it:

  $ dig microsoft.com. | grep EDE
  ; EDE: 15 (Blocked)

  resolver.log:Dec 20 00:43:57 router dnsmasq[8172]: possible DNS-rebind attack detected: microsoft.com

翻了 dnsmasq 的 manpage,可以看到這個功能:

--stop-dns-rebind

Reject (and log) addresses from upstream nameservers which are in the private ranges. This blocks an attack where a browser behind a firewall is used to probe machines on the local network. For IPv6, the private range covers the IPv4-mapped addresses in private space plus all link-local (LL) and site-local (ULA) addresses.

id=38704159 這邊也有類似的情況,不過這邊是提到 OpenWrt

microsoft.com is currently IPv6-only on my network, because OpenWrt's DNS rebinding protection filters out the A records:

  $ ping -4 microsoft.com
  ping: microsoft.com: Address family for hostname not supported

  $ ping -6 microsoft.com
  PING microsoft.com(2603:1030:c02:8::14 (2603:1030:c02:8::14)) 56 data bytes
  64 bytes from 2603:1030:c02:8::14 (2603:1030:c02:8::14): icmp_seq=1 ttl=112 time=68.4 ms