1

I am having a major problem generating a compliant DNSSEC key pair for use with a .de domain name.

DENIC have a testbed - Nameserver Predelegation Check Web Interface at https://www.denic.de/en/service/tools/nast/ and the idea is that a customer with a .de domain name enters their domain name and (optionally) nameservers and DNSKeys, with the NAST web interface then checking everything and confirming whether everything is compliant or not. So far so good.

The problem is the DNSKeys: I use dnssec-keygen with BIND in order to generate the keys and normally have no problem at all with this using something along the lines of:

dnssec-keygen -3 -a ECDSAP256SHA256 -n ZONE -K /var/named/dynamic test.com.

...and, indeed, the above should generate keys that comply with DENIC's requirements:

  1. ZONE must be set (it is)
  2. it must be NSEC3-capable (it is)
  3. it must be algorithm 3, 5, 6, 7, 8, 10, 12, 13 or 14 (it is: algorithm 13)
  4. it must be 512 to 4096 bits in length (algorithm 13 is, but it is not possible to stipulate a bit length using dnssec-keygen)

...

...

I have now found two solutions to this, both of which (as would normally be the case) require the addition of DS record entries by the registrar of the domain(s) for which the DNSSEC keys have been generated in order to avoid missing DS records warnings in validation checks[1].

...

[1] Once validatable records have been generated for DENIC's NAST page, DS record keys may be generated using one or the other of the following (amended first according to the intended domain name):

dnssec-dsfromkey -a SHA-1 Kexstocktra.de.+008+50707.key
dnssec-dsfromkey -a SHA-256 Kexstocktra.de.+008+50707.key
dig @127.0.0.1 dnskey exstocktra.de | dnssec-dsfromkey -f - exstocktra.de

In the name.com control panel once validatable CSK or KSK DNSKeys have been submitted to DENIC's NAST, that information becomes visible in the customer control panel (albeit with No in both the DS and RRSIG columns, which is to be expected pending the input of DS records on the registrar side).

Unfortunately, entering the DS record entries into name.com's control panel (as a customer would normally do) just produces an error: success message, and the entries are not accepted (name.com's setup normally produces an error for DS record entries alongside the display of the details that have been entered and a success message, so the presence of an error message on its own cannot be relied on). I am attempting to get name.com to fix this problem, but their development team seem to having another of their infamous "code freezes", so progress on this is slow.

...

Anyway, this is a very rough outline, based on Fedora 29 (RHEL) using BIND DNS (BIND 9.11.4-P2-RedHat-9.11.4-13.P2.fc29 (Extended Support Version):

/etc/bind/named.conf:

dnssec-enable yes;
dnssec-validation yes;
managed-keys-directory "/var/named/dynamic";

zone "exstocktra.de." IN {
    type master;
    file "named.exstocktra.de";
    auto-dnssec maintain;
    // enable the automatic signing
    key-directory "/var/named/dynamic";
    // directory in which to search for the DNSSEC keys
    update-policy local;
    // update-policy local
    inline-signing yes;
    // this is an optional addition, but is required in order
    // for BIND to handle zone signing and is essential for
    // ZSK keysets that are acceptable to DENIC's NAST
    // interface.
};

cd /var/named/dynamic

Create a Zone Signing Keyset (ZSK) [faster if haveged or rng-tools (thanks @Håkan Lindqvist) are installed on the system].

dnssec-keygen -3 -a ECDSAP256SHA256 -n ZONE -K /var/named/dynamic exstocktra.de.

========================================================================

If you just require a ZSK keyset for use with a .de domain name then it should now be possible to restart named, rndc reload, restart named again, and to use the steps detailed below to generate the information for DENIC's NAST interface and the registrar's DS records.

Note: this will produce a missing SEP flag warning. dnssec-keygen does not support SEP flag (KSK only), so in order to avoid Secure End-Point warnings it is necessary to generate and use KSK keysets, not ZSK.

=========================================================================

...and then create a Key Signing Key (KSK):

dnssec-keygen -f KSK -3 -a ECDSAP256SHA256 -n ZONE -K /var/named/dynamic exstocktra.de.

The directory will now have 4 keys: 2 private/public pairs comprising of one each of ZSK and KSK.

The following for can be used to add an $INCLUDE to the zone file for the zone’s key files and to verify that the addition will work:

cd /var/named/dynamic

for key in `ls Kexstocktra.de*.key`
do
echo "\$INCLUDE $key">> ../named.exstocktra.de
done

named-checkzone exstocktra.de "/var/named/named.exstocktra.de"

The entries in the zone file may then need amending to something more like:

$INCLUDE /var/named/dynamic/Kexstocktra.de.+013+08201.key
$INCLUDE /var/named/dynamic/Kexstocktra.de.+013+61007.key

Next restart named in order to implement the changes:

systemctl restart named
rndc reload
systemctl restart named

Check for the DNSKEY record using dig on the same server:

dig DNSKEY exstocktra.de. @localhost +multiline

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-13.P2.fc29 <<>> DNSKEY exstocktra.de. @localhost +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25049
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: f71e1737abd9de6a66c748e65c5f2de2fa584d957700a92d (good)
;; QUESTION SECTION:
;exstocktra.de.         IN DNSKEY

;; ANSWER SECTION:
exstocktra.de.          86400 IN DNSKEY 257 3 13 (
                                cQ9PiHhVl5FGmf95rGc2Y5pqNiSD49nhARzLiSLzCH6h
                                bquxne/8FKBtiydWLwNI2uft3c19m4F4sBCs3h/2vw==
                                ) ; KSK; alg = ECDSAP256SHA256 ; key id = 8201
exstocktra.de.          86400 IN DNSKEY 256 3 13 (
                                OpSJYBpdPcroNXNIH8n3/DrRDmTuL6QfpLcaKqrGzjQ5
                                0JgIVyO0RsnuN2uWNMPyclfe0dkobesMFCAqp1Ki7Q==
                                ) ; ZSK; alg = ECDSAP256SHA256 ; key id = 61007

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Sat Feb 09 19:45:38 GMT 2019
;; MSG SIZE  rcvd: 230

Also check for the presence of RRSIG records:

dig A exstocktra.de. @localhost +noadditional +dnssec +multiline

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-13.P2.fc29 <<>> DNSKEY exstocktra.de. @localhost +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13699
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e06c70f5cf57425d4cad03b95c5f2e4734fd5a649042689d (good)
;; QUESTION SECTION:
;exstocktra.de.         IN DNSKEY

;; ANSWER SECTION:
exstocktra.de.          86400 IN DNSKEY 257 3 13 (
                                cQ9PiHhVl5FGmf95rGc2Y5pqNiSD49nhARzLiSLzCH6h
                                bquxne/8FKBtiydWLwNI2uft3c19m4F4sBCs3h/2vw==
                                ) ; KSK; alg = ECDSAP256SHA256 ; key id = 8201
exstocktra.de.          86400 IN DNSKEY 256 3 13 (
                                OpSJYBpdPcroNXNIH8n3/DrRDmTuL6QfpLcaKqrGzjQ5
                                0JgIVyO0RsnuN2uWNMPyclfe0dkobesMFCAqp1Ki7Q==
                                ) ; ZSK; alg = ECDSAP256SHA256 ; key id = 61007

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Sat Feb 09 19:47:19 GMT 2019
;; MSG SIZE  rcvd: 230

It should now be possible to copy the key from the first of the two blocks of code (as shown above) and to use it on DENIC's NAST page (link given below) in order to create validating DNSSEC records, remembering to select the CSK/KSK radio button and the correct algorithm first.

https://www.denic.de/en/service/tools/nast/

  • What specifically are you entering into their form? Can you name an actual domain that would be suitable for reproducing the problem? – Håkan Lindqvist Feb 4 '19 at 20:34
  • Purely from looking at the form it appears they ask you to enter the public key, however you are talking about DS (which is not the public key itself). Are you sure you are entering the correct value? – Håkan Lindqvist Feb 4 '19 at 20:36
  • As for your confusion regarding KSK/ZSK/CSK, you are expected (this is not about NAST/DENIC/...) to either have two separate keypairs: one KSK (SEP set) for signing your set of keys only and one ZSK (SEP not set) for signing your zone, or alternatively have a single keypair: CSK (SEP set) used to sign everything. – Håkan Lindqvist Feb 4 '19 at 20:53
  • You first command generates a zone key. This is not what an online checking tool needs. As Håkan Lindqvist explained, normally you have a KSK signing this ZSK. This KSK is tied to a specific DS records that exist in the parent of the zone. When you use an online checking tool for a domain not published the tool needs to have the equivalent of the DS record that would be in the parent zone. Depending on the parent policies and the tool features, you either need to supply a key or its digest directly. – Patrick Mevzek Feb 5 '19 at 2:42
  • Yes, - good points, - thanks. - I did try entering the keys at the registry first, but they were rejected and continue to be rejected; that is why I thought that possibly the purpose of the NAST interface was to verify if the key was good or not. - I can see what you and Håkan are saying, though: I need to produce a key for domainA and then I need to produce a key signed by domainA's key and THAT is the key that I need to use because it will have inherent trust. - Is that correct? – user506088 Feb 6 '19 at 1:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy