Google Chrome 將 .dev 設為 HSTS Preload 名單

其實是兩件事情... 第一件是 Google Chrome.dev 結尾的網域設為 HSTS Preload 名單:「Chrome to force .dev domains to HTTPS via preloaded HSTS」。

第二件事情是隨著第一件來的,HSTS Preload 必須由 domain 擁有人提出啊... 所以 .dev 是合法的 TLD (gTLD)?

文章作者給了答案,是的,而且就是 Google 擁有的:

Wait, there's a legit .dev gTLD?
Yes, unfortunately.

(翻白眼)

這對開發者來說有種無奈感...

不過你可以用這招避開:「在 Google Chrome 連上因 HSTS 而無法連線的網站」,也就是輸入 badidea

另外測試了一下,應該是所有的 A record 都會指到 127.0.53.53,如果有人懶得設定的話也可以用這個位置啦...

Cloudflare 的 F-Root

Cloudflare 從三月底開始跟 ISC 簽約合作,服務 F-Root 這個 DNS Service (f.root-servers.net):「Delivering Dot」。

Since March 30, 2017, Cloudflare has been providing DNS Anycast service as additional F-Root instances under contract with ISC (the F-Root operator).

Linode 東京的機器上面可以看出來 www.cloudflare.com 走的路徑跟 f.root-server.net 相同:

gslin@one [~] [22:49] mtr -4 --report www.cloudflare.com
Start: Tue Sep 12 22:49:29 2017
HOST: one.abpe.org                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 139.162.65.2               0.0%    10    0.6   0.6   0.5   0.6   0.0
  2.|-- 139.162.64.5               0.0%    10    2.0   1.1   0.6   2.5   0.5
  3.|-- 139.162.64.8               0.0%    10    0.7   1.0   0.7   2.1   0.3
  4.|-- 218.100.6.62               0.0%    10    0.8   0.8   0.8   1.0   0.0
  5.|-- 198.41.215.162             0.0%    10    0.7   0.7   0.7   0.8   0.0
gslin@one [~] [22:49] mtr -4 --report f.root-servers.net
Start: Tue Sep 12 22:49:46 2017
HOST: one.abpe.org                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 139.162.65.3               0.0%    10    0.5   0.6   0.5   0.6   0.0
  2.|-- 139.162.64.7               0.0%    10    0.7   0.7   0.6   0.8   0.0
  3.|-- 139.162.64.8               0.0%    10    0.7   0.7   0.6   0.8   0.0
  4.|-- 218.100.6.62               0.0%    10    0.8   0.8   0.8   0.8   0.0
  5.|-- f.root-servers.net         0.0%    10    0.8   0.8   0.7   0.8   0.0

而且也可以從監控發現,f.root-servers.net 的效能變好:

Using RIPE atlas probe measurements, we can see an immediate performance benefit to the F-Root server, from 8.24 median RTT to 4.24 median RTT.

DNS query 的量也大幅增加:

而且之後也會隨著 Cloudflare 的 PoP 增加而愈來愈快... 在原文的 comment 也提到了 Cloudflare 也有打算跟其他的 Root Server 合作,所以看起來會讓整個 infrastructure 愈來愈快而且穩定。

另外這也代表台灣在本島也會直接連到 F-Root 了,不過 HiNet 自己也有 F-Root,所以 HiNet 的部份就沒什麼差...

Route 53 的 Query 記錄

Amazon Route 53 可以收 query log 了,會丟到 CloudWatch Logs:「Amazon Route 53 Announces Support For DNS Query Logging」。

If you are using Amazon Route 53 as your public, authoritative DNS, you will now have the capability to easily log DNS queries received by Amazon Route 53 through integration with CloudWatch Logs.

這樣可以拿來分析了...

Amazon Route 53 對地區的微調功能

Amazon Route 53 推出新功能,針對地區微調資源的比重:「Amazon Route 53 Traffic Flow Announces Support For Geoproximity Routing With Traffic Biasing」。

範例大致上說明了這個功能的能力,假設你在兩個點都有服務可以提供,你可以利用這個功能微調某個比率到某個點:

For example, suppose you have EC2 instances in the AWS US East (Ohio) region and in the US West (Oregon) region. When a user in Los Angeles browses to your website, geoproximity routing will route the DNS query to the EC2 instances in the US West (Oregon) region because it's closer geographically. If you want a larger portion of users in the middle of the United States to be routed to one region, you can specify a positive bias for that region, a negative bias for the other region, or both.

有點 CDN 的想法在裡面...

Amazon Route 53 支援 CAA record 了

Amazon Route 53 宣佈支援 CAA record 了:「Announcement: Announcement: Amazon Route 53 now supports CAA records」、「Amazon Route 53 now supports CAA records」。

這是一個被動性的 workaround,要求 CA 本身要支援 DNS CAA,所以他沒辦法防止 CA 本身作惡誤簽,但因為負作用與技術債的可能性不高,在 CA/Browser Forum 上被通過強制要求支援了。(參考「未來 CA 將會強制要求檢查 DNS CAA record」)

Gandi 的 DNS 服務也支援了 (要透過 export mode,參考「How can I add a CAA record?」),不過 Linode 還沒做...

Amazon Route 53 將會加緊支援 DNS CAA

看到 Amazon Route 53 要支援 DNS CAA 的消息:「Announcement: Announcement: CAA Record Support Coming Soon」。

裡面有提到 CA/Browser Forum 的決議,要求各瀏覽器支援 DNS CAA:

On March 8, 2017, the Certification Authority and Browser Forum (CA/Browser Forum) mandated that by September 8, 2017, CA’s are expected to check for the presence of a CAA DNS record and, if present, refuse issuance of certificates unless they find themselves on the whitelist <https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/>.

DNS CAA 可以設定哪些 SSL certificate 可以發出你的證書,除了自己以外,也可以讓第三者比較容易確認是否有誤發的行為:

We have seen a lot of interest in Amazon Route 53 support for Certification Authority Authorization (CAA) records, which let you control which certificate authorities (CA) can issue certificates for your domain name.

直接接管整個 .io 的網域...

在「The .io Error – Taking Control of All .io Domains With a Targeted Registration」這邊看到的 XDDD

其實就是這樣:

;; AUTHORITY SECTION:
io.         172800  IN  NS  ns-a1.io.
io.         172800  IN  NS  ns-a2.io.
io.         172800  IN  NS  ns-a3.io.
io.         172800  IN  NS  ns-a4.io.
io.         172800  IN  NS  a0.nic.io.
io.         172800  IN  NS  b0.nic.io.
io.         172800  IN  NS  c0.nic.io.

然後他就去註冊 ns-a{1,2,3,4}.io 了 XDDD

這很歡樂 XDDD

(應該可以來掃一下所有的 tld...)

除了 DNS 的 TTL 外,還有瀏覽器本身的 cache time...

在看「Reviewing Fastly’s New Approach To Load Balancing In The Cloud」這篇的時候被提醒:

However, most browsers have implemented their own caching layer that can override the TTL specified by the server. In fact, some browsers cache for 5-10 minutes, which is an eternity when a region or data center fails and you need to route end users to a different location.

我印象中沒那麼長,但也記不起來多長,所以查了一下...

結果 IE 在「How Internet Explorer uses the cache for DNS host entries」直接說三十分鐘 XDDD 這篇文章是 2011 年更新的,所以至少到 IE9 都是對的?

Internet Explorer 4.x and later versions modify how DNS host entries are cached by decreasing the default time-out value to 30 minutes.

Firefox 的值可以從 Mozilla networking preferences 這邊對 network.dnsCacheExpiration 的說明看到是 60 秒。

Google Chrome 沒找到官方的說明...

不過這可以知道當你要換 IP address 時,如果可以讓新舊 IP 都提供服務的話,至少規劃半個小時會比較保險。如果有其他理由而沒辦法同時提供服務的話,至少公告步驟裡要有「重開瀏覽器」這塊。

而作業系統自己的 cache 又是另外要計算進去的事了...

GitHub 也自己搞了一套管理多家 DNS 的程式...

StackOverflow 團隊發表完自己開發管理 DNS 的程式後 (參考「StackOverflow 對於多 DNS 商的同步方式...」),GitHub 也來參一腳:「Enabling DNS split authority with OctoDNS」。

可以看到 GitHub 用了兩家的系統 (AWSRoute 53Dyn 的服務):

;; AUTHORITY SECTION:
github.com.             172800  IN      NS      ns1.p16.dynect.net.
github.com.             172800  IN      NS      ns3.p16.dynect.net.
github.com.             172800  IN      NS      ns2.p16.dynect.net.
github.com.             172800  IN      NS      ns4.p16.dynect.net.
github.com.             172800  IN      NS      ns-520.awsdns-01.net.
github.com.             172800  IN      NS      ns-421.awsdns-52.com.
github.com.             172800  IN      NS      ns-1707.awsdns-21.co.uk.
github.com.             172800  IN      NS      ns-1283.awsdns-32.org.

GitHub 的 OctoDNS 用 YAML 管理:

octodns:
  type: A
  values:
    - 1.2.3.4
    - 1.2.3.5
zones:
  github.com.:
    sources:
      - config
    targets:
      - dyn
      - route53

有種當初 Dyn 被打趴後大家硬是想個解法的產物... @_@

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