Tag: record

SSH 的 SSHFP record

很久前看過 SSHFP record，當時支援度不高就忘記了... 剛剛在 Cloudflare 的這篇「Additional Record Types Available with Cloudflare DNS」看到發現 OpenSSH 很久前就有支援了...

用法是 VerifyHostKeyDNS 這個 option，像是 ssh -o "VerifyHostKeyDNS=yes" -o "StrictHostKeyChecking=yes" hostname 這樣的指令，對於 ~/.ssh/known_hosts 裡沒有的機器，在第一次連線的時候會去查 DNS record，如果沒有查到的話就會中斷。

產生 SSHFP record 的方式則是可以參考「How do I generate SSHFP records?」這篇，也就是直接用 sshkey-gen -r [hostname]，程式就會去讀 /etc/ssh/ 下的資料產生了。

ORM 常見的效能問題

在「How not to structure your database-backed web applications: a study of performance bugs in the wild」這邊看到的，裡面提到的論文是以 Rails 的 ActiveRecord 分析，不過概念上還算通用...

重點在最後一張 (Table 7 那張)：

看一下在腦裡留個印象，之後遇到的時候至少大概知道怎麼查...

台固的網域名稱轉出到 Gandi，以及 GDPR...

看到 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 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

以往在 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 A records, 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？

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

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

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_BUFSIZE 給 BIO_set_write_buffer_size 使用，這代表有可能還有其他的地方也是這樣搞？)

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

這是文章作者的測試：

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

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