Documentation

The project has updated the following documentation:

  1. The EPP interface documentation

    The documentation is extended with descriptions of how to exchange DNSSEC information over the EPP interface.

    The following changes to the EPP interface have been defined:

    1. The DNSSEC extensions shall be in accordance with secDNS-1.1 as defined in RFC5910.

    2. The element Maximum Signature Lifetime will not be accepted. Attempts to submit this element will be rejected.

    3. DS data shall be exchanged over EPP according to the DS Data Interface .
      Here, the variant with optional key data will also be accepted for registrars who want validation of their DS’s.

      Attempts to use Key Data Interface will be rejected.

    4. When it comes to which algorithms to accept, we will accept the ones that are commonly used which the system can handle. However, we might still block the most unusual ones, like GOST and the elliptical variants ( ECDSA, RFC 6605 ).

    5. When it comes to which digest types to accept, we will accept the ones that are commonly used which the system can handle. However, we might still block the most unusual ones, like GOST and SHA-384.

    6. Transfer of secure delegations between registrars:
      What should happen with the DS data when a secured delegation is to be transferred to a registrar who does not supports DNSSEC?
      We have chosen to perform the transfer, but strip the DS data. This will change the delegation to become unsecured.

    7. DNS checks.
      Some new DNSSEC checks will be performed during registration and update of delegations.

      The following checks will be performed when a delegation has at least one DS record:

      • Look up the DNSKEY records from each of the name servers for the delegation:
        • The DNSKEY record sets in all nameservers must match each other.
        • The DNSKEY record set must contain at least one key which is referred to from the DS set.
        • Look up RRSIG records for the DNSKEY record set. Check that at least one of the RRSIGS are signed with one of the keys which are referred to from the DS set.
        • Look up RRSIG records for the SOA record and the NS records. Each of the RRSIG sets must contain at least one RRSIG which is signed by one of the keys in the DNSKEY record set.

      Attempts to add DS records to a delegation will be rejected if any of those basic checks fail.

      Note that no DNSSEC specific checks are performed when name servers are added or modified.

  2. DNSSEC support in the Whois interface

    Whois er updated to present DNSSEC data for a domain if such data is registered. The newest version of the Whois interface document is published here.

  3. A new DPS document for .no

    Norid has written a DPS (DNSSEC Policy and Practice Statement) inn accordance with the format and contents as recommended in RFC6841.

    A DPS contains descriptions of the keys, algorithms and rollover procedures used by the registry, as well as a description of the infrastructure and how the signing chain and the keys are secured. We have based our choices of algorithms and other values on best practices from the DPS documents from se, nl and at.

    The document is published along with other technical documentation.
    The latest version of the DPS document can be found here (revision 1, dated 2014-09-18).

Last updated 2015 or before