Skip to content

Route53 DS record has wrong keytag

0

I have example.com registered with AWS. For top level zone, added a KSK key and activated DNSSEC to use that key. Went to registered domains console, selected example.com, "Manage keys" and added the content of the "Public key" from the previous step (content of "Establish a chain of trust" -> "Route 53 registrar").

dig example.com @8.8.8.8 DS
;; ANSWER SECTION:
example.com.		21600	IN	DS	**2___7** 13 2 E4B...44 42...48
example.com.		21600	IN	DS	**1___7** 13 2 18A...C8 BB...86

=> returns the proper record, except the Key Tag which is one less (-1) compared to the value inside the Key details page.

I tried this a second time, adding a second key, and I get the exact same result. For the child zones / subdomains, I added myself the DS record, and it works correctly. When testing the top domain here: https://dnssec-analyzer.verisignlabs.com/example.com all is good except 2 errors:

  • None of the 3 DNSKEY records could be validated by any of the 2 DS records - I need to mention here that I do have 3 keys right now -> one I added by mistake and deleted it, but is not yet propagated (for the next 2 days most likely)
  • The DNSKEY RRset was not signed by any trusted keys

I don't know the details of DNSSEC internals, but having a different value for the KeyTag in the DS record might cause the issue as it will generate a different SHA. As the DS record for top level is not added manualy, but by adding the pub key and derived from there, could this be an issue with Route53 / AWS related?

delv @8.8.8.8 example.com
;; broken trust chain resolving 'example.com/A/IN': 8.8.8.8#53
;; resolution failed: broken trust chain
dig example.com @8.8.8.8 DNSKEY
...
;; ANSWER SECTION:
example.com.		3600	IN	DNSKEY	256 3 13 wyTR...Fxu+ /+R+Zr...Q== **-> wrong deleted key**
example.com.		3600	IN	DNSKEY	257 3 13 3wV0...OxK qKFjjm...A== **-> first key**
example.com.		3600	IN	DNSKEY	257 3 13 6NVX...Io0 J11HP...Q== -> **second key**

These keys in the response are split between 55 and 33 characters, but they contains proper value when the two parts are concatenated. Not sure if this is how is formatted by dig, or this is normal as the key contains sha/salt or if this is OK as is.

Thank you in advanced for any support!

asked 3 years ago800 views
1 Answer
0
Accepted Answer

For anybody else having this issue: the key type had to be KSK and not ZSK. I assume the 1 unit difference between the actual key tag in the pub key and the value returned by dig - that is the DS record, should of tell me the problem, but for that I most likely needed to know very in depth the way DNSSEC derives the KeyTag, and all the components actually from the PUBKEY.

Thank you all people that tried to look into this and good luck!

answered 3 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.