DNSSEC is ... Quote from Wikipedia article about DNSSEC: The Domain Name System Security Extensions (DNSSEC) is a suite of IETF specifications for securing certain kinds of information provided by the DNS as used on IP networks.
It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.
- RFC 4033: DNS Security Introduction and Requirements
- RFC 4034: Resource Records for the DNS Security Extensions
- RFC 4035: Protocol Modifications for the DNS Security Extensions
- RFC 6781: DNSSEC Operational Practices, Version 2 (key rotation etc.)
- DNSSEC chapter in BIND 9.9 ARM
- Inline Signing in ISC BIND 9.9.0 - Examples
- Prevents DNS spoofing/cache poisoning
- See NIST Special Publication 800-81 - Secure Domain Name System (DNS) Deployment Guide for lenghty discussion about implications from insecure DNS
- Enables applications to trust data from DNS tree so the data can be used for new purposes. For example:
- See design page BIND9/Design/RBTDB. We decided to implement DNSSEC support on top of RBTDB from BIND 9.
- Key material handling (July 2013)
- Idea of super-master-server for key maintenance (August 2013)
- Another thread about key maintenance (August 2013)
- Key rotation - continuation (September 2013)
- Simo's proposal for distributed key rotation (September 2013)
- Use automatic zone signing from BIND 9 (so-called inline-signing).
- Unsigned data will be stored in LDAP.
- Signed data will be stored only in-memory or eventually in on-disk cache, never in LDAP DB.
- Store signing keys in LDAP DB so all IPA DNS servers can share them.
- Use OpenDNSSEC or other existing solution for key rotation.
- Blue components are controlled by us.
- Bind-dyndb-ldap has to mimic DB API precisely otherwise signing will not work as expected.
This design document describes only very basic functionality where a DNS zone is signed with provided signing keys. Those keys need to be generated and periodically rotated.
We will work on key management and automatic rotation in two phases:
To Be Done: See links above for for schema requirements.
LDAP schema should be forward-compatible so migration from short-term to long-term solution will not require changes in LDAP schema and data migration.
DNS Zone (idnsZone objectClass)
- Add new boolean attribute idnsSecInlineSigning:
- not present or FALSE => DNS zone does not support DNSSEC. Unsigned data are stored in in-memory DB managed by bind-dyndb-ldap (blue box in the diagram).
- TRUE => in-line signing is enabled. bind-dyndb-ldap will instruct BIND to create new in-memory database for signed data (black box in the diagram) and to do internal zone transfers from database with unsigned data (managed by bind-dyndb-ldap).
Additional requirements and changes discovered during the implementation phase:
- Inline-signing depends on IXFR zone transfer from unsigned to signed zone (internally inside BIND process). Bind-dyndb-ldap has to implement full support for IXFR. See ticket #64.
- IXFR requires some temporary files for so-called journal, i.e. write-access to file system is required.
In initial phase, user has to have an interface for enabling and disabling DNSSEC for particular DNS zone. This can be one boolean attribute for CLI and one check-box for WebUI. More complex management will be described as part of Long-term plan for key management?.
$ ipa dnszone-mod example.com. --dnssec=TRUE $ ipa dnszone-mod example.com. --dnssec=FALSE
Nothing for DNSSEC signing itself. Long-term plan for key management? will use replication for coordination among DNS masters.
Updates and Upgrades
DNSSEC feature will enabled by new attribute. Old replicas will serve unsigned zones without any change.
Nothing for DNSSEC signing itself. Key management mechanism may require new packages, see detailed plans linked above.
Key management mechanism will require coordination with FreeIPA/SSSD/certmonger team - we will probably need an mechanism for rotating keys on client side. This will be very handy for:
- Isolated environments where public root key was replaced by organization. (This will be also good for proof-of-concept deploynments.)
- Island of Security mode where organization signs own internal domains but keys used for signing are not published in parent (public) domain.
- Example: example.com. is purely internal signed domain and com. domain does not publish public keys used for signing.
- See RFC 5011: Automated Updates of DNSSEC Trust Anchors for inspiration. This doesn't solve case where all keys were compromised, this needs discussion.
Backup and Restore
- Temporary files produced by bind-dyndb-ldap don't need to be backed up.
- Signing keys can be re-generated after restore. This will require cooperation with operator of parent DNS zone because hashes of new keys have to be uploaded to the parent zone. For security reasons, I still prefer not to backup DNS signing keys.
Test scenarios that will be transformed to test cases for FreeIPA Continuous Integration during implementation or review phase.
Petr Spacek <pspacek@…>