1. Docs
  2. DNSSEC

DNSSEC

Overview

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.

References:

Use Cases

DNSSEC

Discussion

High-level design

  • 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.

    ../../_images/dnssec-basic-diagram.png

  • 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:

LDAP Schema

Keys

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).

FreeIPA specifics

  • FreeIPA server with DNSSEC support should indicate this support via cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example object in LDAP:
    • The first version with key-generator will have an attribute: ipaConfigString: version 1
    • The master server with key-generator will special attribute: ipaConfigString: keygenerator

This will enable upgrade scripts to detect if some old replicas are still in the topology or not. See discussion on freeipa-devel list.

Implementation

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.

Feature Management

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 DNSSEC Longterm Key Rotation

$ ipa dnszone-mod example.com. --dnssec=TRUE
$ ipa dnszone-mod example.com. --dnssec=FALSE

Replication

Nothing for DNSSEC signing itself. DNSSEC Longterm Key Rotation 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.

Dependencies

Nothing for DNSSEC signing itself. Key management mechanism may require new packages, see detailed plans linked above.

External Impact

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 Plan

Test scenarios that will be transformed to test cases for FreeIPA Continuous Integration during implementation or review phase.

  • Generate signing keys

    $ dnssec-keygen -3 -b 2048 -f KSK dnssec.test
$ dnssec-keygen -3 -b 1024 -f KSK dnssec.test

  • Copy keys into /var/named/dyndb-ldap/ipa/dnssec.test/keys/

  • Create a signed zone

    • set idnsSecInlingSigning attribute to TRUE

  • Do zone transfer and store the result in a file:

    $ dig @127.0.0.1 -t AXFR dnssec.test. > dnssec.test.db

  • Verify that signatures in the zone are correct:

    $ ldns-verify-zone -S -k Kdnssec.test.+007+12345.key -k Kdnssec.test.+007+23456.key dnssec.test.db

RFE Author

Petr Spacek <pspacek@…>

© Copyright 2017, bind-dyndb-ldap contributors. Created using Sphinx.