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ライブ署名のようなアクティブなプロセスで使用されている場合、秘密鍵のセキュリティに対する多くの脅威の1つに過ぎません。マシンがインターネットにさらされればさらされるほど、攻撃のベクトルは増えていきます。オフライン署名のマシンであれば、このような脅威にさらされる可能性がかなり低くなります。

鍵の安全性を確保する方法として、ハードウェアセキュリティモジュール（HSM）などのハードウェアベースのソリューションを使用する方法があります。この方法の主な欠点はコストであり、HSMは非常に高価（そして遅い）です。これは、利用者との距離を縮めるために地理的に分散しているDNSサーバーを運用する上で、最も厄介な点の一つです。すべてのサーバーロケーションにHSMを導入すると、コストがかかるだけでなく、法的な問題が発生する可能性があります。

鍵がリモート上に公開されることから保護するためのもう一つの解決策は、暗号化操作をシステムの信頼できるコンポーネントに引き渡すことです。そこで、暗号化を引き渡すことができるカスタムDNSサーバーが役立ちます。

DNSSECの鍵管理は、TLSの鍵管理と類似しており、同様の課題があります。今年初め、私たちはTLSの鍵の安全性を高めるために、キーレスSSLを導入しました。私たちはキーレスSSLを拡張して、DNSSECライブ署名用のリモートキーサーバーの利点を提供することを検討しています。

権威DNSサーバーを運用している事業者は、悪意のある分散サービス妨害（DDoS）攻撃の導線としてサーバーが利用されてしまうことに神経を尖らせることが多いようです。これは、DNSがステートレスプロトコルであるUDPを使用していることに起因しています。

TCPでは、それぞれの接続は3ウェイハンドシェイクから始まります。これにより、接続を開始する前にお互いのIPアドレスを認識し、正しいことを確認します。UDPでは、ハンドシェイクのような行為はありません。メッセージは、検証されないまま「送信元」のIPアドレスを持つIPに直接送信されます。攻撃者が「こんにちは、送信元IP：X」というUDPパケットをサーバーに送信すると、サーバーは通常「X」にUDPパケットを送信して応答することになります。「X」を送信者のIPアドレスではなく被害者のIPアドレスにすりことは、UDP「スプーフィング」（なりすまし）と呼ばれます。攻撃者は被害者になりすますことで、UDPリクエストに応答するサーバーを「リフレクト」されたトラフィックで過負荷状態に陥れることができます。これは、権威サーバーにも、オープンな再帰リゾルバーにも同様に適用されます。

DNSSECはUDPでも動作しますが、DNSクエリに対する応答は、複数のDNSKEYとRRSIGレコードを含む非常に長いものになる可能性があります。これはリフレクション攻撃を「増幅」させることができるため、攻撃者にとって魅力的なターゲットとなります。少量のスプーフィングされたUDP DNSSECリクエストがネームサーバーに送信されると、被害者は大量の反射トラフィックを受け取ることになります。場合によっては、これだけで被害者のサーバーを過負荷状態に陥れ、サービス拒否を引き起こすこともあります。

ルートサーバーに存在しないTLDを問い合わせた場合に返される応答は約100バイトですが、同じ問い合わせに対する署名付きの応答は約650バイト、増幅率にして6.5倍です。ルートは1,024ビットのRSA鍵で署名され、不存在の応答にはNSECが使用されます。TLDに存在しないドメインを1,024ビットの鍵で署名したNSEC3を使って要求した場合、増幅率は約10倍になります。さらに高い増幅率を得られるクエリもあり、最も効果的な「ANY」クエリがあります。

多くのサービスと同様に、DNSもTCP上で動作させることができます。TCPが必要であることを示すために、リゾルバに送り返すことができる「truncation」（切り捨て）フラグがあります。これにより、DNSリクエストの速度が遅くなるという代償を払いながら、DNSリフレクションの問題を解決することができます。しかし、16%のリゾルバがTCP切り捨てフラグを実装しておらず、4%がセカンドサーバを試行しないため、この解決策は現時点では実用的ではありません。

応答のサイズを小さくするもう一つの方法に、従来のRSA鍵の代わりに、 楕円曲線デジタル署名アルゴリズム （ECDSA） 鍵を使用するというものがあります。ECDSA鍵は同等の強度を持つRSA鍵よりもはるかに小さく 、より小さな署名を生成することで DNSSECの応答をはるかに小さくし、増幅率を低下させます。Google Public DNSは2014年末にECDSAのサポートを追加し、それ以来、他のいくつかの企業も 同様の措置をとっています。

TCPやECDSAのサポートは、一般的なDNSSECのサポートに比べるとまだ遅れており、代わりに従来の不正利用防止策で代用することができます。これには、 Resource Rate Limiting（RRL）、およびその他の経験則などがあります。

リフレクション攻撃から保護するために、Cloudflareはさまざまな角度からのアプローチに取り組んでいます。1つ目は、現在DNSサーバーで使用している攻撃識別に関する経験則と不正使用防止技術を利用すること、2つ目は、DNSSEC応答の増幅率を下げることです。最大増幅率を下げる方法としては、TCP上の「ANY」リクエストにのみ返信する、可能な限り小さいECDSA鍵を使用する、鍵のロールオーバーの頻度を減らす、などがあります。

Cloudflareは、ゾーンプライバシー、鍵管理、リフレクション／増幅のリスクに関して、DNSSECによってもたらされる複雑さを認識しています。適切な技術的判断と、運用管理を実施することで、DNSSECの危険性を防ぐことができます。