未來 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 資料,你可以限制只有誰可以發你的憑證,直接用白名單做控管。

Ruby 上使用 DynamoDB 的函式庫:aws-record

AWS 正式發表了在 Ruby 上使用 DynamoDB 的 library:「Announcing General Availability of aws-record」。

GitHub 連結在「aws/aws-sdk-ruby-record」,而 Ruby Gems 的連結在「aws-record」。

這樣用起來更簡單了...

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

GitHub 的網站功能上 CDN 了...

GitHub Pages 上 CDN 了:「Faster, More Awesome GitHub Pages」。

不過 Apex domain (也就是 domain 本身的 hostname) 無法設定 CNAME record,必須透過 A record,就沒辦法用到 CDN 的地區特性了...

CDN 用的是 Fastly,也丟進 SmokePing 監測好了...

請僅快確認這次 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)」。