DNSSEC 的複雜性與注意事項

DNS is split into smaller pieces called zones. A zone typically starts at a domain name, and contains all records pertaining to the subdomains. Each zone is managed by a single manager. For example, cloudflare.com is a zone containing all DNS records for cloudflare.com and its subdomains (e.g. www.cloudflare.com, api.cloudflare.com).

There is no directory service for subdomains in DNS so if you want to know if api.cloudflare.com exists, you have to ask a DNS server and that DNS server will end up asking cloudflare.com whether api.cloudflare.com exists. This is not true with DNSSEC. In some cases, enabling DNSSEC may expose otherwise obscured zone content. Not everyone cares about the secrecy of subdomains, and zone content may already be easily guessable because most sites have a ‘www’ subdomain; however, subdomains are sometimes used as login portals or other services that the site owner wants to keep private. A site owner may not want to reveal that “secretbackdoor.example.com” exists in order to protect that site from attackers.

The reason DNSSEC can expose subdomains has to do with how zones are signed. Historically, DNSSEC is used to sign static zones. A static zone is a complete set of records for a given domain. The DNSSEC signature records are created using the Key Signing Key (KSK) and Zone Signing Key (ZSK) in a central location and sent to the authoritative server to be published. This set of records allows an authoritative server to answer any question it is asked, including questions about subdomains that don’t exist.

Unlike standard DNS, where the server returns an unsigned NXDOMAIN (Non-Existent Domain) response when a subdomain does not exist, DNSSEC guarantees that every answer is signed. This is done with a special record that serves as a proof of non-existence called the NextSECure (NSEC) record. An NSEC record can be used to say: “there are no subdomains between subdomains X and subdomain Y.” By filling the gap between every domain in the zone, NSEC provides a way to answer any query with a static record. The NSEC record also lists what Resource Record types exist at each name.

For statically signed zones, there are, by definition, a fixed number of records. Since each NSEC record points to the next, this results in a finite ‘ring’ of NSEC records that covers all the subdomains. Anyone can ‘walk’ a zone by following one NSEC record to the next until they know all subdomains. This method can be used to reveal all of the names in that zone---possibly exposing internal information.

Suppose there is a DNSSEC-enabled zone called example.com, with subdomains public.example.com and secret.example.com. Adding NSEC records will reveal the existence of all subdomains.

Asking for the NSEC record of example.com gives the following:

example.com. NSEC public.example.com. A NS SOA TXT AAAA RRSIG NSEC DNSKEY

Asking for public.example.com gives the following NSEC record:

public.example.com. NSEC secret.example.com. A TXT AAAA RRSIG NSEC

Asking for secret.example.com gives the following NSEC record:

secret.example.com. NSEC example.com. A TXT AAAA RRSIG NSEC

The first one is for the zone top/apex, and says that the name “example.com” exists and the next name is “public.example.com”. The public.example.com record says that the next name is “secret.example.com” revealing the existence of a private subdomain. The “secret.example.com” says the next record is “example.com” completing the chain of subdomains. Therefore, with a few queries anybody can know the complete set of records in the zone.

Technically, DNS records are not supposed to be secret, but in practice they are sometimes considered so. Subdomains have been used to keep things (such as a corporate login page) private for a while, and suddenly revealing the contents of the zone file may be unexpected and unappreciated.

Before DNSSEC the only way to discover the contents of names in a zone was to either query for them, or attempt to perform a transfer of the zone from one of the authoritative servers. Zone Transfers (AXFR) are frequently blocked. NSEC’s alternatative, NSEC3, was introduced to fight zone enumeration concerns, but even NSEC3 can be used to reveal the existence of subdomains.

Most domains under .ch use NSEC3

The NSEC3 record is like an NSEC record, but, rather than a signed gap of domain names for which there are no answers to the question, NSEC3 provides a signed gap of hashes of domain names. This was intended to prevent zone enumeration. Thus, the NSEC3 chain for a zone containing “example.com” and “www.example.com” could be (each NSEC3 record is on 3 lines for clarity):

231SPNAMH63428R68U7BV359PFPJI2FC.example.com. NSEC3 1 0 3 ABCDEF
NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM
A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM.example.com. NSEC3 1 0 3 ABCDEF
231SPNAMH63428R68U7BV359PFPJI2FC
A TXT AAAA RRSIG

Where

231SPNAMH63428R68U7BV359PFPJI2FC

example.com

NKDO8UKT2STOL6EJRD1EKVD1BQ2688DM

www.example.com

The first line of the NSEC3 record contains the “name” of the zone after it has been hashed, the number of hash rounds and salt used in the hashing are the two last parameters on the first line “3 ABCDEF”. The “1 0” stands for digest algorithm (1 means SHA-1) and if the zone uses Opt-out (0 means no). The second line is the “next hashed name in the zone”, the third line lists the types at the name. You can see the “next name” at the first NSEC3 record matches the name on the second NSEC3 record and the “next name” on that one completes the chain.

For NSEC enumeration, you can create the full list of domains by starting to guess at possible names in the domain. If the zone has around 100 domain names, it will take around 100 requests to enumerate the entire zone. With NSEC3, when you request a record that does not exist, a signed NSEC3 record is returned with the next zone present ordered alphabetically by hash. Checking if the next query name candidate fits in one of the known gaps allows anyone to discover the full chain in around 100 queries. There are many tools that can do this computation for you, including a plug-in to nmap

With the hashes that correspond to all the valid names in the zone, a dictionary attack can be used to figure out the real names. Short names are easily guessed, and by using a dictionary, longer names can be revealed as existing without having to flood the authoritative nameservers with guesses. Tools like HashCat make this easy to do in software, and the popularity of bitcoin has dramatically lowered the price of hashing-specific hardware. There is a burgeoning cottage industry of devices built to compute cryptographic hashes. The Tesla Password cracker (below) is just one example of these off-the shelf devices.

The Teslsa Cracker

Because hashing is cheap, zone privacy is only slightly improved when using NSEC3 as designed; the amount of protection a name gets is proportional to its unguessability.

In short, NSEC is like revealing plaintext passwords, and NSEC3 is like revealing a Unix-style passwords file. Neither technique is very secure. With NSEC3 a subdomain is only as private as it is hard to guess.

This vulnerability can be mitigated by a techniques introduced in RFCs 4470 and 4471 (https://tools.ietf.org/html/rfc4470 and https://tools.ietf.org/html/rfc4471) called “DNSSEC white lies”; this was implemented by Dan Kaminsky for demonstration purposes. When a request comes in for a domain that is not present, instead of providing an NSEC3 record of the next real domain, an NSEC3 record of the next hash alphabetically is presented. This does not break the NSEC3 guarantee that there are no domains whose hash fits lexicographically between the NSEC3 response and the question.

You can only implement NSEC3 or NSEC “white lies” if signatures can be computed in real-time in response to questions. Traditionally, static zone records for DNS resolution are created offline, and all the records with signatures stored in a zone file. This file is then read by a live DNS server allowing it to answer questions about the zone.

Cloudflare’s DNSSEC implementation leverages ECDSA’s efficient signature generation to sign DNSSEC records on-the-fly.

DNSSEC 旨在以各種模式運行，每種模式都提供不同的安全性、效能和便利性權衡。即時簽署解決了區域內容暴露問題，但交換條件是安全性較低的金鑰管理。

最常見的 DNSSEC 模式是靜態區域的離線簽署。這允許將私密金鑰保存在未連接到網路的機器上，藉此高度保護簽署系統免受外部威脅。當 DNS 資訊不經常變更時，此操作模型非常有效。

另一種常見的操作模式是集中式線上簽署。如果在存取受限、專用 DNS 簽署系統中簽署資料，則允許 DNS 資料變更並快速發布。某些營運者在其主要 DNS 伺服器上執行 DNS 簽署。就像離線簽署靜態區域一樣，此模式遵循中央簽署模型，即單個（或重複的）中央簽署者執行所有簽署，並且資料從其傳播到實際的權威 DNS 伺服器。

一種更激進的模式是允許實際的權威 DNS 伺服器在需要時動態簽署資料，這允許使用許多新功能，包括在產生答案的位置簽署的地理相關資訊。缺點是，現在金鑰產製原料位於許多可直接存取網際網路的不同機器上。在邊緣執行即時簽署會帶來金鑰分發等新問題，並對節點提出額外的計算要求。

最近，發現了一個名為 Heartbleed 的錯誤，該錯誤在伺服器應用程式中打開了一個主要的安全漏洞。錯誤原因在於 OpenSSL 中的編碼錯誤，其造成了遠端記憶體暴露漏洞。此錯誤允許遠端攻擊者從面向網際網路的伺服器中擷取加密金鑰。在 DNSSEC 即時簽署等活動過程中使用金鑰時，遠端記憶體暴露錯誤只是對私密金鑰安全的眾多威脅之一。機器暴露在網際網路上的次數越多，攻擊媒介就越多。離線簽署機器暴露於此類威脅的窗口要小得多。

確保金鑰安全的一種方法是使用硬體支援的解決方案，如硬體安全模組 (HSM)。這種方法的主要缺點是成本 – HSM 非常昂貴（而且速度很慢）。這是執行 DNS 伺服器時最棘手的問題之一，因為這些伺服器分布在各個地理位置上，以便接近其客戶。在每個伺服器位置執行 HSM 不僅成本高昂，而且還可能出現法律問題。

另一種防止遠端洩漏金鑰的解決方案是將加密作業卸載到系統的受信任元件中。這就是一個可以卸載加密之自訂 DNS 伺服器可以派上用場的地方。

DNSSEC 的金鑰管理類似於 TLS 的金鑰管理，且具有類似的挑戰。今年早些時候，我們推出了無密鑰 SSL ，以幫助提高 TLS 的金鑰安全性。我們正在考慮擴充無密鑰 SSL，以便為 DNSSEC 即時簽署提供遠端金鑰伺服器的優勢。

執行權威 DNS 伺服器的營運商經常擔心他們的伺服器將被用作惡意分散式阻斷服務 (DDoS) 攻擊的管道。這源於 DNS 使用 UDP（一種無狀態通訊協定）的事實。

在 TCP 中，每個連線均以三向握手開始。這可確保在開始連線之前，雙方的 IP 位址均為已知且正確無誤。在 UDP 中，沒有此類握手：訊息只是直接傳送至具有未經驗證的「來源」IP 位址的 IP。如果攻擊者可以製作一個 UDP 封包，向伺服器表示「嗨，來自 IP X」，則伺服器通常會透過向 X 傳送 UDP 封包來回應。選擇 X 作為受害者的 IP 位址而不是傳送者的 IP 位址被稱為 UDP「詐騙」。透過詐騙受害者，攻擊者可以使回應 UDP 要求的伺服器用「反射」的流量對受害者進行泛洪攻擊。這既適用於權威伺服器，也適用於開放式遞迴解析程式。

DNSSEC 也透過 UDP 運作，DNS 查詢的答案可能很長，包含多個 DNSKEY 和 RRSIG 記錄。對攻擊者來說，這是一個吸引力十足的目標，讓他們能夠「放大」反射攻擊。如果將少量詐騙性 UDP DNSSEC 要求傳送到名稱伺服器，則受害者將收到大量反射流量。有時，這足以使受害者的伺服器不堪重負，並導致拒絕服務。

從根伺服器要求不存在的 TLD 將返回大約 100 位元組的答案，同一問題的簽署答案約為 650 位元組或放大因數為 6.5。根使用 1,024 位元 RSA 金鑰進行簽署，並將 NSEC 用於否定答案。若要透過使用 1,024 位元金鑰簽署的 NSEC3 要求 TLD 中不存在的網域，則將產生大約 10 的放大因數。還有其他查詢可以產生更高的放大因數，最有效的是「ANY」查詢。

與許多服務一樣，DNS 也可以透過 TCP 運作。有一個「截斷」標誌可以傳送回解析程式，表示需要 TCP。這將解決 DNS 反射問題，但代價是 DNS 要求速度較慢。此解決方案目前不實用，因為 16% 的解析程式不遵守 TCP 截斷標誌，4% 的解析程式不嘗試第二台伺服器。

另一種減小回應規模的選項是使用橢圓曲線數位簽章演算法 (ECDSA) 金鑰，而不是傳統的 RSA 金鑰。ECDSA 金鑰比同等強度的 RSA 金鑰小得多，並且其產生的簽章更小 ，使 DNSSEC 回應規模更小，從而降低了放大因數。Google 公用 DNS 在 2014 年末增加了對 ECDSA 的支援，從那時起其他幾個 DNS 也開始 紛紛效仿。

對 TCP 和 ECDSA 的支援仍然落後於一般的 DNSSEC 支援，因此可以改用傳統的反濫用方法。這包括回應速率限制 (RRL) 及其他啟發式方法。

為了防止反射攻擊，Cloudflare 正在研究一種多管齊下的方法。首先，使用我們目前在 DNS 伺服器中所用的攻擊識別啟發式方法及反濫用技術，其次降低 DNSSEC 回應的放大因數。降低最大放大因數的方法包括：僅透過 TCP 回覆「ANY」要求，盡可能使用較小的 ECDSA 金鑰，以及降低金鑰變換的頻率。

Cloudflare 意識到 DNSSEC 在區域隱私權、金鑰管理及反射/放大風險方面具有複雜性。透過明智的工程決策及適當的操作控制，可以防止 DNSSEC 帶來的危險。