幹壞事是進步最大的原動力
看到「Encrypted Server Name Indication for TLS 1.3」這個，由 Fastly、Cloudflare、Apple 的人聯手推出的 draft，想要保護 TLS 連線一開始明文傳輸的 hostname 部分。看起來是透過 DNS 發佈 public key，然後使用者用這把 public key 保護 hostname 的部分...
而 DNS 的部分可以透過 DNS over TLS 或是 DNS over HTTPS 來保護，這樣讓 ISP 沒有任何資訊可以看到 hostname，把暴露的資訊再降低...
來繼續關注這個技術...
Google 宣佈了 .app 的網域將開放註冊：「Introducing .app, a more secure home for apps on the web」。
整個 .app 網域都已經被 Google 設定 HSTS Preload 了：
A key benefit of the .app domain is that security is built in—for you and your users. The big difference is that HTTPS is required to connect to all .app websites, helping protect against ad malware and tracking injection by ISPs, in addition to safeguarding against spying on open WiFi networks. Because .app will be the first TLD with enforced security made available for general registration, it’s helping move the web to an HTTPS-everywhere future in a big way.
如果要註冊下來，開發的時候得注意...
看到 othree 的「TFN 域名轉出」這篇，剛好前陣子把 git.tw 也轉到 Gandi 上，也遇到一樣的問題... 以往的經驗是網域註冊商會提供 authorization code，但台固的系統是讓你自己輸入，懂這點後就好處理了：
所以結論是，TFN 域名轉出時要輸入的移轉中密碼其實就是給使用者自訂 authorization code，而且還有個蠻短的長度限制 XD
另外是因為 GDPR 所以看不到 whois 資料了，像是 othree 提到的 markdown.tw：
gslin@GSLIN-HOME [~] [14:32/W2] whois markdown.tw
Domain Name: markdown.tw
Domain Status: clientTransferProhibited
Registrant:
Not displayed due to GDPR
FR
Administrative Contact:
Not displayed due to GDPR
Technical Contact:
Not displayed due to GDPR
Record expires on 2020-03-07 (YYYY-MM-DD)
Record created on 2011-03-07 (YYYY-MM-DD)
Domain servers in listed order:
ns-171-a.gandi.net
ns-114-b.gandi.net
ns-144-c.gandi.net
Registration Service Provider: GANDI SAS
我自己的 git.tw 也是：
gslin@GSLIN-HOME [~] [14:34/W2] whois git.tw
Domain Name: git.tw
Domain Status: clientTransferProhibited
Registrant:
Not displayed due to GDPR
FR
Administrative Contact:
Not displayed due to GDPR
Technical Contact:
Not displayed due to GDPR
Record expires on 2019-05-23 (YYYY-MM-DD)
Record created on 2008-05-23 (YYYY-MM-DD)
Domain servers in listed order:
kristin.ns.cloudflare.com
paul.ns.cloudflare.com
Registration Service Provider: GANDI SAS
這樣就有點麻煩了，以後如果要聯絡的話只剩下 DNS 內的 SOA record？
以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域，現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了：「Custom domains on GitHub Pages gain support for HTTPS」：
We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.
不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準，也稱為 ANAME，有些 DNS provider 有支援，主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。
如果是使用 A record，則是需要更新 IP 位置：
If you are using
Arecords, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.
另外也提供 HTTP 轉 HTTPS 的選項：
以前 HTTPS 還得自己弄伺服器處理，現在可以直接往 GitHub 上丟了...
另外用查出來的 IP 看了一下架構，IP 是 Fastly 的，所以應該是跟 Fastly 合作，但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證，或是 Fastly 提供 Port 80/443 的 TCP Proxy？
Twitter 上看到 WebKit 對 HSTS 所產生的 Super Cookie 提出的改善方案：
How WebKit crumbles the "Super Cookie". https://t.co/iwOpjM8p9f
— WebKit (@webkit) March 16, 2018
拿原文的例子來說明，先指定一個隨機數給 user，像是 8396804 (二進位是 100000000010000000000100)，所以就存取下面的網址：
https://bit02.example.com https://bit13.example.com https://bit23.example.com
在存取這些 HTTPS 網址時都會指定 HSTS，所以之後連到這三個網址的 HTTP request 就不會觸發到 HTTP 版本，會因為 HSTS 被轉到 HTTPS 版本。於是就可以用 32 個 HTTP request 測試 32bits 而判斷出身份。(當然你可以用更多)
WebKit 提出的改善方案大概有幾種，主要是就觀察到的現象來限制。
第一種解法「Mitigation 1: Limit HSTS State to the Hostname, or the Top Level Domain + 1」是因為會看到這樣的設計：
https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.a.example.com https://a.a.a.a.a.a.a.example.com …etc...
https://bit00.example.com https://bit01.example.com https://bit02.example.com ...etc... https://bit64.example.com
所以提出的方案是只有目前網站的 domain 以及 top domain + 1 (像是 example.com) 可以被設定 HSTS：
Telemetry showed that attackers would set HSTS across a wide range of sub-domains at once. Because using HSTS in this way does not benefit legitimate use cases, but does facilitate tracking, we revised our network stack to only permit HSTS state to be set for the loaded hostname (e.g., “https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com”), or the Top Level Domain + 1 (TLD+1) (e.g., “https://example.com”).
但其實廣告主只需要註冊 32 domains (或是 64) 就可以避開這個問題。
第二種是「Mitigation 2: Ignore HSTS State for Subresource Requests to Blocked Domains」，如果在 HTTPS 頁面上，某個 domain 的 cookie 已經因為某些原因被阻擋 (像是手動設定)，那麼就忽略掉 HSTS 的設計：
We modified WebKit so that when an insecure third-party subresource load from a domain for which we block cookies (such as an invisible tracking pixel) had been upgraded to an authenticated connection because of dynamic HSTS, we ignore the HSTS upgrade request and just use the original URL. This causes HSTS super cookies to become a bit string consisting only of zeroes.
後面這點在現在因為 SEO 設計而使得各大網站都往 HTTPS 方向走，應該會有些幫助吧...
在「Ballot 218 - Remove validation methods 1 and 5 - CAB Forum」看到「Ballot 218: Remove validation methods #1 and #5」這則議案以 78% 的同意票通過，限縮 SSL Certificate 的認證方式。眼睛瞄到中華電信投下反對票：
14 Yes votes: CFCA, Cisco, Comodo CA, D-TRUST, DigiCert, GDCA, GlobalSign, GoDaddy, Izenpe, Let’s Encrypt, Logius PKIoverheid, SSL.com, TrustCor, Trustwave
4 No votes: Buypass, Chunghwa Telecom, Entrust Datacard, SwissSign
4 Abstain: Actalis, Disig, HARICA, OATI
78% of voting CAs voted in favor
找了一下在 BR (Baseline Requirements) 的 3.2.2.4.1 與 3.2.2.4.5，其中前者是透過註冊商認證：
3.2.2.4.1 Validating the Applicant as a Domain Contact
Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar.
後者是透過文件認證：
3.2.2.4.5 Domain Authorization Document
Confirming the Applicant's control over the FQDN by relying upon the attestation to the authority of the Applicant to request a Certificate contained in a Domain Authorization Document.
在想投下反對的原因，會不會是因為中華自己的 domain 應該都是透過後者方式發的？透過內部公文系統...
Amazon Route 53 的新功能，可以解決以前自己要建立 Service Discovery 服務的工作：「Amazon Route 53 Releases Auto Naming API for Service Name Management and Discovery」。官方的文件在「Using Autonaming for Service Discovery」這邊。
不過目前有些限制，一個 namespace (domain name) 目前只能有五個服務：
DNS settings for up to five records.
然後 DNS 回應時，最多回八個 record：
When Amazon Route 53 receives a DNS query for the name of an instance, such as backend.example.com, it responds with up to eight IP addresses (for A or AAAA records) or up to eight SRV record values.
回應八個 record，但應該是可以註冊超過八個吧... (i.e. 每次都回不一樣)
自建服務 (像是 Cassandra 或是 ScyllaDB) 可以直接用這個服務掛上去，就不用自己架 Consul 了。
目前支援了這四區，亞洲不在這波提供範圍：
Amazon Route 53 Auto Naming is available in US East (N. Virginia), US East (Ohio), US West (Oregon), and EU (Ireland) regions.
早些時候測試發現 PChome 已經修正了之前提到的問題：「PChome 24h 連線會慢的原因...」、「PChome 24h 連線會慢的原因... (續篇)」，這邊除了整理一下以外，也要修正之前文章裡的錯誤。
在 RFC 4074 (Common Misbehavior Against DNS Queries for IPv6 Addresses) 裡面提到了當你只有 IPv4 address 時，DNS server 要怎麼回應的問題。
在「3. Expected Behavior」說明了正確的作法，當只有 A RR 沒有 AAAA RR 的時候，應該要傳回 NOERROR，而 answer section 裡面不要放東西：
Suppose that an authoritative server has an A RR but has no AAAA RR for a host name. Then, the server should return a response to a query for an AAAA RR of the name with the response code (RCODE) being 0 (indicating no error) and with an empty answer section (see Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that there is at least one RR of a different type than AAAA for the queried name, and the stub resolver can then look for A RRs.
在「4.2. Return "Name Error"」裡提到，如果傳回 NXDOMAIN (3)，表示查詢的這個名稱完全沒有 RR，而不僅僅限於 AAAA record，這就是我犯的錯誤 (在前面的文章建議傳回 NXDOMAIN)：
This type of server returns a response with RCODE 3 ("Name Error") to a query for an AAAA RR, indicating that it does not have any RRs of any type for the queried name.
With this response, the stub resolver may immediately give up and never fall back. Even if the resolver retries with a query for an A RR, the negative response for the name has been cached in the caching server, and the caching server will simply return the negative response. As a result, the stub resolver considers this to be a fatal error in name resolution.
Several examples of this behavior are known to the authors. As of this writing, all have been fixed.
PChome 這次的修正回應了正確的值 (而不是我提到的 NXDOMAIN)：
$ dig shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw ; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<<<- opcode: QUERY, status: NOERROR, id: 40767 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;shopping.gs1.pchome.com.tw. IN AAAA ;; AUTHORITY SECTION: gs1.pchome.com.tw. 5 IN SOA ns1.gs1.pchome.com.tw. root.dns.pchome.com.tw. 20171123 3600 3 3600 5 ;; Query time: 16 msec ;; SERVER: 210.242.216.91#53(210.242.216.91) ;; WHEN: Fri Nov 24 01:44:52 CST 2017 ;; MSG SIZE rcvd: 134
另外 RFC 也有一些其他的文件可以參考，像是 RFC 2308 (Negative Caching of DNS Queries (DNS NCACHE))、RFC 4697 (Observed DNS Resolution Misbehavior) 以及 RFC 8020 (NXDOMAIN: There Really Is Nothing Underneath)，這些文件描述了蠻多常見的問題以及正確的處理方法，讀完對於現在愈來愈複雜的 DNS 架構有不少幫助。
在「PChome 24h 連線會慢的原因...」這篇的 comment 有讀者提到了 Happy Eyeballs 應該可以解決這個問題：
除了可以在維基百科上面看到外，比較正式的說明可以參考 RFC 6555：「Happy Eyeballs: Success with Dual-Stack Hosts」，其中在「6. Example Algorithm」就有提到 Google Chrome 與 Mozilla Firefox 怎麼實做 Happy Eyeballs：
What follows is the algorithm implemented in Google Chrome and Mozilla Firefox.
- Call getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy.
- Initiate a connection attempt with the first address in that list (e.g., IPv6).
- If that connection does not complete within a short period of time (Firefox and Chrome use 300 ms), initiate a connection attempt with the first address belonging to the other address family (e.g., IPv4).
- The first connection that is established is used. The other connection is discarded.
If an algorithm were to cache connection success/failure, the caching would occur after step 4 determined which connection was successful.
Other example algorithms include [Perreault] and [Andrews].
可以看到 Happy Eyeballs 的演算法是要避免 IPv6 network 不通的情況卡住很慢 (如果在 300ms 內連線沒有建起來，就會儘快往另外一個 address family 嘗試)，而不是在 DNS 層避免問題 (也就是 getaddinfo() 觸發的 DNS query)。
這次的情況是 DNS query 很慢，就會導致還是一開始就很慢，Happy Eyeballs 沒辦法解決這個問題。
不過話說回來，我是有印象知道有這個演算法，但不知道有「Happy Eyeballs」這個這麼逗趣的名字... (掩面)
Update：續篇請參考「PChome 24h 連線會慢的原因... (續篇)」。
tl;dr：因為他們的 DNS servers 不會對 IPv6 的 AAAA record 正確的回應 NXDOMAIN，導致 DNS resolver 會不斷嘗試。
好像一行就把原因講完了啊，還是多寫一些細節好了。
起因於我的電腦連 PChome 24h 時常常會卡住，Google Chrome 會寫「Resolving host...」，於是就花了些時間找這個問題。
一開始先用幾個工具測試，發現 host 會卡，但不知道卡什麼：
$ host 24h.pchome.com.tw
拿 tcpdump 出來聽的時候發現 host 會跑 A、AAAA 以及 MX 三個種類，而後面兩個都會卡住：
24h.pchome.com.tw is an alias for shopping.gs1.pchome.com.tw. shopping.gs1.pchome.com.tw has address 210.242.43.53 ;; connection timed out; no servers could be reached ;; connection timed out; no servers could be reached
這樣就有方向了... 我的電腦是 Dual-stack network (同時有 IPv4 address 與 IPv6 address)，所以可以預期 Google Chrome 會去查 IPv6 address。而國內很多網站都還沒有把有 IPv6 的情境當標準測試，很容易中獎...
有了方向後，用 dig 測試 IPv6 的 AAAA，發現都是給 SERVFAIL，而且多跑幾次就發現會卡住：
$ dig 24h.pchome.com.tw aaaa @168.95.192.1
然後對 {cheetah,dns,dns2,dns3,wolf}.pchome.com.tw (上層登記的) 與 dns4.pchome.com.tw (實際多的) 測，可以拿到 CNAME record，像是這樣：
$ dig 24h.pchome.com.tw aaaa @dns.pchome.com.tw ; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> 24h.pchome.com.tw aaaa @dns.pchome.com.tw ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26037 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;24h.pchome.com.tw. IN AAAA ;; ANSWER SECTION: 24h.pchome.com.tw. 300 IN CNAME shopping.gs1.pchome.com.tw. ;; AUTHORITY SECTION: gs1.pchome.com.tw. 300 IN NS ns3.gs1.pchome.com.tw. gs1.pchome.com.tw. 300 IN NS ns1.gs1.pchome.com.tw. gs1.pchome.com.tw. 300 IN NS ns4.gs1.pchome.com.tw. gs1.pchome.com.tw. 300 IN NS ns5.gs1.pchome.com.tw. gs1.pchome.com.tw. 300 IN NS ns2.gs1.pchome.com.tw. ;; ADDITIONAL SECTION: ns1.gs1.pchome.com.tw. 300 IN A 210.242.216.91 ns2.gs1.pchome.com.tw. 300 IN A 210.242.216.92 ns3.gs1.pchome.com.tw. 300 IN A 210.242.43.93 ns4.gs1.pchome.com.tw. 300 IN A 203.69.38.91 ns5.gs1.pchome.com.tw. 300 IN A 210.71.147.91 ;; Query time: 12 msec ;; SERVER: 210.59.230.85#53(210.59.230.85) ;; WHEN: Wed Nov 22 11:05:24 CST 2017 ;; MSG SIZE rcvd: 243
但往 ns{1,2,3,4,5}.gs1.pchome.com.tw 問的時候給不出答案，也不給 NXDOMAIN，像是這樣：
$ dig shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw ; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> shopping.gs1.pchome.com.tw aaaa @ns1.gs1.pchome.com.tw ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36249 ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 6 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;shopping.gs1.pchome.com.tw. IN AAAA ;; AUTHORITY SECTION: gs1.pchome.com.tw. 3600 IN NS ns3.gs1.pchome.com.tw. gs1.pchome.com.tw. 3600 IN NS ns4.gs1.pchome.com.tw. gs1.pchome.com.tw. 3600 IN NS ns5.gs1.pchome.com.tw. gs1.pchome.com.tw. 3600 IN NS ns1.gs1.pchome.com.tw. gs1.pchome.com.tw. 3600 IN NS ns2.gs1.pchome.com.tw. ;; ADDITIONAL SECTION: ns3.gs1.pchome.com.tw. 3600 IN A 210.242.43.93 ns4.gs1.pchome.com.tw. 3600 IN A 203.69.38.91 ns5.gs1.pchome.com.tw. 3600 IN A 210.71.147.91 ns1.gs1.pchome.com.tw. 3600 IN A 210.242.216.91 ns2.gs1.pchome.com.tw. 3600 IN A 210.242.216.92 ;; Query time: 11 msec ;; SERVER: 210.242.216.91#53(210.242.216.91) ;; WHEN: Wed Nov 22 11:07:17 CST 2017 ;; MSG SIZE rcvd: 310
於是 DNS resolver 就倒在路邊了...