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 04 '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 04 '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 04 '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 05 '19 at 02: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? –  Feb 06 '19 at 01:45
  • @YTreehuggerCymru This seems to completely change the question, into essentially "how should I sign my zone?". If this is with BIND (the tools mentioned suggest this) I would suggest reading https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html#dnssec-signing – Håkan Lindqvist Feb 08 '19 at 08:33
  • Looking at the latest update, I'm a bit confused. The steps look ok, but you showed the creation of algorithm 13 (ECDSAP256SHA256) keys, but then there are suddenly algorithm 7 (RSASHA1-NSEC3-SHA1) keys. There's also a strange mix of domain names, which also seems confusing. Could you make a simple example that reproduces the problem where you do not try to obfuscate anything, such that one can simply look at it and try out with the NAST test? – Håkan Lindqvist Feb 09 '19 at 19:32
  • Fair enough, and thanks. - The actual domain name is: exstocktra.de –  Feb 09 '19 at 19:42
  • @YTreehuggerCymru Ok, I tried filling in the actual values and get "Check successful." from NAST. – Håkan Lindqvist Feb 09 '19 at 19:58
  • Yes, - thanks, - I have that, too, but name.com is still telling me that there are no DS and RRSIG records, and https://dnssec-analyzer.verisignlabs.com/exstocktra.de is also telling me that there are no DS records. Any ideas? –  Feb 09 '19 at 20:01
  • Indeed, the delegation lacks DS records. Have you actually added a DS record (through your registrar)? – Håkan Lindqvist Feb 09 '19 at 20:04
  • No, - I thought that that may be what is causing the problem; but (and, yes, I am being serious here) name.com does not understand DENIC's DNSSEC implementation (it seems to be quite different to that of other registries), so my attempts to add the DS record files are failing. - I will need to update them and see if they can add the records manually, even if they cannot currently update the control panel. –  Feb 09 '19 at 20:10
  • @YTreehuggerCymru Ok, so you enter all the required values (should be readily available, essentially `dig exstocktra.de DNSKEY | dnssec-dsfromkey -2 -f - exstocktra.de` if they want the digest rather than the public key itself) but something fails on their side? If so, I think you are right that you will have to talk to their support about how to resolve that. – Håkan Lindqvist Feb 09 '19 at 20:17
  • Yes, and again, thanks: I have the DNSKEY records, and have just submitted them via a support ticket; so I might receive an acknowledgement in about a week's time, and a further acknowledgement about a week after that that the development team have finally decided to look into things =] (name.com is not exactly fast to resolve issues with domain names and their control panel). –  Feb 09 '19 at 20:25

0 Answers0