Mozilla 維護的 Public Suffix List

在「域名小知识:Public Suffix List」這邊看到由 Mozilla 維護的 Public Suffix List,記錄了哪些 suffix 屬於 top-level:

  • Avoid privacy-damaging "supercookies" being set for high-level domain name suffixes
  • Highlight the most important part of a domain name in the user interface
  • Accurately sort history entries by site

所以 supercookie 阻擋機制是從這邊來的...

用 Amazon API Gateway 重導網域

在「Creating An Amazon API Gateway With aws-cli For Domain Redirect」這邊看到用 Amazon API Gateway 重導整個網域的方法。一般的做法是用 Amazon S3 (用 web hosting 重導) + Amazon CloudFront (for HTTPS) 堆出來,事實上這個方法成本也比較低,這篇文章只是示範怎麼用而已:

I’m not saying the API Gateway method is better than using S3 plus CloudFront for simple hostname redirection. In fact, it costs more (though still cheap), takes more commands to set up, and isn’t quite as flexible in what URL paths get redirected from the source domain. It does, however, work and may be useful as an API Gateway aws-cli example.

可以從中間學到一些東西,尤其是可以看到如何使用 aws-cli 操作 Amazon API Gateway 的部分...

Let's Encrypt 的 Limited Beta

Let's Encrypt 在拿到 IdenTrust 提供的 cross sign (參考「Let's Encrypt 正式出發」) 後所啟動的計畫:「Beta Program Announcements」。

要先透過 Google Forms 填單等待,等通過後要指定 production server 才會發出來。

要注意的是,Let's Encrypt 發出來的 SSL certificate 會比較短,只有 90 天有效,設計上是依靠自動機制在更新,所以理論上不會有問題:

Certificates from Let's Encrypt are valid for 90 days. We recommend renewing them every 60 days to provide a nice margin of error. As a beta participant, you should be prepared to manually renew your certificates at that time. As we get closer to General Availability, we hope to have automatic renewal tested and working on more platforms, but for now, please play it safe and keep track.

再來是有註冊限制,分成 Registrations/IP address 與 Certificates/Domain 兩個限制:

There are two rate limits in play: Registrations/IP address, and Certificates/Domain.

前者的限制是每天 10 次:

Registrations/IP address limits the number of registrations you can make in a given day; currently 10. This means you should avoid deleting the /etc/letsencrypt/accounts folder, or you may not be able to re-register.

後者的限制是每個 domain 只給 4 個 certificate:

Certificates/Domain you could run into through repeated re-issuance. This limit measures certificates issued for a given combination of Top Level Domain + Domain. This means if you issue certificates for the following domains, at the end you would have what we consider 4 certificates for the domain example.com.

拿來測試應該是夠用。

取得某些 tld 所有的 Domain Name

在「How to Download a List of All Registered Domain Names」這邊介紹了 .com、.net 以及 .name 的 zone file 怎麼申請與下載 (由 Verisign 維護的三個 tld)。

另外也介紹了 Centralized Zone Data Service,包括所有的 tld,以及 ICANN 提供的 API。

這樣應該有很多資料可以分析?

.onion 的域名保護

.onion 被用在 Torhidden service,而現在從不同的面向要保護這個 root domain 不被註冊,在 IETF 的 blog 上看到「.onion」這篇文章就是其中一個方向。

這邊的計畫是把 .onion 域名當作像是 .local.localhost.example 這樣的特殊域名保護 (參考 RFC 6761「Special-Use Domain Names」) 而提了一個新的 RFC (目前是 draft):「The .onion Special-Use Domain Name」。

如果通過的話,就有一個標準可以遵循,不然現在對 .onion 一直都是 De-facto standard...

HTTP/1.1 時代的 Best Practice 變成 HTTP/2 的問題

Velocity 2015 上的「HTTP/2 is here, let's optimize!」提到了很多關於 HTTP/1.1 時代所採用的 Best Practice (或者說,workaround) 變成了 HTTP/2 的問題。

這張表整理了各種技巧在 HTTP/1.1 與 HTTP/2 的差異:

在 HTTP/2 因為有了 multiplexing 機制,用了 Apply domain sharding 後反而增加 DNS query 以及開新的連線所需要的 handshake 時間。

而 Concatenate resources 也算是 workaround 的一種,不同等級的合併會有不同的 trade-off。全站合併 assets 可以讓常逛的使用者下載的量降到最低,但會讓第一次讀取的使用者花比較多時間下載。如果是單頁合併 assets,則剛好反過來:第一次讀取的使用者較快,但常逛的使用者會下載重複的內容。

最後的 Inline resources,作者則是提出利用 HTTP/2 提供的 server push 機制來改善,不過沒看懂...

有些 workaround 總算可以拋開了...

.SUCKS 的 Domain...

easyDNS 這篇「Why We Will Not Be Registering easyDNS.SUCKS」把議題拋出來了。

.SUCKS 的 domain 申請的目的就是要發橫財,而這也從 Sunrise Claim 的價錢看出來:USD$2499。而當初抗議成立時也沒被接受,現在看起來不像會有進一步的進展。

除非如同 comment 所提到的被 Google 抵制,不過實在不像...

Route 53 的大改版

Amazon Route 53 的大改版:「Route 53 Update - Domain Name Registration, Geo Routing, and a Price Reduction」。

首先是可以註冊 domain,除了 web console 外,還可以透過 API 註冊:「Actions on Domain Registrations」。

看起來 privacy protection 的部份是跟 Gandi 合作:

Turns privacy protection on or off for the domain, determining whether WHOIS queries return contact information specified in the registrar record. If privacy protection is enabled, the query returns contact information for our registrar partner, Gandi, instead of the contact information that is specified in the registrar record.

沒看到可以註冊的 tld 的 API,但是網站 web console 連進去可以看到其實相當多... (不過目前沒看到 .tw)

另外一個大功能是 Geo Routing,可以選擇洲別,或是地區別。不過「美國本土」(海外的部份有另外分區) 與「中國」這兩個網路大國都各只有一區,而不是把再依照各州或各省細分... (有不少 CDN 所提供的 DNS 服務是把美國依照各州列出設定...)

但至少補上了這一塊,這樣可以用 Route53 配合 multi-CDN 的機制,而不需要自己刻了...

然後最後是 query 的價錢降價 20%:

Last, but certainly not least, I am happy to tell you that we have reduced the prices for Standard and LBR (Location-Based Routing) queries by 20%.

是該看看要不要撤掉 Zerigo,因為目前這塊最大的成本其實是報帳以及帳號控管,而非單純租用成本 :o

EFF 的 Privacy Badger

EFF 推出新的延伸套件 (有 Firefox 與 Google Chrome 版),透過演算法阻擋嘗試追蹤你的單位:「Privacy Badger」。

在官網上有比較技術面的說明:

At a more technical level, Privacy Badger keeps note of the "third party" domains that embed images, scripts and advertising in the pages you visit. If a third party server appears to be tracking you without permission, by using uniquely identifying cookies to collect a record of the pages you visit across multiple sites, Privacy Badger will automatically disallow content from that third party tracker. In some cases a third-party domain provides some important aspect of a page's functionality, such as embedded maps, images, or fonts. In those cases Privacy Badger will allow connections to the third party but will screen out its tracking cookies.

技術上的作法是分析 third party domain 的行為,用演算法阻擋可能的追蹤。與 Ghostery 這類工具使用人力建立清單的方法不太一樣。

裝起來跑看看,感覺還蠻有趣的...

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