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 架構有不少幫助。

自適應演算法與 A/B Testing

Hacker News Daily 上看到三年前的舊文章,講自適應演算法取代常見的 A/B testing:「20 lines of code that will beat A/B testing every time」。

就拿原文裡面的例子來說明,我想要測試 "Buy Now!" 這個按鈕的顏色來得知哪個顏色的 click rate 最高,而我有 Orange、Green 以及 White 三種顏色為候選。

一開始我初始值都設為「展示了 1 次,被點擊了 1 次」,所以每個點擊率都是 100%:

OrangeGreenWhite
1/1 = 100%1/1=100%1/1=100%

然後你的網站上只要展示「點擊率最高的那個顏色」,並且記錄下來展示次數與點擊率就好,而整個過程會是自適應而被自動被淘汰掉,最後可能會變成這樣,就會固定是綠色的了:

OrangeGreenWhite
114/4071 = 2.8%205/6385=3.2%59/2264=2.6%

而這樣做的好處是節省人力成本:你不需要 A/B Testing 完後再人工介入修改。

對於更複雜的例子,雖然原文沒有提到,但你可以直接展開來做,舉例來說,你假設顏色與地區兩個變數所帶出來的 click rate 不是 i.i.d.,那麼你可以針對每個 Color + Region 都存數值去比較。

當然還是有他的問題 (comment 有提到),不過可以架出一些全自動的 workaround 來解決,比起要兩階段人工介入省了不少人力。

另外可以想像在大的產品上會遇到效能問題 (因為對同樣資料大量的 read + write),但這個數字不需要太即時,只要量大就會準確,所以技術上也可以解決...

關於 CSS 中 :visited 的隱私問題

在七年半前 (2008 年八月) 寫的「利用 CSS 產生的隱私問題」文章,最近好像是因為 Rplus ChenFacebook 上的這邊提到而又有不少點擊進來,不過這個問題在 2010 年左右已經被解決了。

可以參考 MDN 上「:visited - CSS」的說明,以及當時 Mozilla 所發佈的文章:「privacy-related changes coming to CSS :visited」。

由於隱私問題,Mozilla 的作法是限制 :visited 可以改變的項目,只剩下少數與呈現方式有關的屬性可以用:

For privacy reasons, browsers strictly limit the styles you can apply using an element selected by this pseudo-class: only color, background-color, border-color, border-bottom-color, border-left-color, border-right-color, border-top-color, outline-color, column-rule-color, fill and stroke.

另外各種想要取得 :visited 的 CSS 資訊的方法,也會以沒有瀏覽過該網站重新計算,並且傳回假資料以確保還是不會洩漏:

The first change is that Gecko will lie to web applications under certain circumstances. In particular, getComputedStyle() and similar functions such as element.querySelector() always return values indicating that a user has never visited any of the links on a page.

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 也有同樣問題。