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 的密钥管理，也存在类似的挑战。今年早些时候，我们推出了 Keyless SSL ，以帮助提高 TLS 的密钥安全性。我们正在考虑扩展 Keyless SSL，为 DNSSEC 实时签名提供远程密钥服务器的优势。

运行权威 DNS 服务器的运营商经常担心服务器会被用作恶意分布式拒绝服务 (DDoS) 攻击的渠道。这是因为 DNS 使用 UDP 这种无状态协议。

在 TCP 中，每个连接都以三方握手开始。这可以确保在开始连接之前，双方的 IP 地址是已知和正确的。在 UDP 中没有这样的握手：信息只是直接发送到一个 IP 地址，且其“来源” IP 地址未经验证。 如果攻击者能够制作一个 UDP 数据包发给服务器，说 “嗨，来自 IP X ”，服务器一般会通过发送 UDP 数据包给 X 来回应。将 X 设为受害者的 IP 地址而不是发送者的 IP 地址，这被称为 UDP “欺骗”。通过欺骗受害者，攻击者可以使响应 UDP 请求的服务器用 "反射 "流量淹没受害者。这同样适用于权威服务器和开放递归解析器。

DNSSEC 也通过 UDP 工作，对 DNS 查询的回答可能非常长，包含多个 DNSKEY 和 RRSIG 记录。这是一个对攻击者有吸引力的目标，因为它允许他们 “放大”其反射攻击。如果向名称服务器发送少量的欺骗性 UDP DNSSEC 请求，受害者将收到大量的反射流量。有时这足以使受害者的服务器不堪重负，并导致拒绝服务。

从根服务器查询一个不存在的顶级域名，返回的响应约为 100 字节，同一查询的签名应答约为 650 字节，即放大系数为 6.5。根服务器使用 1024 比特的 RSA 密钥进行签名，并使用 NSEC 处理否定应答。在使用以 1024 位密钥签名的 NSEC3 的顶级域名服务器查询一个不存在的域名，将产生约 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 的危险是可以预防的。