DNSSEC¶

DNS Security Extensions (DNSSEC) provides cryptographic authentication of DNS data.

Current Implementation Status¶

✅ DNSSEC Validation: Bindy currently supports DNSSEC validation of responses from upstream nameservers.

🚧 DNSSEC Zone Signing: Automatic zone signing is planned but not yet implemented. See DNSSEC Zone Signing Roadmap for implementation timeline.

DNSSEC Validation (Current Feature)¶

Overview¶

When DNSSEC validation is enabled, BIND9 will verify cryptographic signatures on DNS responses from other nameservers. This protects against: - Cache poisoning attacks - Man-in-the-middle tampering - Spoofed DNS responses

Important: DNSSEC validation requires:

Valid DNSSEC trust anchors
Proper network connectivity to root DNS servers
Accurate system time (NTP synchronization)

Invalid or missing DNSSEC signatures will cause queries to fail when validation is enabled.

Enabling DNSSEC Validation¶

Configure validation in the Bind9Cluster global configuration:

apiVersion: bindy.firestoned.io/v1beta1
kind: Bind9Cluster
metadata:
  name: production-dns
  namespace: dns-system
spec:
  global:
    dnssec:
      validation: true  # Enable DNSSEC validation of upstream responses

Or override per-instance in Bind9Instance:

apiVersion: bindy.firestoned.io/v1beta1
kind: Bind9Instance
metadata:
  name: primary-dns
  namespace: dns-system
spec:
  clusterRef: production-dns
  config:
    dnssec:
      validation: true  # Instance-specific override

Verification¶

Check that DNSSEC validation is working:

# Get BIND9 pod IP or service IP
SERVICE_IP=$(kubectl get svc -n dns-system production-dns-primary -o jsonpath='{.spec.clusterIP}')

# Query a DNSSEC-signed domain
dig @$SERVICE_IP cloudflare.com +dnssec

# Look for the 'ad' (authentic data) flag in the response
# flags: qr rd ra ad; QUERY: 1, ANSWER: 1, ...
#                ^^-- This indicates successful DNSSEC validation

# Query a domain known to have broken DNSSEC
# This should FAIL if validation is working correctly
dig @$SERVICE_IP dnssec-failed.org

Troubleshooting DNSSEC Validation¶

Validation Failures¶

If queries fail with validation enabled:

# Check BIND9 logs for DNSSEC errors
kubectl logs -n dns-system -l app.kubernetes.io/component=bind9 | grep -i dnssec

# Common errors:
# - "broken trust chain" - Missing or invalid DS records
# - "no valid signature found" - Expired or missing RRSIG
# - "validation failed" - Signature verification failed

Bypass Validation for Testing¶

To query without DNSSEC validation (for debugging):

# Use +cd (checking disabled) flag
dig @$SERVICE_IP example.com +cd

# This retrieves the response without validating signatures

Time Synchronization Issues¶

DNSSEC signatures have validity periods and will fail if system time is incorrect:

# Check BIND9 pod time
kubectl exec -n dns-system -l app.kubernetes.io/component=bind9 -- date

# Compare with actual time
date

# If time is off, ensure NTP is configured on nodes

DNSSEC Zone Signing (Planned Feature)¶

Status: 🚧 Not yet implemented

Bindy will support automatic DNSSEC zone signing in a future release, including:

Automatic key generation (KSK and ZSK)
Configurable signing policies
Automatic key rotation
DS record generation for parent zones
NSEC3 support for authenticated denial

For details, see:

Manual Zone Signing (Workaround)¶

Until automatic signing is implemented, you can manually sign zones inside BIND9 pods:

# 1. Generate keys (inside BIND9 pod)
kubectl exec -n dns-system -l app.kubernetes.io/component=bind9 -- \
  dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.com

# 2. Sign the zone file
kubectl exec -n dns-system -l app.kubernetes.io/component=bind9 -- \
  dnssec-signzone -o example.com /var/cache/bind/db.example.com

# 3. Extract DS record for parent zone
kubectl exec -n dns-system -l app.kubernetes.io/component=bind9 -- \
  cat dsset-example.com.

Important: Manual signing is not persistent across pod restarts and does not integrate with Bindy's declarative zone management. Use only for testing or temporary purposes.

DNSSEC Record Types¶

Understanding DNSSEC record types:

Record Type	Purpose	Example
DNSKEY	Public signing keys (KSK and ZSK)	`example.com. IN DNSKEY 257 3 13 ...`
RRSIG	Cryptographic signatures for records	`example.com. IN RRSIG A 13 2 3600 ...`
NSEC	Proof of non-existence (shows what doesn't exist)	`example.com. IN NSEC www.example.com. A RRSIG`
NSEC3	Privacy-preserving proof of non-existence (hashed)	`abc123.example.com. IN NSEC3 1 0 10 ...`
DS	Delegation signer (published in parent zone)	`example.com. IN DS 12345 13 2 ABC...`

Note: When DNSSEC signing is implemented, Bindy will automatically generate and manage these records.

Best Practices¶

For DNSSEC Validation (Current)¶

Test before production - Enable validation in staging first to identify upstream DNSSEC issues
Monitor query failures - Alert on increased SERVFAIL responses after enabling
Keep trust anchors updated - BIND9 manages this automatically via RFC 5011
Ensure NTP sync - DNSSEC signature validation requires accurate time
Document upstream dependencies - Know which upstream resolvers support DNSSEC

For DNSSEC Signing (Future)¶

When zone signing is implemented:

Start with test zones - Validate DS record publication process
Monitor key expiration - Alert before keys expire
Automate DS updates - Integrate with domain registrar APIs where possible
Use NSEC3 - Provides better privacy than NSEC for zone enumeration
Plan for emergencies - Have procedures for emergency key rollovers

Reference¶

DNSSEC RFCs¶

RFC 4033 - DNS Security Introduction and Requirements
RFC 4034 - Resource Records for DNSSEC
RFC 4035 - Protocol Modifications for DNSSEC
RFC 5155 - NSEC3 (Hashed Authenticated Denial)
RFC 8624 - Algorithm Requirements and Usage