DNSSEC I am not able to validate DNSKEY answer

Question

Here is the answer I got for .com.my. DNSKEY:

com.my. 3600    IN  DNSKEY  257 3 8 BQEAAAABu3FxmZrMlOMXlk2I2LeTsoMre8QaJKw75gSH9G8VCNX6AaVo8hT8qQyfNWDtdM+xiGqmYhWYFlABsIurfdfXVHNFep4Odn0klVD9tz11l9J4csNRRnJwOMYZV2q6yiBbyJuTvx6Z0xWuTsxtELIA597gxuGNQPumkIvllrTzauwhBtZp+m/GZwehVNAa1Vc6VxCLCPkXVK/6PliezJOTcJJXJmBTrML5x7UrYEYTW0EKDQCW4wHWbDrIXTuIXeBNW2S9ITX97WpLJXU5hSJPRteV8NK/j5KEbHxeq852cbU7CWa6whBz+sR/BoPuzTkX4M1e1PBJs7eppNNYffnsvw==
com.my. 3600    IN  DNSKEY  257 3 8 BQEAAAAB51ZYIFm8oIy4aaNzWPC0UmEuG7D/QB7fETcAf7bIYqVUpKnmgFPqmMwOSSSvbpJfJR9SvF/N5Gbaao3bI+GGVYRMo2nQ7djcAGkzrv0f1ZOHO1sdV0XQrjNTj+BpI1tTqQRun+78WxIU+Km8gRRaZE9NM9riELyhu7pAJiFEAs7Y1CjiFp00+Q5w6Xc2YOhiFy9h957Kq9YRhc1ELlJ8m276ekcda0bdJ2FF5iad8BbcC6+Iep7Mhc9TP7u4cI39j8TJRW0V9nTo/dc7Z1eIDQYxZ0hvkk1AY/f2SOT1/72M35yBQZLAAsStfX/w0F+Sg8ndoIcRBCvhajbckjFQQQ==
com.my. 3600    IN  DNSKEY  256 3 8 AwEAAcYcelsQmHJIShuGUB7QZQRx3jq253RbvLr8b2Piwmo6M9jvQBbNgMHkOiFI+v+AczufDzcf9lia38rAK5fmZqxHsft9meoFB1uXE9pp/ZB27rP+PTs9gGvuZKB/HyKjcwiwYWEhYQMrRaXk0Pr081MGzBjamZTMvvKTyRcmA+G9
com.my. 3600    IN  RRSIG   DNSKEY 8 2 3600 20200628013603 20200529003005 14256 com.my. MfavTkDT/Ar+31EN5BpCOt8ehR6QW8z/UaAZOLonvxEc3d8Xgx72dt09kyZworhXjg9FyUWtEJTWkrXcuIrMtrNcKg6smdnVzX04xbrDWDfKLYJh+0IxvtxPJeOQZ/ii0DpGn7oCPYqwc7qo3hZYPbgijiFsSVP+QJSepLCAnqjGfmYlmwltRgmlc9LCtCfbsO3ySlOVkhHtACa9BEYMG66rT8fAszFw48j8b3N7RdV/mRFYt/FHPgFpP2p4m6jNxWXDr1EQzuzLfswvUEs8Zl6swRHbutvm5j58mlJ+oM47x4qIpxLskeIfTwI33Bqv21HuRh3IwpG8tZNZbAxqcQ==
com.my. 3600    IN  RRSIG   DNSKEY 8 2 3600 20200628013603 20200529003005 52884 com.my. DaN+2IviGp8h7mGkWEpvCgOSsPZW0O9TORE6k/cfK9kbOg3ckjRtm1vAJ4VeXV/vOJzvjRkm2g9T31dhOTI9XgF4ro/0rvrZ9uwifaPWbKle/Q5mgfreCinEE13KGa2VIDacbRSFwtEeheCwGcvXivDDhkW7uQ4/a8Agxy0vS1VYduF9gY7WJhivZbko1ERwYdpqJCrb6Ppo9NFTWl5gZtHFc+WbF+pYkegGq6uPfcjGhi5C46d1gyjGy4NDOLP9hLDaConKWgayDIEzzHcvUR7rk4fCLfTfGimvFR8MBBcExKyc0xsz8YtEk/lo2Y3l+4gCJeJ/FOuJbzjjUVr8gg==

I do not get how to validate the RRSIG. For both RRSIG, I find one key with the same KeyTag/Algo/SignerName, but for both RRSIG the verification fails.

I do not get why it returns two RRSIG and two KSK. When I try nst.com.my on https://dnsviz.net that works well (https://dnsviz.net/d/nst.com.my/dnssec/), so how do they validate those records?

"so how do they validate those records?" In all generic terms, you shouldn't bother by the number of records, especially keys. The definition of DNSSEC to define if a record is valid (correctly signed, etc.) is if you find ONE valid trust path from it to the root KSK (or opposite direction depending on how the validation is done). You should just have to test what exists to find which one works, and as soon as you have one valid path the rest (other records) are irrelevant. This is useful to allow for algorithms migrations. — Patrick Mevzek, Jun 01 '20 at 00:50

score 1 · Answer 1 · answered May 30 '20 at 12:02

One simple tool for the sort of ad-hoc validation that you seem to look for is delv.

If you (for some troubleshooting purpose) want to validate the com.my. IN DNSKEY RRset you could simply run:

$ delv com.my DNSKEY
; fully validated
com.my.                 3541    IN      DNSKEY  256 3 8 AwEAAcYcelsQmHJIShuGUB7QZQRx3jq253RbvLr8b2Piwmo6M9jvQBbN gMHkOiFI+v+AczufDzcf9lia38rAK5fmZqxHsft9meoFB1uXE9pp/ZB2 7rP+PTs9gGvuZKB/HyKjcwiwYWEhYQMrRaXk0Pr081MGzBjamZTMvvKT yRcmA+G9  ; ZSK; alg = RSASHA256 ; key id = 23091
com.my.                 3541    IN      DNSKEY  257 3 8 BQEAAAABu3FxmZrMlOMXlk2I2LeTsoMre8QaJKw75gSH9G8VCNX6AaVo 8hT8qQyfNWDtdM+xiGqmYhWYFlABsIurfdfXVHNFep4Odn0klVD9tz11 l9J4csNRRnJwOMYZV2q6yiBbyJuTvx6Z0xWuTsxtELIA597gxuGNQPum kIvllrTzauwhBtZp+m/GZwehVNAa1Vc6VxCLCPkXVK/6PliezJOTcJJX JmBTrML5x7UrYEYTW0EKDQCW4wHWbDrIXTuIXeBNW2S9ITX97WpLJXU5 hSJPRteV8NK/j5KEbHxeq852cbU7CWa6whBz+sR/BoPuzTkX4M1e1PBJ s7eppNNYffnsvw==  ; KSK; alg = RSASHA256 ; key id = 14256
com.my.                 3541    IN      DNSKEY  257 3 8 BQEAAAAB51ZYIFm8oIy4aaNzWPC0UmEuG7D/QB7fETcAf7bIYqVUpKnm gFPqmMwOSSSvbpJfJR9SvF/N5Gbaao3bI+GGVYRMo2nQ7djcAGkzrv0f 1ZOHO1sdV0XQrjNTj+BpI1tTqQRun+78WxIU+Km8gRRaZE9NM9riELyh u7pAJiFEAs7Y1CjiFp00+Q5w6Xc2YOhiFy9h957Kq9YRhc1ELlJ8m276 ekcda0bdJ2FF5iad8BbcC6+Iep7Mhc9TP7u4cI39j8TJRW0V9nTo/dc7 Z1eIDQYxZ0hvkk1AY/f2SOT1/72M35yBQZLAAsStfX/w0F+Sg8ndoIcR BCvhajbckjFQQQ==  ; KSK; alg = RSASHA256 ; key id = 52884
com.my.                 3541    IN      RRSIG   DNSKEY 8 2 3600 20200628013603 20200529003005 14256 com.my. MfavTkDT/Ar+31EN5BpCOt8ehR6QW8z/UaAZOLonvxEc3d8Xgx72dt09 kyZworhXjg9FyUWtEJTWkrXcuIrMtrNcKg6smdnVzX04xbrDWDfKLYJh +0IxvtxPJeOQZ/ii0DpGn7oCPYqwc7qo3hZYPbgijiFsSVP+QJSepLCA nqjGfmYlmwltRgmlc9LCtCfbsO3ySlOVkhHtACa9BEYMG66rT8fAszFw 48j8b3N7RdV/mRFYt/FHPgFpP2p4m6jNxWXDr1EQzuzLfswvUEs8Zl6s wRHbutvm5j58mlJ+oM47x4qIpxLskeIfTwI33Bqv21HuRh3IwpG8tZNZ bAxqcQ==
com.my.                 3541    IN      RRSIG   DNSKEY 8 2 3600 20200628013603 20200529003005 52884 com.my. DaN+2IviGp8h7mGkWEpvCgOSsPZW0O9TORE6k/cfK9kbOg3ckjRtm1vA J4VeXV/vOJzvjRkm2g9T31dhOTI9XgF4ro/0rvrZ9uwifaPWbKle/Q5m gfreCinEE13KGa2VIDacbRSFwtEeheCwGcvXivDDhkW7uQ4/a8Agxy0v S1VYduF9gY7WJhivZbko1ERwYdpqJCrb6Ppo9NFTWl5gZtHFc+WbF+pY kegGq6uPfcjGhi5C46d1gyjGy4NDOLP9hLDaConKWgayDIEzzHcvUR7r k4fCLfTfGimvFR8MBBcExKyc0xsz8YtEk/lo2Y3l+4gCJeJ/FOuJbzjj UVr8gg==
$

And it looks up the necessary records, validates and outputs the validation result.

However, for normal use, you have no reason to use delv or other similar tools, but rather just make use of the validation logic built into the resolver implementation.

As for why com.my (actually also my) have multiple KSK keys active, it's not really possible to tell with certainty. But one might presume that they are in the process of a KSK rollover.
If you want certain answers regarding why they are doing what they are doing, you would have to direct the question to the com.my operator (or find some published information from them, if that is available).

"But one might presume that they are in the process of a KSK rollover." Not necessarily. You can have cold standby keys, outside of any rollover, just to prepare in future emergencies (urgent key rollover, and hence it is better to have the keys published, you just need then to publish the relevant DS at parent), see https://dnsviz.net/d/paris/XtROtQ/dnssec/ for one example. It is detailed in §4.2.4 of RFC 6781 "Stand-by keys". IANA is always picky about this when TLDs operators do it (as they check the configuration and flag a missing corresponding DS as an error) but it is possible. — Patrick Mevzek, Jun 01 '20 at 00:42
If you look at https://dnsviz.net/d/com.my/XmlkaA/dnssec/ done on 2020-03-11 you will see that they already had back then the two ZSKs with IDs of 52884 and 14286. If this was a key rollover it would take almost 3 months and, even if it is good in DNSSEC land to have long timers for things like that, 3 months become quite long (normally that delay would be over the frequency of change for the ZSK...) — Patrick Mevzek, Jun 01 '20 at 00:48
@PatrickMevzek However, in this case, it's not a standby key? (Both keys are in active use) — Håkan Lindqvist, Jun 01 '20 at 06:51
The ZSK is indeed signed by both KSKs, so maybe it is a standby but used or a rollover, but I have the feeling it is not a rollover. I can not formally prove it externally, as you said only the `com.my` operator could tell or if someone finds their "DNSSEC Policy Statement" which is kind of mandatory and lists the timers for KSK, ZSK and signatures updates. — Patrick Mevzek, Jun 01 '20 at 15:48

DNSSEC I am not able to validate DNSKEY answer

1 Answers1