Home » Computer » Network » Archive by category "DNS" (Page 2)

Google 的 .search 網域

Netcraft 的「November 2017 Web Server Survey」這篇看到關於 Google 弄到的 .search 網域:

This month the controversial new .search gTLD being run by Google’s Charleston Road Registry subsidiary was found for the first time, with www.nic.search responding to the survey. Google hopes it will be able to run .search as a dotless domain which will automatically redirect users to their search engine of choice. This proposal has been criticised for going against ICANN’s own rules, which prohibits this functionality due to the potential for conflicts with existing names on internal networks. This feature could also cause confusion for users who have come to expect that typing words into their address bar will perform a search query for that term.

It is currently uncertain whether or not Google will be allowed to run the .search TLD as a dotless domain, however with the launch of the first site on this TLD this month Google is one step closer to the provision of this service.

找了一下資料,ICANNWiki 上的「.search」有些資料,另外也有新聞資訊 (2013 年的):「Google Wants To Operate .Search As A “Dotless” Domain, Plans To Open .Cloud, .Blog And .App To Others」。


AWS 提供 Hybrid Cloud 環境下 DNS 管理的說明

不知道為什麼出現在 browser tab 上,不知道是哪邊看到的... AWS 放出了一份文件,在講 hybrid cloud 環境下當你同時有一般 IDC 機房,而且使用內部 domain 在管理時,網路與 AWS 打通後要怎麼解決 DNS resolver 的問題:「Hybrid Cloud DNS Solutions for Amazon VPC」。

有些東西在官方的說明文件內都寫過,但是是 AWS 的特殊設計,這邊就會重複說明 XDDD

像是這份文件裡提到 Amazon DNS Server 一定會在 VPC 的 base 位置加二 (舉例來說, 的 VPC,Amazon DNS Server 會在

Amazon DNS Server
The Amazon DNS Server in a VPC provides full public DNS resolution, with additional resolution for internal records for the VPC and customer-defined Route 53 private DNS records.4 The AmazonProvidedDNS maps to a DNS server running on a reserved IP address at the base of the VPC network range, plus two. For example, the DNS Server on a network is located at For VPCs with multiple CIDR blocks, the DNS server IP address is located in the primary CIDR block.

在官方文件裡,則是在「DHCP Options Sets」這邊提到一樣的事情:

When you create a VPC, we automatically create a set of DHCP options and associate them with the VPC. This set includes two options: domain-name-servers=AmazonProvidedDNS, and domain-name=domain-name-for-your-region. AmazonProvidedDNS is an Amazon DNS server, and this option enables DNS for instances that need to communicate over the VPC's Internet gateway. The string AmazonProvidedDNS maps to a DNS server running on a reserved IP address at the base of the VPC IPv4 network range, plus two. For example, the DNS Server on a network is located at For VPCs with multiple IPv4 CIDR blocks, the DNS server IP address is located in the primary CIDR block.

另外也還是有些東西在官方的說明文件內沒看過,像是講到 Elastic Network Interface (ENI) 對 Amazon DNS Server 是有封包數量限制的;這點我沒在官方文件上找到,明顯在量太大的時候會中獎,然後開 Support Ticket 才會發現的啊 XDDD:

Each network interface in an Amazon VPC has a hard limit of 1024 packets that it can send to the Amazon Provided DNS server every second.

Anyway... 這份文件裡面提供三種解法:

  • Secondary DNS in a VPC,直接用程式抄一份到 Amazon Route 53 上,這樣 Amazon DNS Server 就可以直接看到了,這也是 AWS 在一般情況下比較推薦的作法。
  • Highly Distributed Forwarders,每台 instance 都跑 Unbound,然後針對不同的 domain 導開,這樣可以有效避開單一 ENI 對 Amazon DNS Server 的封包數量限制,但缺點是這樣的設計通常會需要像是 Puppet 或是 Chef 之類的軟體管理工具才會比較好設定。
  • Zonal Forwarders Using Supersede,就是在上面架設一組 Unbound 伺服器集中管理,透過 DHCP 設定讓 instance 用。但就要注意量不能太大,不然 ENI 對 Amazon DNS Server 的限制可能會爆掉 XD


新的 DNS Resolver:

看到新的 DNS Resolver 服務,也拿到了還不錯的 IP address,「New “Quad9” DNS service blocks malicious domains for everyone」,服務網站是「Quad 9 | Internet Security and Privacy in a Few Easy Steps」,主打宣稱過濾已知的危險站台...

由政府單位、IBM 以及 Packet Clearing House 成立的:

The Global Cyber Alliance (GCA)—an organization founded by law enforcement and research organizations to help reduce cyber-crime—has partnered with IBM and Packet Clearing House to launch a free public Domain Name Service system.

也就是說,後面三家都不是專門做網路服務的廠商... 於是就會發現連 Client Subnet in DNS Queries (RFC 7871) 都沒提供,於是查出來的地區都不對,這對使用 DNS resolver 位置分配 CDN 節點的服務很傷啊... (或是其他類似服務)

這是 GooglePublic DNS ( 查出來的:

i.kfs.io.               576     IN      CNAME   kwc.kkcube.com.country.mp.kkcube.com.
kwc.kkcube.com.country.mp.kkcube.com. 21599 IN CNAME TW.kwc.kkcube.com.
TW.kwc.kkcube.com.      188     IN      CNAME   i.kfs.io.cdn.cloudflare.net.
i.kfs.io.cdn.cloudflare.net. 299 IN     A
i.kfs.io.cdn.cloudflare.net. 299 IN     A

;; Query time: 28 msec
;; WHEN: Sat Nov 18 05:30:23 CST 2017
;; MSG SIZE  rcvd: 181

這是 Quad9 ( 查出來的:

i.kfs.io.               1800    IN      CNAME   kwc.kkcube.com.country.mp.kkcube.com.
kwc.kkcube.com.country.mp.kkcube.com. 42702 IN CNAME US.kwc.kkcube.com.
US.kwc.kkcube.com.      300     IN      CNAME   i.kfs.io.cdn.cloudflare.net.
i.kfs.io.cdn.cloudflare.net. 300 IN     A
i.kfs.io.cdn.cloudflare.net. 300 IN     A

;; Query time: 294 msec
;; WHEN: Sat Nov 18 05:30:27 CST 2017
;; MSG SIZE  rcvd: 181

再來一點是,在科技領域相信政府單位通常都是一件錯誤的事情,我 pass... XD


原文是講滲透測試的前置作業,需要將某個特定 domain 下的主機名稱掃出來:「A penetration tester’s guide to sub-domain enumeration」。

最直接的還是 DNS zone transfer (AXFR),如果管理者沒設好 DNS server 的話,這會是最快的方式。當沒有這個方法時就要用各種其他方式來掃了。


應該有人可以提到所有的東西再寫成程式 XD

Stream 對 .io 的感冒

Stream 的人寫了一篇「Why Stream Stopped Using .IO Domain Names for Production Traffic」表達他們對 .io 的感冒...

主要是因為 9/20 爛掉的情況不太妙。第一個是 .io 爛掉了兩個小時 (以月來算 SLA 就等於直接掉了 0.2% uptime,變成不到 99.8%),第二個是爛掉時 server 傳回的不是 SERVFAIL,而是 NXDOMAIN

The outage lasted for almost 2 hours, during which 1/5th of DNS queries for any .getstream.io record would fail.

他們的解法是改到 .com 上,畢竟影響的時候應該會修得比較快。另外文章裡也有延伸提到 Amazon Route 53 爛掉時要怎麼辦,如果他們真的決定要解決的話,應該是會拿出像「StackOverflow 對於多 DNS 商的同步方式...」或是「GitHub 也自己搞了一套管理多家 DNS 的程式...」的搞法吧。

不過這的確是當初選 .io 沒預料到的...

下一代的 Tor Hidden Service

Tor 公佈了下一代的 Hidden Service (Onion Service):「Tor's Fall Harvest: the Next Generation of Onion Services」。

三年前 Facebook 自己暴力算出 facebookcorewwwi.onion 這個很特別的名字 (參考「Facebook 證明 Tor 的 Hidden Service 不安全」),這陣子連紐約時報也能暴力算出 nytimes3xbfgragh.onion 這個好名字 (參考「紐約時報網站上 Tor 的 Hidden Service (i.e. Tor Onion Service)」,這讓只有 16 chars 的 hostname 的 hashed-space 不夠大的問題愈來愈明顯 (只有 80 bits 的空間)。

如果你也想要找出一個有趣的 hostname 的話,可以用 lachesis/scallion 這樣的工具,這程式用 CPU 產生出 RSA key 後,再用 GPU 算 SHA-1

The inital RSA key generation is done the CPU. An ivybridge i7 can generate 51 keys per second using a single core. Each key can provide 1 gigahash worth of exponents to mine and a decent CPU can keep up with several GPUs as it is currently implemented.

也因為如此,Facebook 與紐約時報在上線時並不是直接在 Hidden Service 上裸奔,而是上了 HTTPS 作為 workaround,以避免資料外洩。

但這畢竟是 workaround,Tor 的人還是希望協定本身就可以提供一個夠安全的架構,而花了四年多發展出下一代的 Hidden Service,也就是這次提到的成果了。

最大的改變就是 hostname 變長很多了,從本來的 16 chars 變成 56 chars:

And finally from the casuals user's PoV, the only thing that changes is that new onions are bigger, tastier and they now look like this: 7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion.

hostname 變長主要是因為把整個 256 bits public key 放進去,可以從 spec 看到:

6. Encoding onion addresses [ONIONADDRESS]

   The onion address of a hidden service includes its identity public key, a
   version field and a basic checksum. All this information is then base32
   encoded as shown below:

     onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion"
     CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2]

       - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service.
       - VERSION is an one byte version field (default value '\x03')
       - ".onion checksum" is a constant string
       - CHECKSUM is truncated to two bytes before inserting it in onion_address

  Here are a few example addresses:


   For more information about this encoding, please see our discussion thread

這是因為在 ECC 的安全性被廣泛認可後,ECC 的優點就被拿出來用在這次設計上了:

  • 256 bits 的 ECC key 強度大約是 3072 bits RSA key (以現在最好的攻擊演算法來估算)。
  • 直接放 public key 不需要經過 hash function 計算,可以避免掉 hash function 被找到 collision 時的風險。

於是因為 hostname 放的下,就硬塞進去了 XDDD

不過如果要玩的人需要裝 alpha 版本,目前的 stable 版本還沒有這個功能:

Tor as of version supports the next-gen onion services protocol for clients and services! As part of this release, ​the core of proposal 224 has been implemented and is available for experimentation and testing by our users.

用 Vagrant 的技巧

在「Ten Things I Wish I’d Known Before Using Vagrant」這邊作者整理了使用 Vagrant 的十個技巧,有些以前就知道,有些是每次遇到都要查一次,有些則是新發現的工具...


A Vagrant plugin that provides a simple DNS server for Vagrant guests

Landrush is a simple cross-platform DNS for Vagrant VMs that is visible on both, the guest and the host.

It spins up a small DNS server and redirects DNS traffic from your VMs to use it, automatically registering/unregistering IP addresses of guests as they come up and go down.


Vagrant.configure("2") do |config|
  config.vm.box = "hashicorp/precise64"

  config.landrush.enabled = true

  config.vm.hostname = "myhost.vagrant.test"

  config.landrush.host 'static1.example.com', ''
  config.landrush.host 'static2.example.com', ''

以前有遇到這樣的需求時都還傻傻的去寫 /etc/hosts... (也是會動啦,而且每一台都寫一樣的東西是還好,但有種很 workaround 的感覺 XD)


Let's Encrypt 的 Embed SCT 支援

翻到 Let's EncryptUpcoming Features 時看到:

Embed SCT receipts in certificates
ETA: February, 2018

對 Embed SCT 不熟,所以查了查這個功能。

這指的是在簽發 SSL certficiate 後,把資料丟給 Certificate Transparency (CT) 伺服器後,伺服器會提供 signed certificate timestamp (SCT);而這個資料放到 SSL certificate 內叫做 Embed SCT:(出自 CT 的 FAQ)

What is an SCT?
An SCT is a signed certificate timestamp. When a certificate authority or a server operator submits a certificate to a log, the log responds with an SCT. An SCT is essentially a promise that the log server will add the certificate to the log in a specific time. The time, known as the maximum merge delay (MMD), helps ensure that certificates are added to logs in a reasonable time. The SCT accompanies the certificate until the certificate is revoked. A TLS server must present the SCT to a TLS client (along with the SSL certificate) during the TLS handshake.

當使用 ECC 時會小於 100 bytes:

How big is an SCT?
SCTs are less than 100 bytes, assuming elliptic curve signatures are used.

這樣才能試著解釋前幾天提到要拔掉 HPKP 的事情:「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」,也就是為什麼他們是提 CT 解,而不是 DNS CAA 解...

不過我記得 CT server 可以自己架自己 submit 不是嗎?後來有另外規定一定要用第三方的嗎?這樣又很怪...

Chromium 內提案移除 HPKP (HTTP Public Key Pinning)

Twitter 上看到這則 tweet,提到要移除 HPKP (HTTP Public Key Pinning):

blink-dev 上的討論可以參考「Intent To Deprecate And Remove: Public Key Pinning」(就是上面那個連結,只是拉出來)。

這個提案大概可以推敲出理由... 目前的作法必須寫進瀏覽器內,這樣明顯會有 scale 問題,而且這個作法本身就很 workaround,只能保護所謂「高價值」的 domain,而且因為是綁在 Public Key 上,如果 CA 換了 Intermediate Certificate 就有可能會導致檢查過不了。

另外一方面,scale 而且合理的替代方案已經發展出來了。如果瀏覽器會檢查 DNS CAA 資訊 (這個規格可以在 DNS 裡設定有哪些 CA 可以簽這個 domain),就能解這個問題 (加上 DNSSEC 會更加確保驗證過程)。像是這樣:

example.com.    IN      CAA     0 issue "letsencrypt.org"
example.com.    IN      CAA     0 issuewild ";"

不過這個提案本身提到 CT (Certificate Transparency) 怪怪的,因為 CT 無法避免惡意的簽發 (發了以後故意不送 CT):

Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)

但在瀏覽器支援 DNS CAA 可以避免,結果在討論時都沒到 DNS CAA...

另外在 Hacker News 上也有討論:「Public Key Pinning Being Removed from Chrome (groups.google.com)」可以看一下,有個人有提到用 DNS CAA 的方法...

不過印象中這群人對 DNS-based 的方案都不太喜歡,所以也有可能是這樣不考慮在瀏覽器端實作 DNS CAA 吧...

Android 將測試 DNS over TLS

從「Android getting "DNS over TLS" to prevent ISPs from knowing what websites you visit」這邊看到的報導,原
文在「Android getting “DNS over TLS” support to stop ISPs from knowing what websites you visit」這邊可以看到。

It appears that “DNS over TLS” support is being added to Android, according to several commits added to the Android Open Source Project (AOSP). The addition in the Android repository shows that a new setting will be added under Developer Options allowing users to turn on or off DNS over TLS. Presumably, if such an option is being added to Developer Options, then that means it is in testing and may arrive in a future version of Android such as version 8.1.

這邊用的應該是 RFC 7858 的「Specification for DNS over Transport Layer Security (TLS)」,已經是 Standards Track 了。預設使用 TCP port 853:

By default, a DNS client desiring privacy from DNS over TLS from a particular server MUST establish a TCP connection to port 853 on the server, unless it has mutual agreement with its server to use a port other than port 853 for DNS over TLS.

而且建議如果另外定義的話,不要用 port 53:

This recommendation against use of port 53 for DNS over TLS is to avoid complication in selecting use or non-use of TLS and to reduce risk of downgrade attacks.

另外也說明了在 port 853 上禁用明文傳輸:

DNS clients and servers MUST NOT use port 853 to transport cleartext DNS messages.

另外一個還在發展的標準是 Cisco 的人推出的「DNS over Datagram Transport Layer Security (DTLS)」,走的是 UDP port 853,不過看起來因為 stateless 的特性,需要考慮比較多問題... (尤其這類服務常配合 anycast)

不過即使將 DNS query 保護起來,TLS 本身還是會透漏 hostname 的部份 (因為 SNI 的關係),所以就 privacy 面向考量的話,沒有實質的意義... 主要還是考慮被竄改的問題?但如果是這樣的話,目前 TLS 連線本身就已經有這樣的保護了?暫時沒想到可以解什麼實際的問題...