deSEC and IONOS

[phil]

Hi,
I’ve been using deSEC for a while and got an email stating that some action is required. I’m not the most tech-savvy person out there, so I’m struggling lightly at this:

Your provider may require you to input this information as a block or as individual values. To obtain individual values, split the text below at the spaces to obtain the

From my own account, obv. I made the keys unrecognizable.

- key tag,
- algorithm,
- digest type
- digest (in this order).
5680 13 2 2*******9ab*********bbf82f*******7b2e39d******43d5******4a
5680 13 4 b******************867**c24********************bc7****bb***********464******108

NOTE: no uppercase characters in both of those keys. In IONOS’s example pubKey, there are, and there are special characters as well + and / - which is why I was not sure if the second line is in fact the pubKey.

From IONOS’s Website:

In order for us to set up the DS record for you, we need your domain name and the information listed below in the following format:

> ​"extensions": {
> "secDns": {
> "dsData": [{
> "keyTag": 5680,
> "alg": 13,
> "digestType": 2,
> "digest": "2*******9ab*********bbf82f*******7b2e39d******43d5******4a",
> "keyData": {
> "flags":
> "protocol":
> "alg": 13
> "pubKey":
> }
> }]
> }
> }
> }

This example lists the required information for the domain example.com:

"extensions": {
"secDns": {
"dsData": [{
"keyTag": 370,
"alg": 13,
"digestType": 2,
"digest": "BE74359954660069D5C63D200C39F5603827D7DD02B5 6F120EE9F3A86764247C",
"keyData": {
"flags": 257
"protocol": 3
"alg": 7
"pubKey":"/AwEAAbinasY+k/9xD4MBBa3QvhjuOHIpe319SFbWYIRj /nbmVZfJnSw7By1cV3Tm7ZlLqNbcB86nVFMSQ3JjOFMr" }
}]
}
}

You can usually find this information in the management interface of your DNS provider. If you do not have access to this information, please contact your DNS provider.

################

Thanks for assisting

[fiwswe]

You have not actually asked any question. But I am assuming you want to know which data to fill in to the fields, IONOS wants to have?

Multiple digests are possible. So these are just two digests calculated with different methods:

@phil

5680 13 2 2*******9ab*********bbf82f*******7b2e39d******43d5******4a
5680 13 4 b******************867**c24********************bc7****bb***********464******108

BTW: Digests and public keys are not confidential information. They will be published for all to see in the DNS system. No need to anonymize them. The only thing that is confidential would be the corresponding private key, which you will never see in the case of deSEC.

The digest is a hexadecimal value, capitalisation of the letters should make no difference. You can look it up in the deSEC web interface. Click on the (i) next to the domain name and select the DS RECORDS tab. The first value is the keyTag, the next the alg (13), the 3rd the digestType (2 or 4) and the long string the digest.

The public key is a base64 string so capital and small letters, digits and some special characters are expected. You can look it up in the deSEC web interface. Click on the (i) next to the domain name and select the DNSKEY RECORDS tab. The first value is the flags, the second the protocol, the 3rd the alg and the long string the pubKey.

HTH
fiwswe

[fiwswe]

One more thing: Once you have the public key, any digest can be calculated from that. So giving IONOS both is somewhat redundant.

fiwswe

[phil]

hi, thanks I didn’t know. Better safe than sorry for masking stuff that is labelled KEY I thought the first line was a private key, and the second line a pub key, but as I didn’t know… well.

Ok, yes my question was exactly this: What information does IONOS want from me? They provide a template, I have posted this template:

"extensions": {
"secDns": {
"dsData": [{
"keyTag": 370,
"alg": 13,
"digestType": 2,
"digest": "BE74359954660069D5C63D200C39F5603827D7DD02B5 6F120EE9F3A86764247C",
"keyData": {
"flags": 257
"protocol": 3
"alg": 7
"pubKey":"/AwEAAbinasY+k/9xD4MBBa3QvhjuOHIpe319SFbWYIRj /nbmVZfJnSw7By1cV3Tm7ZlLqNbcB86nVFMSQ3JjOFMr" }
}]
}
}

Now what I got from deSEC was those two lines

@fiwswe

The digest is a hexadecimal value, capitalisation of the letters should make no difference. You can look it up in the deSEC web interface. Click on the (i) next to the domain name and select the DS RECORDS tab. The first value is the keyTag, the next the alg (13), the 3rd the digestType (2 or 4) and the long string the digest.

yes that is where I got the information from. Ans I think this is correct then? I filled the template with this information. Except the "pubKey": field - if I understand you correctly, it is not the longer one.

@phil

> ​"extensions": {
> "secDns": {
> "dsData": [{
> "keyTag": 5680,
> "alg": 13,
> "digestType": 2,
> "digest": "2*******9ab*********bbf82f*******7b2e39d******43d5******4a",
> "keyData": {
> "flags":
> "protocol":
> "alg": 13
> "pubKey":
> }
> }]
> }
> }
> }

I still don’t know where to find that pubKey, sorry for being stupid.

@fiwswe

The public key is a base64 string so capital and small letters, digits and some special characters are expected. You can look it up in the deSEC web interface. Click on the (i) next to the domain name and select the DNSKEY RECORDS tab. The first value is the flags, the second the protocol, the 3rd the alg and the long string the pubKey.

I can’t find any field labelled pubKey under DS Records, but under the other tab DSKEY Records.
which means I have to combine information from both tabs to fill out the template?

[fiwswe]

@phil

I can’t find any field labelled pubKey under DS Records, but under the other tab DSKEY Records.
which means I have to combine information from both tabs to fill out the template?

Exactly!

(And like I wrote, the DS information is theoretically redundant. But if IONOS wants it, by all means give it to them )

fiwswe

[phil]

@fiwswe

Exactly!

(And like I wrote, the DS information is theoretically redundant. But if IONOS wants it, by all means give it to them )

Great, I understand now. I also did some research and found this very well crafted documentation/presentation:

DNSSEC-101-Abridged-Slides.pdf

[fiwswe]

Nice PDF!

Some small nitpicks:

• They do not mention the CSK (Combined Signing Key) used e.g. by deSEC. It is basically a single private/public key pair for signing the zone and for signing the keys (DNSKEY RRset). So the KSK is identical to the ZSK in this case. Flags: 257
• NSEC was replaced by NSEC3. Because NSEC allowed scanning a zone for all RRsets. NSEC3 fixes that problem. I have not seen NSEC in some time.
• If you rely on an outside validating Recursive Name Server then an attacker could interfere between the local Stub Resolver and the outside Recursive NS. So for best (most secure) results run a validating Recursive NS locally, ideally on the same machine that generates the queries and point your clients to that NS. [I use unbound(8) for this on OpenBSD for example.]
• One of the major practical problems is still getting Domain Registrars to set/update the DS records in the parent zone. (Exactly what you were struggling with with IONOS.) Some have (semi-)automated workflows, others require contacting support (and being persistent until you get competent help) and alas still others can’t do this at all. It’s high time CDS/CDNSKEY are implemented and used widely to automate this. (See RFC 8078)

fiwswe