My Awesome Project

Appearance

DNSSEC: Validation & Key Management ​

Tại sao điều này quan trọng ​

DNSSEC = DNS-level cryptographic security. Prevent DNS spoofing, cache poisoning, man-in-the-middle.

When critical: High-security environments (banking, government, healthcare).

DNSSEC Fundamentals ​

What DNSSEC Does ​

Without DNSSEC:
  Client: DNS query: api.example.com
  Attacker intercepts: Returns 10.0.0.100 (malicious IP)
  Client: Trusts response (no verification)
  Result: Compromised!

With DNSSEC:
  Client: DNS query: api.example.com
  Attacker intercepts: Returns 10.0.0.100 (malicious IP) + bad signature
  Client: Verifies signature → FAILS
  Result: Query rejected (SERVFAIL), client uses fallback

DNSSEC Chain of Trust ​

Root Zone
  ├─ DNSKEY (root public key)
  ├─ DS records (child zone digests)
  
.com Zone
  ├─ DNSKEY (.com public key)
  ├─ RRSIG (signed by root)
  ├─ DS records (example.com digests)
  
example.com Zone
  ├─ DNSKEY (example.com public key)
  ├─ RRSIG (signed by .com)
  ├─ A records (api.example.com)
  ├─ RRSIG (A records signed)
  
Validation:
  1. Validate example.com DNSKEY using root trust anchor
  2. Validate example.com A records using example.com DNSKEY
  3. If all signatures valid → Response trusted

Cloud DNS DNSSEC Support ​

Enable DNSSEC ​

bash
# Create zone with DNSSEC
gcloud dns managed-zones create example-zone \
  --dns-name=example.com \
  --visibility=public \
  --dnssec-state on

# Or update existing zone
gcloud dns managed-zones update example-zone \
  --dnssec-state on

# Get DS records
gcloud dns managed-zones describe example-zone \
  --format="get(dnssecConfig.dsRecords[].dsData)"

Key Signing Procedure ​

  1. Cloud DNS automatically generates:

    • KSK (Key Signing Key) - private, never exported
    • ZSK (Zone Signing Key) - rotated by GCP

  2. DS records (Delegation Signer):

    • Provided by Cloud DNS
    • Upload to parent zone (domain registrar)

  3. Signing process:

    • Cloud DNS auto-signs all records
    • Signatures include in responses
    • TTL for signatures synchronized with records

GCP Cloud DNS DNSSEC Details ​

Automation ​

GCP handles:
  ✓ Key generation (KSK, ZSK)
  ✓ Record signing (RRSIG generation)
  ✓ Key rotation (automatic)
  ✓ Signature refresh (as TTL approaches)
  
You provide:
  ✓ DS records to registrar
  ✓ Monitor signing status
  ✓ Ensure chain of trust maintained

Monitoring DNSSEC Status ​

bash
# Check DNSSEC config
gcloud dns managed-zones describe example-zone \
  --format="get(dnssecConfig)"

# Test DNSSEC validation
dig api.example.com +dnssec

# Check signatures
dig api.example.com +dnssec +multi

# Validate chain of trust
dig example.com DNSKEY +dnssec

Operational Considerations ​

Challenge 1: DS Record Management ​

Procedure:
  1. Enable DNSSEC on Cloud DNS zone
  2. Get DS records
     gcloud dns managed-zones describe example-zone \
       --format="get(dnssecConfig.dsRecords)"
  3. Login to domain registrar
  4. Add DS records to .com zone delegation
  5. Wait 24-48 hours for propagation

If DS records not updated:
  → DNSSEC validation fails
  → Query returns SERVFAIL
  → Clients see service as unavailable

Challenge 2: Key Rotation ​

Cloud DNS automatically rotates ZSK (Zone Signing Key) every ~30 days.

During rotation:
  1. New ZSK generated
  2. Both old+new ZSK published (overlap period)
  3. Records signed with both keys
  4. Old KSK invalidated after period
  5. Clients transparently validate

Implication: No manual action needed, but monitor status.

Challenge 3: Migration to/from DNSSEC ​

Enabling DNSSEC:
  1. Enable on Cloud DNS
  2. Get DS records
  3. Add to registrar
  4. Wait 24-48h
  5. Test: dig +dnssec
  
Disabling DNSSEC:
  1. Remove DS records from registrar
  2. Wait 24-48h for propagation
  3. Disable on Cloud DNS
  4. Clients no longer validate

DNSSEC Validation ​

Client-Side Validation ​

Most clients (browsers, apps) don't validate DNSSEC. Validation typically happens at:

  • Recursive resolver (8.8.8.8)
  • Stub resolver with DNSSEC support (rare)
Query path:
  Pod → CoreDNS (no validation by default)
      → VPC Resolver (169.254.169.254, no validation)
      → Cloud DNS (no validation)
      → Public resolver (8.8.8.8, validates)

Enabling Validation in CoreDNS ​

corefile
.:53 {
    cache 30
    errors
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
      ttl 30
    }
    
    # Enable DNSSEC validation
    dnssec {
      key file /etc/coredns/keys
    }
    
    forward . /etc/resolv.conf {
      max_concurrent 1000
    }
}

Troubleshooting ​

Issue 1: SERVFAIL After Enabling DNSSEC ​

bash
# Symptom: dig example.com +dnssec returns SERVFAIL

Debug:
  1. Check DNSSEC enabled
     gcloud dns managed-zones describe example-zone | grep dnssec
  
  2. Check DS records in registrar
     dig example.com DS
  
  3. Validate chain
     dig example.com +dnssec +trace
  
  4. Check propagation time (24-48h)
  
  5. If still failing: Contact registrar, ensure DS records correct

Issue 2: Signature Verification Failures ​

bash
# Test query
dig api.example.com +dnssec

# If BOGUS (signature invalid):
  1. Check if transitioning DNSSEC state
     Wait 48-72h, try again
  
  2. Check if zone misconfigured
     gcloud dns managed-zones describe
  
  3. Force re-signing
     gcloud dns managed-zones update --dnssec-state off
     (wait 1h)
     gcloud dns managed-zones update --dnssec-state on

Performance Impact ​

Latency ​

DNSSEC validation adds ~2-5ms per query.

With caching, impact minimal:
  First query: +5ms (validation)
  Cached queries: 0ms impact

CPU/Memory ​

Validation requires cryptographic operations:
  CPU spike: During signature verification (~0.1-1ms per query)
  Memory: DNSKEY stored in memory (~1KB per zone)
  
At scale (millions QPS): Consider caching resolver to offload

Best Practices ​

  1. Enable DNSSEC for production (especially public APIs)
  2. Upload DS records to registrar (critical step often missed)
  3. Monitor validation status (check regularly)
  4. Plan key rotation (automatic, but be aware)
  5. Test before production (ensure no SERVFAIL)
  6. Graceful migration (24-48h propagation time)
  7. Document DS records (for disaster recovery)

When NOT to Use DNSSEC ​

Cases where DNSSEC overhead not justified:

✗ Internal-only DNS (no need for public validation)
✗ High-frequency, latency-critical queries (5ms adds up at scale)
✗ Simple DNS setup (few zones, few records)
✗ Not compliance-required
✓ Use instead: VPN/mTLS for internal security

Cases where DNSSEC critical:

✓ Public APIs (customers access)
✓ Domain-critical (financial, healthcare)
✓ Compliance requirement (some frameworks)
✓ High-value target (worth cost)

References ​