過年前因為工作關係第一次注意到 CAA record (Certification Authority Authorization) 這個東西，簡單說明就是透過 DNS record 來設定你的 SSL cert 的簽發單位白名單，一開始的規範是 RFC6844，其實原理也不複雜，不過我就在遇到用 AWS ACM 簽發憑證時說檢查不過的狀況，有趣的是該 domain 沒有設定任何 CAA，搜尋研究一陣子後發現可能是因為該 domain 是 CNAME 去到別的第三方 domain 才會這樣，然後果然發現這個問題其實很久了。
不過其實原始版本的 RFC6844 其實沒有要求檢查 CNAME 目標的 CAA，而是在 2017 年的勘誤 5065 中才加入的，不過這個修改造成很多問題，所以 letsencrypt 在同一年就又換回舊的實做了。CAA record 看起來也因此放棄這個修改了，在用來取代 RFC6844 的 RFC8659 中，就完全沒有提到 CNAME 的檢查，甚至在與舊版相異的附錄也是特別提到這點差異，不過 RFC8659 還很新，是 2019 年 11 月的，看起來 AWS 還沒修正也情有可原(?)。
最近因為花了很多時間研究 Safari 和第三方 Cookie，常常看到一個專有名詞 eTLD+1，之前只知道和 domain name 及 TLD 相關，不清楚確切的定義，所以又去查了一下，結果找到解釋最清楚的竟然是 Go 的 publicsuffix 套件的說明文件，總之簡單比較不明確的解釋，eTLD 指的是 effective TLD，像是net、net.tw這類，域名註冊商可以提供的網址後綴，依此類推，eTLD+1 就是 eTLD 再多一段，也就是一般人可以註冊到的網域名稱，像是我這邊用的othree.net，至於部落格的子網域blog.othree.net就不是 eTLD+1 了。
其中的 eTLD 又稱為 Public Suffix，然後 Mozilla 有維護一份 Public Suffix List，給瀏覽器用的，主要用途就是避免寫入太高權限的 cookie，例如我要是把 cookie 寫到.net層的話，所有的.net域名的網站都會讀的到它，就會有安全性問題，這份清單現在已經是主要瀏覽器開發商都有在使用了，它的內容除了那些 eTLD 之外，其實還有私人公司提交的，像是 blogspot 列了一大串，還有 github 有列github.io和githubusercontent.com，github.io是 GitHub Pages 的預設 domain，像我的 Github Page 就會用 othree.github.io，GitHub 提交這筆記錄，在現代瀏覽器就會限制我在othree.github.io不能寫 cookie 到github.io，這樣可以確保所有使用者的頁面不會互相影響。
我還順便亂瀏覽一下內容，發現 Amazon 手上好多的 gTLD，像是book、song，然後他們的cloudfront.net也有提交，還有一堆其它的 aws 網域名稱；另外就是 DynDNS 和 no-ip 兩個類似服務都提交超多的；然後還發現一間叫 nymnom.com 的域名註冊商，專門提供一堆nom或nym結尾的域名，搞不清楚這兩個單字的意思啊。