DNSSEC を実装する方法

问题

DNS 応答はデフォルトで認証されていないため、攻撃者が応答を偽装し、ユーザーを悪意のあるサーバーへ誘導できます(DNS キャッシュポイズニング)。DNS ゾーンを暗号的に署名し応答を検証するために、DNSSEC(RFC 4033-4035)を実装する必要があります。

前提条件

• DNS 解決とレコードタイプの理解
• 公開鍵暗号とデジタル署名への習熟
• DNS ゾーン管理に関する知識

ステップ

1. 1. Generate zone signing keys

   Generate two key pairs for each zone: a Zone Signing Key (ZSK) used to sign individual resource records, and a Key Signing Key (KSK) used to sign the DNSKEY RRset. Use ECDSA P-256 or RSA-2048+ for signatures. The ZSK is used frequently (rotate annually), the KSK rarely (rotate every few years). Create the DNSKEY records from both keys and add them to the zone. Use the RSA tool and hash tools to understand the signing process.

   入力

   zone: example.com | algorithm: ECDSAP256SHA256

   输出

   ZSK: {private, public} | KSK: {private, public} | DNSKEY records created

2. 2. Sign the zone and create RRSIG records

   For each resource record set (RRset) in the zone, create an RRSIG record containing the signature over the RRset data using the ZSK. Sign the DNSKEY RRset with the KSK. Create NSEC or NSEC3 records for authenticated denial of existence (proving a name does not exist). The signed zone now contains original records plus RRSIG, DNSKEY, and NSEC/NSEC3 records. Use the DNS encoder/decoder to inspect the wire format.

   入力

   A record: example.com. 3600 IN A 93.184.216.34

   输出

   RRSIG: example.com. 3600 IN RRSIG A 13 3 3600 20260101... (signature)

3. 3. Publish the DS record in the parent zone

   Compute the Delegation Signer (DS) record from the KSK's DNSKEY: DS = digest(KSK DNSKEY RDATA). Submit this DS record to your parent zone's operator (registrar for .com, or parent zone admin). The DS record creates the chain of trust from the root zone through TLD to your zone. The root zone and TLDs are already signed, creating a complete trust chain from the trust anchor. Use the hash tool to compute the DS digest.

   入力

   KSK DNSKEY: example.com. 3600 IN DNSKEY 257 3 13 <key>

   输出

   DS: example.com. 3600 IN DS 12345 13 2 <digest>

4. 4. Configure validation and monitor the chain

   Enable DNSSEC validation on your resolver. The resolver validates the chain from the trust anchor (root) through TLD DS to your zone DNSKEY, then verifies each RRSIG. Responses are marked AD (Authentic Data) when validated. Monitor for validation failures (SERVFAIL with bogus responses). Use dig +dnssec to test. Set up key rollover procedures: pre-publish new keys before switching, then retire old keys after the TTL expires. Use the DNS decoder to verify signed responses.

   入力

   dig +dnssec example.com A

   输出

   flags: qr rd ra ad | RRSIG validated | status: secure

期待される結果

ルートからの完全な信頼チェーンを備えた DNSSEC 署名済みゾーン。DNS レスポンスは暗号学的に認証され、スプーフィングを検出できます。

よくあるエラー

Forgetting to publish the DS record in the parent zone

Without the DS record in the parent, there is no chain of trust. Validators cannot authenticate your zone. Submit the DS to your registrar after signing.

Rolling keys without pre-publishing

Key rollover must follow RFC 6781 procedures. Pre-publish the new key before switching signatures, and wait for TTL to expire before removing the old key. Premature removal breaks validation.

Using NSEC instead of NSEC3

NSEC allows zone walking (enumerating all names). NSEC3 hashes the names, preventing enumeration. Use NSEC3 for zones where name privacy matters.

トラブルシューティング指引

• If validation fails with SERVFAIL, check the RRSIG timestamps (validity period), the DS record matches the KSK, and the chain of trust is unbroken.
• If the zone is large, signing can be slow. Use incremental signing (only re-sign changed records) and offline signing for better performance.
• For CDNSKEY/CDS automation, ensure your registrar supports RFC 8078 for automated DS record updates.

セキュリティ上の制限

• DNSSEC authenticates DNS data integrity and origin but does not encrypt DNS queries — use DNS-over-TLS or DNS-over-HTTPS for confidentiality.
• DNSSEC adds complexity and larger response sizes — ensure your infrastructure handles EDNS0 and larger UDP packets.
• All signing operations happen offline or on a dedicated signing server; private keys never appear on public-facing resolvers.