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

Amazon CloudFront 支援 EDNS-Client-Subnet

Amazon CloudFront 今天的新聞:「Improved CloudFront Performance with EDNS-Client-Subnet Support」。

目前 CDN 大多都還是靠 GeoDNS 技術達到分流技術,但另外一方面,Google 的 Public DNSOpenDNS 服務不一定在每個 ISP 都有設機房,這使得 CDN 服務無法靠 DNS server 的 IP address 正確導到離使用者 ISP 最近的 CDN (也就是原文指的 sub-optimal performance)。

EDNS-Client-Subnet 是一個 draft,讓 DNS resolver 可以把 client 的網段資訊帶給 CDN 的 DNS server,進而改善定位。

剛剛測試發現 Akamai 也支援了,在「OpenDNS: Why doesn't Akamai support the edns client subnet extension? This would allow OpenDNS and Google DNS to more effectively provide the geo location of the CDN and allow Akamai to send content to clients at higher speed.」這篇也有提到。

以前會鼓勵使用自己家的 DNS resolver 的理由又要消失一個了 :p

NTIA 決定將 Root Domain 的管理權責轉移到 ICANN

NTIA (National Telecommunications and Information Administration) 決定將 root domain 管理權責移交出來:「NTIA Announces Intent to Transition Key Internet Domain Name Functions」,關於移交的 Q&A 則可以在「IANA Functions and Related Root Zone Management Transition Questions and Answers」這篇讀到。

目前是 NTIA 放出意願,請 ICANN 提出轉移計畫:

As the first step, NTIA is asking the Internet Corporation for Assigned Names and Numbers (ICANN) to convene global stakeholders to develop a proposal to transition the current role played by NTIA in the coordination of the Internet’s domain name system (DNS).

不知道要花多久時間,可能是用幾年的時間轉移。雖然是找 stakeholders,但看起來應該是會由 ICANN 掌握...

Domain Sharding 的調整...

Domain Sharding 是針對以往瀏覽器常見的「加速技巧」(workaround),目的是突破瀏覽器對單一 domain 的最大連線速限制。像是 IE{6,7} 在 HTTP/1.1 上的限制是 2。

Steve Souders 在 2008 年整理的「Roundup on Parallel Connections」就有列出當時各瀏覽器的限制。而在 BrowserscopeNetwork 可以看到更多新的數字。

而隨著環境一直在改變,桌機限制的連線數也逐漸調高,以及 SPDY 的發展,再加上行動平台的比重愈來愈高,本來的 Domain Sharding 技巧需要重新審視。

Etsy 的「Reducing Domain Sharding」這篇文章中提到他們決定減少 Domain Sharding 的數量 (由四個變成兩個),而改善了反應時間:

  • 在圖片較多的頁面上約減少 50ms~80ms,在一般頁面則是減少 30ms~50ms。
  • 在行動平台上減少 500ms。

這兩個改善使得每次造訪的點閱率多了 0.27 page。

尤其是行動平台上對 Domain Sharding 的敏感程度,讓現在設計網站的人要考慮的更多了...

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

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

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

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

Amazon CloudFront 與 Route53 正式公告增加台灣機房...

如同前幾天提到的正式公告了:「New Edge Locations Added in Taipei and Rio de Janeiro for Amazon CloudFront and Amazon Route 53」。

價錢跟預期的一樣,與亞洲區其他點相同。

不過實際上測試,Route53 好像沒看到會導到台灣機房?

Zerigo DNS 換到 Akamai,然後漲價...

Zerigo 年底發了兩篇公告:

Zerigo 是好用在 GeoDNS 的服務上 (不用自己寫程式 & 更新 GeoDNS database,更不用自己做 HA 機制),一般的 DNS 服務到是還好... 漲了也只能接受啊,就當作換上 Akamai 後的成本調漲好了?(看了看,檯面上 GeoDNS 沒幾家好用的服務啊...)

繼續觀察看看吧...

AWS 進入北京!

早上的時候就有看到消息了,而剛剛在 AWS 老大 Werner VogelsTwitter 上看到他宣佈 AWS 北京區的成立:

官方公告在「Coming Soon - New China (Beijing) Region」這邊。中國大陸的官方網站在「亚马逊 AWS | Cloud Computing in China on Amazon Web Services (Simplified Chinese)」這邊。

一如往常的,有中國政府規範的但書:

This Region will allow China-based and multinational companies to make use of a broad collection of AWS services while remaining in compliance with China's legal and regulatory requirements.

要注意的是,目前列出來的服務並沒有 CloudFrontRoute53,只有看到這樣的說明:

We have been working with a number of local data center, bandwidth, and content delivery partners to bring this Region to life. Companies such as China Net Center and SINNET will provide the infrastructure, network services, and CDN services that are required to support the launch and operation of AWS technology services in China.

繼續觀望看看接下來如何...