PLNOG11: Slaying the Two-Headed Beast: Challenges and Triumphs of DNSSEC (panel)

### Overview At PLNOG 11, Dan York (Internet Society Deploy360) moderated a panel titled "Slaying the Two-Headed Beast: Challenges and Triumphs of DNSSEC," addressing the operational challenges, advantages, and deployment strategies of DNSSEC. The panel featured experts Frederick (StatDNS), Krzysztof Olejniczak (NASK / .pl registry), and Patrik Wallström (.se / OpenDNSSEC). The discussion explored the dual nature of DNSSEC—signing zones on the authoritative side and validating responses on the resolving side—while examining emerging standards such as DANE and real-world deployment lessons from ccTLD registries.

### Key Topics - **Signing vs. Validating**: DNSSEC relies on public-key cryptography where authoritative nameservers publish digital signatures alongside DNS records, and validating recursive resolvers verify signatures up to the root zone. - **Automation and Key Management**: Manual signing and static key management carry significant operational risks. Software like OpenDNSSEC was developed to automate zone signing, policy enforcement, and key rollovers. NASK developed automated scripts and wrappers around DNS software to sign the .pl zone three times daily. - **Registry Incentives & Adoption**: The .se ccTLD initially charged extra for DS record publication, which hindered adoption; reversing policy to make signed domains cheaper significantly drove uptake, resulting in roughly one-third of the .se zone being signed. - **DANE (RFC 6698) and Certificate Validation**: DANE enables domain owners to bind SSL/TLS certificates or certificate fingerprints to DNS via TLSA records secured by DNSSEC, mitigating reliance on hundreds of certificate authorities. While browser adoption remains slowed by concerns over latency and packet sizes, DANE is actively being tested in SMTP, XMPP, and VoIP/SIP. - **Resolver Deployment and Failure Modes**: DNSSEC does not have a user-facing failure mode; validation failures typically return `SERVFAIL`, causing applications to fail silently without explicit error details. Major milestones like Comcast and Google Public DNS enabling validation increased global validation percentages from around 3% to 8%.

### Technical Details - **Hardware Security Modules (HSMs)**: NASK integrated tamper-proof HSMs utilizing the PKCS#11 standard to protect cryptographic signing keys for the .pl zone, requiring testing to ensure software compatibility and sufficient throughput. The panelists noted that while HSMs are critical for high-impact TLDs and enterprises, smaller domain owners can sign without dedicated hardware. - **Resource Demands**: Validating resolvers require additional CPU and memory capacity to process cryptographic validations, along with larger network pipes to accommodate DNSSEC responses that are 4–5 times larger than traditional DNS responses. - **Packet Fragmentation & Home Gateways**: Large DNS packets containing DNSKEY and TLSA records can fail to traverse older consumer home routers and gateways, prompting ongoing standardization work in IETF home networking groups. - **Operating System Integration**: Modern Linux distributions and BSD releases (such as FreeBSD 10 bundling Unbound instead of BIND, as well as Fedora and Debian initiatives) increasingly enable validating resolvers by default.

### Takeaways Network operators are encouraged to activate DNSSEC validation on recursive resolvers immediately—often requiring only a single configuration line in software such as Unbound or Windows Server. The panel stressed that mastering zone signing and automated key rollover early carries far less operational risk while adoption is still growing, rather than waiting until widespread validation turns configuration errors into catastrophic user outages.