Funky Key Tag in AWS Route53 (2)

Timothe Litt litt at acm.org
Thu Dec 29 15:55:37 UTC 2022 

> What is annoying is it accepts the hash as perfectly valid and gets 
> the  DS record number as the wrong ID.
A key is just a bundle of bits, no way to validate it.  Well, perhaps 
the length should be consistent with the key type...

In fact, with the same input, dnssec-dsfromkey produces the same keytag 
as AWS.  Below I pretend that the hash from your DS is in a DNSKEY record.

|cat >tmp.key||
||ericgermann.photography. DNSKEY 257 3 8 
A17DF360A9E0CB485BD396A839119441C5FF62A9C9E46D586EBDD1D084E2E36B||
|

|dnssec-dsfromkey -2 tmp||
||ericgermann.photography. IN DS *22755* 8 2 
2E81A125523957ED2C3076B4E58BE159027F659D74E184E2F0B81D922D1E7FA9|

So, as I concluded, AWS was generating a DS for a different "key".  Its 
keytag was correct for the data it got.

Glad you got to a solution.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

On 29-Dec-22 10:39, Eric Germann wrote:
> I understand all the tools and output.  The error I was trying to find 
> is why they disagreed and checking all the points along the way. 
>  Thanks for your scripts.
>
> Anyways, for GoogleFu, I got it fixed and it works correctly now 
> thanks to 
> https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server-2
>
> For entering the DS record in to Route53, you enter the whole public 
> key in Base64 without spaces or newlines, not the hash of the key like 
> the registrars I’ve used for other domains.
>
> What is annoying is it accepts the hash as perfectly valid and gets 
> the  DS record number as the wrong ID.
>
> Thanks to all who helped!
>
> Eric
>
>
>> On Dec 29, 2022, at 10:06, Timothe Litt <litt at acm.org> wrote:
>>
>>
>>> That’s why I wanted to decode the DS record to see if it’s encoding 
>>> it as 32686 or 22755
>>
>> As I said, no decoding required.  Just look at the DS record.  The 
>> keytag is immediately after "DS" in plain, unencoded text.
>>
>> If the question is how to verify the keytag from the DNSKEY it 
>> references, I've shown you two different tools that produce the same 
>> result.
>>
>> If you use the same input file, you get the same answer from ISC and 
>> Net::DNS::SEC.
>>
>> |cat >tmp.key|
>>
>> |ericgermann.photography. DNSKEY 257 3 8 
>> AwEAAatPHgdYxFA74X+17xAMmZNn+I6XVzodbnA/m4M6vV+axYh+PTNt 
>> xrZSQ4PXEcJkNXF5OR1UPfPWea/gGIuYUbjMaa2H7fd+TXqc+C44U/2O 
>> vbZqefSUXl1QzqyxPyG7xZuAgTApFt+PuK9CrQtP7IV9qu34cXAXLGF1 
>> SgrhBi843sTESw8nBAv1MDLMBCDEULVOSghqqxdJQ57yGOdsgYFdt6kL 
>> UNA1zntZV49dDWHGttZWwhEnnMuNz+e6bRroETOIhtzxLn4HOievnZmV 
>> 4rqzh5Zku/06QMNiUWwePW07RIGVVzUszU0LaAgBh/m111x5UiYfup2N egWHPunS1IM=||
>> |
>>
>> |dnssec-dsfromkey -2 tmp||
>> ||ericgermann.photography. IN DS ||*32686 *8||2 
>> A17DF360A9E0CB485BD396A839119441C5FF62A9C9E46D586EBDD1D084E2E36B|
>>
>> That's the same answer as Net::DNS::SEC.  Two different tools from 
>> reputable sources, same answer.
>>
>> None of the installed keys have 22755.  DNSvis does show a DS record 
>> installed with 22755 (and no matching key).  So AWS is installing 
>> that DS from whatever input you provide it.
>>
>> That leaves:
>>
>>   * Different input to AWS vs. the local tools
>>       o perhaps you have a file with a different DNSKEY that you are
>>         uploading to AWS.  I've been known to accidentally overwrite,
>>         rename, or confuse files. (Not often, but it happens.)
>>       o have you verified that the contents of the file that you are
>>         using matches what's in the DNS?
>>       o Does AWS have an option to use a DNSKEY from your zone?  That
>>         would avoid the manual step.
>>   * If you're copy/pasting the DNSKEY file into AWS, corruption in
>>     the process (buffer overruns?)
>>   * It's not inconceivable that AWS has a bug, but someone should
>>     have hit one like this before you
>>
>> Before blaming AWS, I'd be very sure that the same key is being 
>> input.  If it is, they have a bug....
>>
>> You might also consider using a different key experimentally, on the 
>> off chance that a wrong keytag bug is data-dependent.
>>
>> But the most likely scenario is that somehow AWS is generating a DS 
>> for a different key.
>>
>> I don't use AWS, so that's as far as I can go.
>>
>> Good luck.
>>
>> Timothe Litt
>> ACM Distinguished Engineer
>> --------------------------
>> This communication may not represent the ACM or my employer's views,
>> if any, on the matters discussed.
>> On 29-Dec-22 09:28, Eric Germann wrote:
>>> Yeah, that’s the problem I’m trying to solve.  I run the key thru 
>>> dnssec-dsfromkey and get 32686, When I put the key in to Route53, I 
>>> get 22755 from the decoded DS record in the console for Route53.
>>>
>>> That’s why I wanted to decode the DS record to see if it’s encoding 
>>> it as 32686 or 22755
>>>
>>>
>>>> On Dec 29, 2022, at 09:17, Timothe Litt <litt at acm.org> wrote:
>>>>
>>>> On 28-Dec-22 19:40, Eric Germann wrote:
>>>>> My question is
>>>>>
>>>>> Is there any way to decode the DS record and see what key tag is 
>>>>> actually encoded in it?  If it’s 32686 it’s an issue with Route53. 
>>>>>  If it’s 22755 it’s an issue with dnssec-dsfromkey.
>>>>>
>>>>> If anyone wants the DNSKEY for algorithm 8, ping me off list and I 
>>>>> will share it with you in a private email.
>>>>>
>>>>> Thoughts?
>>>>>
>>>> And because it's trivial, here are the keytags for all your keys 
>>>> and DS records and how to get them.  Note that you have DNSKEY 
>>>> 32686: installed in the DNS, and that the installed DS is 22755.
>>>>
>>>> Can't say how it got that way, but that's what is there.  (Manual 
>>>> processes are error-prone.  That getting registrars to adopt 
>>>> CDS/CDNSKEY - RFC7344 - has been so slow is unfortunate.)  It's 
>>>> rarely the tools.
>>>>
>>>> | perl  -MNet::DNS::SEC -e'@keys = split /\n/, qx(dig +cdflag 
>>>> +short ericgermann.photography DNSKEY); print "$_ => 
>>>> ",Net::DNS::RR->new("ericgermann.photography. DNSKEY 
>>>> $_")->keytag,"\n" foreach (@keys);'||
>>>> ||257 3 8 AwEAAatPHgdYxFA74X+17xAMmZNn+I6XVzodbnA/m4M6vV+axYh+PTNt 
>>>> xrZSQ4PXEcJkNXF5OR1UPfPWea/gGIuYUbjMaa2H7fd+TXqc+C44U/2O 
>>>> vbZqefSUXl1QzqyxPyG7xZuAgTApFt+PuK9CrQtP7IV9qu34cXAXLGF1 
>>>> SgrhBi843sTESw8nBAv1MDLMBCDEULVOSghqqxdJQ57yGOdsgYFdt6kL 
>>>> UNA1zntZV49dDWHGttZWwhEnnMuNz+e6bRroETOIhtzxLn4HOievnZmV 
>>>> 4rqzh5Zku/06QMNiUWwePW07RIGVVzUszU0LaAgBh/m111x5UiYfup2N 
>>>> egWHPunS1IM= => *32686*||
>>>> ||256 3 8 AwEAAaD+/5eN/zIqYhG/CXXastruIQEBBuD2Y2Yinx+IqWvInKc5Kb6K 
>>>> AWvUWECjn0Q7Lrt1s759/04SZXm2M4GwuKBzY+Ern2ukWi0hQmUBqoET 
>>>> VSrFhu75FJpi0+8wJZhx5UVPg7NTriYXC29rSTBt/OCr/Ot+utf2P9G2 
>>>> hr/BXQqcwausick9Gu9zZtzB0072IEM6okZW1rDwlAwmlDjicJgbAnRt 
>>>> qgpWX21CgRG/G8Jjz4pGSP1rt54ilxVbCL8KR3huRaJGb6lnnJnQJckL 
>>>> oN2+rGaps1bLYC79fgdL5Y/fzR43J+te7RBo4AJXFhW9n1WL6KOKbprE 
>>>> pbl7yiINzTU= => 43126||
>>>> ||256 3 13 bX62WTOQmhTaqnQprecHwUjDzBGAQbF0kqywkNzE1yBTrmP/zBNhvtp+ 
>>>> H9iYf1OOcfyDo6iE1XXUCNKHKZFHkg== => 36584||
>>>> ||256 3 15 9SM6gMjImcK0sKPvIlEr9ZNKxsqmSL9zO7P9kZTH8XQ= => 48248||
>>>> ||257 3 15 A8W3oD5oGEkHjOTfCmPbEBzHHTILksfywXvjQ5r9/dA= => 13075||
>>>> ||257 3 13 DBT06AacWTT1cD//OgwSSNRT9UTZdAgbJOnU/sWcFYhJ+x9SHvpfZGF6 
>>>> tkGehWujsuYtwLf0aKt2b1mjQUk/BA== => 49677|
>>>>
>>>> |perl  -MNet::DNS::SEC -e'@keys = split /\n/, qx(dig +cdflag +short 
>>>> ericgermann.photography DS); print "$_ => 
>>>> ",Net::DNS::RR->new("ericgermann.photography. DS $_")->keytag,"\n" 
>>>> foreach (@keys);'||
>>>> ||22755 8 2 
>>>> 2E81A125523957ED2C3076B4E58BE159027F659D74E184E2F0B81D92 2D1E7FA9 
>>>> => *22755*||
>>>> |
>>>>
>>>> You can, of course, use data from your files instead of dig.  Works 
>>>> for both DS and DNSKEY
>>>>
>>>>  perl -MNet::DNS -MNet::DNS::SEC -e' print 
>>>> Net::DNS::RR->new("ericgermann.photography. DS 22755 8 2 
>>>> 2E81A1255ED2C3076B4E58BE159027F659D74E184E2F0B81D92 
>>>> 2D1E7FA9")->keytag,"\n"'
>>>>
>>>>
>>>> Enjoy.
>>>>
>>>> Timothe Litt
>>>> ACM Distinguished Engineer
>>>> --------------------------
>>>> This communication may not represent the ACM or my employer's views,
>>>> if any, on the matters discussed.
>>>>
>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221229/75f31974/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221229/75f31974/attachment-0001.sig>

More information about the bind-users mailing list