DNSSEC on .de-domain with united-domains.de

Managed DNS Hosting
1

Hi guys,

love desec and the work you do! My last hurdle is to activate dnssec.

I talked to united-domains and they are willing to setup the corresponding values for my .de-domain. I send them DS and DNSKEY records and they got back to me with a specific format request.

Required values for .de, .eu-Domains:
    DNSSEC-KEYDATA-FLAGS=
    DNSSEC-KEYDATA-PROTOCOL=
    DNSSEC-KEYDATA-ALG=
    DNSSEC-KEYDATA-PUBKEY=

I followed your hint and split the dnskey record into flags, protocol, algorithm, and public key. Support got back to me that pubkey is not valid because it “is not a valid value for 'base64Binary”.

Any ideas on how to solve this? Do I need to convert the public key somehow?

2

Hi inetipti,

Thanks for your message, and welcome to deSEC! :slight_smile:

What is the public key value you gave them? (You can post it here; as the name says, it’s not secret.)

Stay secure,
Peter

3

Hi Peter,

thanks for your reply. I used the last part of the dnskey record:

XdmWivRYYuYXQmQvigB8lPPfFVZQXcNIVQeBJ+xjuOa2q+gVyedqdjPwIUb/VOfsXl0UNtoiIzoaB6hslmu+A==

4

Hi inetipti,

That is indeed not a valid key. I suspect some kind of copy-and-paste error, but maybe it’s something else.

Can you please contact our support via email and send your domain name so we can take a look?

Sorry for the trouble, but I’m sure there is a straightforward explanation.

Stay secure,
Peter

5

Hi Peter,

sorry, the pubkey I posted contains indeed a copy-and-paste error.

I used the copy to clipboard function on desec.io frontend, this is the dnskey record:

257 3 13 2XdmWivRYYuYXQmQvigB8lPPfFVZQXcNIVQeBJ+xjuOa2q+gVyedqdjPwIUb/VOfsXl0UNtoiIzoaB6hslmu+A==

And this is how a split the values up (copied from email):

DNSSEC-KEYDATA-FLAGS=257
DNSSEC-KEYDATA-PROTOCOL=3
DNSSEC-KEYDATA-ALG=13
DNSSEC-KEYDATA-PUBKEY=2XdmWivRYYuYXQmQvigB8lPPfFVZQXcNIVQeBJ+xjuOa2q+gVyedqdjPwIUb/VOfsXl0UNtoiIzoaB6hslmu+A==

6

Hi inetipti,

The values you use seem to be valid key parameters (although I can’t tell if it’s the correct key, as I don’t know your domain name). As far as I can tell, your registrar should be accepting these values.

You can check yourself that the pubkey data can be decoded without error. For example, if you use the decoder here, it will output some cryptic text (which is correct). When entering the pubkey value you posted previously (the one with the copy/paste error), you will get an error message instead.

Maybe there also was a copy/paste error ongoing at the customer support of your registrar? I’d suggest to try it again with them, and make sure that everything is exactly identical as in your last post. If that doesn’t work, please shoot us an email, and we’ll try to work with united-domains.de.

Stay secure,
Peter

7

Hi Peter,

thanks for looking into it. The correct pubkey decodes fine for me too.

The support wrote me:

Leider wird der öffentliche SchlĂŒssel weiterhin nicht von der Vergabestelle akzeptiert.
Diese meldet uns:
‘2XdmWivRYYuYXQmQvigB8lPPfFVZQXcNIVQeBJ+xjuOa2q+gVyedqdjPwIUb/VOfsXl0UNtoiIzoaB6hslmu+A’ is not a valid value for 'base64Binary
The value ‘2XdmWivRYYuYXQmQvigB8lPPfFVZQXcNIVQeBJ+xjuOa2q+gVyedqdjPwIUb/VOfsXl0UNtoiIzoaB6hslmu+A’ of element ‘dnsentry:publicKey’ is not valid.

I noticed that the equal signs “==” at the end of the pubkey are missing, could this be the mistake? base64decode still decodes it fine though.

Additionally I was wondering if there is a way I can verify myself that the dnskey is correct and if so, are there any tutorials you know of?

My domain is: pibit.de
(There is nothing active on this domain currently, I’m only using it for sub-domains at the moment)

8

Hi inetipti,

Thanks! I confirmed that the key you posted is indeed the right one for your domain.

There should be no issue, and it looks like your registrar has some kind of bug in their software. This is very unfortunate, but not atypical for DNSSEC implementations :frowning:

You are correct that the == do belong to the key. However, they carry no information: base64-encoded data by convention uses a multiple of 4 characters. Your key has 86 characters, which is not a multiple of 4, so two padding characters are added. It’s like leading zeros in a number, except it’s at the end of the string. – Some base64 implementations (the more rigorous ones) insist that the padding characters are there. It’s fine to use such an implementation, but then they have to make sure that the = characters don’t get lost earlier on the way. :slight_smile:

I suggest you point out to them that the DNSKEY is indeed correct, and that you noticed the missing characters in the error message. You can further strengthen your correctness claim by posting this result from the dig DNS query tool:

$ dig DNSKEY pibit.de @ns1.desec.io

; <<>> DiG 9.16.1-Ubuntu <<>> DNSKEY pibit.de @ns1.desec.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12953
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pibit.de.			IN	DNSKEY

;; ANSWER SECTION:
pibit.de.		3600	IN	DNSKEY	257 3 13 2XdmWivRYYuYXQmQvigB8lPPfFVZQXcNIVQeBJ+xjuOa2q+gVyedqdjP wIUb/VOfsXl0UNtoiIzoaB6hslmu+A==

;; Query time: 28 msec
;; SERVER: 45.54.76.1#53(45.54.76.1)
;; WHEN: Mon Jun 07 11:55:40 CEST 2021
;; MSG SIZE  rcvd: 117

The DNSKEY record is listed there, and you can see it’s the same (the extra space is a “display space” only and means nothing).

(Some registrars also get the DNSKEY this way from the DNS, so you don’t have to provide it manually. However, it’s good that your registrar doesn’t do that, as DNSKEY retrieval via DNS is only secure after you turned on DNSSEC – so there’s a chicken-egg problem here.)

If your registrar can’t fix their bug, feel free to get back to me and I’ll give you a recommendation that will work smoothly.

Stay secure,
Peter

9

Hello Peter,

this is great insight into the problem, thanks for the explanation.

I relayed this information to the support staff and they could resolve the issue.
It was indeed a transmitting error on their side connected to the missing equal signs.

1 Like