PChome 修正了問題,以及 RFC 4074 的說明

早些時候測試發現 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 連線會慢的原因...

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 會跑 AAAAA 以及 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 就倒在路邊了...

Dropbox 的桌面端應用支援 IPv6 環境了...

算是宣示性質的新聞稿吧,畢竟官網與 blog 以及 API 都還是沒 AAAA record:「Adding IPv6 connectivity support to the Dropbox desktop client」。

文章裡面提到支援 IPv6 only network,應該是指 ISP 有支援 NAT64 轉換的情況下可以使用 Dropbox 資源,而不是 Dropbox 整個 IPv6 ready...

gslin@home [~] [17:49/W4] dig www.dropbox.com aaaa @8.8.8.8

; <<>> DiG 9.9.5-3ubuntu0.14-Ubuntu <<>> www.dropbox.com aaaa @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63706
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.dropbox.com.               IN      AAAA

;; ANSWER SECTION:
www.dropbox.com.        55      IN      CNAME   www.dropbox-dns.com.

;; AUTHORITY SECTION:
dropbox-dns.com.        1794    IN      SOA     dns1.p06.nsone.net. hostmaster.nsone.net. 1493415466 43200 7200 1209600 60

;; Query time: 18 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Apr 29 17:49:10 CST 2017
;; MSG SIZE  rcvd: 139

未來 CA 將會強制要求檢查 DNS CAA record

CA/Browser 通過提案,要求以後 CA 單位都要檢查 DNS CAA record 才能發放憑證 (RFC 6844 的「DNS Certification Authority Authorization (CAA) Resource Record」):「Ballot 187 - Make CAA Checking Mandatory」。

Certificate Authority Authorization (CAA) is a DNS Resource Record defined in RFC 6844 – https://datatracker.ietf.org/doc/rfc6844/ , published in January 2013. It allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain and, by implication, that no other CAs are authorized.

透過 DNS CAA 資料,你可以限制只有誰可以發你的憑證,直接用白名單做控管。

最佳化 nginx 的 TLS Time to First Byte (TTTFB)

在「Optimizing NGINX TLS Time To First Byte (TTTFB)」這篇文章裡在討論要如何讓 nginx 的 TLS Time to First Byte (TTTFB) 盡可能短。

可以看到文章裡面用到兩個方法,一個是修改 nginx 的程式碼縮小 TLS record size。我對是覺得頗危險,尤其是作者的改法不知道有什麼 side-effect... (要注意 nginx 裡面直接拿 NGX_SSL_BUFSIZEBIO_set_write_buffer_size 使用,這代表有可能還有其他的地方也是這樣搞?)

第二個方法是開啟 TLS False Start,目前主流的瀏覽器都陸陸續續支援了。

這是文章作者的測試:

可以看到時間減少的相當多。

現在是期望作者這篇文章的測試可以讓 patch 合併回 mainstream 後再用,這樣有比較多人 audit...

ptt.cc 偶而會解不出 IP 的問題

Update:感謝正妹 wens 幫忙,現在已經先上 workaround 了,狀況暫時解除...

最近發現 168.95.1.1 有時會找不到 ptt.cc 這個 domain (參考 gist:9995821),原因是 ptt.cc 在 whois 上登記的是:

Name Server: NS0.PTT.CC
Name Server: NS1.PTT.CC
Name Server: NSOUT1.PTT.CC

用 dig 對 cc 的 NS server 查詢也可以確認:

;; AUTHORITY SECTION:
ptt.cc.                 172800  IN      NS      ns0.ptt.cc.
ptt.cc.                 172800  IN      NS      ns1.ptt.cc.
ptt.cc.                 172800  IN      NS      nsout1.ptt.cc.

;; ADDITIONAL SECTION:
ns1.ptt.cc.             172800  IN      A       140.112.172.10
ns0.ptt.cc.             172800  IN      A       140.112.172.16
nsout1.ptt.cc.          172800  IN      A       112.121.80.227

但 ptt.cc 的三台 NS server 上都找不到 nsout1.ptt.cc:

; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @140.112.172.10

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600
; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @140.112.172.16

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600
; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @112.121.80.227

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600

於是就錯亂了...

可以先解決的方法是先把 nsout1.ptt.cc 加上去,然後再規劃要怎麼修改兩邊的 record (Ptt 這側的 A/NS record,與 cc 的 A/NS record)。

補充一下,ptt2.cc 也有同樣問題。

請僅快確認這次 RoR 所提供的安全性公告

下午遇到布丁大長輩的時候他還很開心說「我用 2.3 沒問題的啊~」XDDD

今天 Ruby on Rails 官方對 Active Record 發出安全性通報以及更新 (類別為 SQL Injection):「[ANN] Rails 3.2.10, 3.1.9, and 3.0.18 have been released!」。

請不要只看標題,這次的安全性問題包括所有版本,而非 3.x 而已。這次的安全性問題太過歡樂,所以除了在支援的版本以外 (3.1 與 3.2),這次的安全性問題還是提供了 2.3 與 3.0 的 patch 讓人下載,並提供當無法使用 patch 時的 workaround:「SQL Injection Vulnerability in Ruby on Rails (CVE-2012-5664)」。