Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2))

[bind--- via bind-users]

On Fri, Dec 30, 2022 at 12:39:30PM +0100, Peter  
wrote:

> On Thu, Dec 29, 2022 at 03:43:35PM -0500, Timothe Litt wrote:
> 
> ! So much like DNSSEC itself, the technology is there, but the will to use it
> ! everywhere it's needed is not.
> 
> Timothy, thank You for the update. I agree to Your viewpoints, and we
> have seen mostly the same with IPv6. Apparently it needs serious pain to
> move something in technology that is mostly invisible to the common
> user. (OTOH we can see new collaboration tools or javascript
> frameworks every day.)
> 
> PMc

The only hope is for the customers of domain registrars
to request that they implement this, and to cite it as
a problem when publically reviewing registrars. For
example, my registrar has their own API, but that's all.
When asked to add support for RFC7344, they say they'll
consider it. The more customers who ask for it, the
better (I hope). And now that DNSSEC is so much easier
to use than in the past, maybe more people will start
asking for RFC7344.

cheers,
raf

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)

[G.W. Haywood via bind-users]

Hi there,

On Fri, 30 Dec 2022, Timothe Litt wrote:


The problem is politics, not technology.


Well there might be a little more to it than that.  People just don't know.

When my wife asked about the security of her bank's Website they told her,

"Don't worry, if there's a little padlock in the box at the top it's secure..."

The bank is anonymous here not to protect the guilty, but to highlight
the fact that it almost doesn't matter which one you choose.

$ whois UK_bank_domain | grep DNSSEC
$

--

73,
Ged.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2))

[Peter]

On Thu, Dec 29, 2022 at 03:43:35PM -0500, Timothe Litt wrote:

! So much like DNSSEC itself, the technology is there, but the will to use it
! everywhere it's needed is not.

Timothy, thank You for the update. I agree to Your viewpoints, and we
have seen mostly the same with IPv6. Apparently it needs serious pain to
move something in technology that is mostly invisible to the common
user. (OTOH we can see new collaboration tools or javascript
frameworks every day.)

PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)

[Timothe Litt]

On 29-Dec-22 19:30, Mark Andrews wrote:
Valid base64 includes spaces and new lines. Poorly written record 
parsers reject valid records.


--
Mark Andrews



True for DNS records; the RFC clearly states that whitespace is allowed 
in the presentation form's base64 fields of DNSSEC records.  And as 
described, the AWS parser is "poorly written".


Not true in general.  In fact, the base64 RFC states the opposite.  Of 
course, confusion results.  I often wonder why so much effort goes into 
writing RFCs when so many people don't read them carefully.


gnu base64 (the command) does what engineers do when there are multiple 
interpretations - provides an option.  See man (1) base64's 
--ignore-garbage and remarks:


   The  data  are  encoded  as described for the base64 alphabet in RFC
   3548.  Decoding require compliant input by
 default, use --ignore-garbage to attempt to recover from
   non-alphabet characters  (such  as  newlines)  in  the
 encoded stream.

Sigh.


https://datatracker.ietf.org/doc/html/rfc3548#page-3

2.3 . 
Interpretation of non-alphabet characters in encoded data


   Base encodings use a specific, reduced, alphabet to encode binary
   data._Non alphabet characters could exist within base encoded data, caused by 
data corruption or by design._   Non alphabet characters may

   be exploited as a "covert channel", where non-protocol data can be
   sent for nefarious purposes.  Non alphabet characters might also be
   sent in order to exploit implementation errors leading to, e.g.,
   buffer overflow attacks.

   _Implementations MUST reject the encoding if it contains characters 
outside the base alphabet when interpreting base encoded data, unless 
the specification referring to this document explicitly states otherwise_.  Such specifications may, as MIME does, instead state that

   characters outside the base encoding alphabet should simply be
   ignored when interpreting data ("be liberal in what you accept").
   Note that this means that any CRLF constitute "non alphabet
   characters" and are ignored.  Furthermore, such specifications may
   consider the pad character, "=", as not part of the base alphabet
   until the end of the string.  If more than the allowed number of pad
   characters are found at the end of the string, e.g., a base 64 string
   terminated with "===", the excess pad characters could be ignored.




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



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)

[Timothe Litt]

On 29-Dec-22 18:37, Eric Germann wrote:
The really annoying part is it isn’t obvious that they want the public 
key and not the result of dnssec-dsfromkey; they do it themselves. 
 The annoying part is they throw an error if the key isn’t valid 
Base64 (think spaces or newlines), but gladly accept the DS output 
from dnssec-dsfromkey.  Somehow or another they are getting the key 
tag from the incorrect DS  record, because they encode again the 
already encoded string.




S_omehow or another _they are getting the key tag from the incorrect 
DS  record, because they _encode again the already encoded string_.

This isn't quite what's happening.

There is no mystery here. The DS hash data is expressed in hex. All hex 
characters are valid base64.  the DS hash is 64 characters long, which 
is a multiple of 4.  So no padding is required.  Thus, it's a valid 
string and can be decoded into 48 bytes.


The key tag is just a folded checksum 
(https://datatracker.ietf.org/doc/html/rfc2535#page-46, which doesn't 
care what data it's working on.  It's supposed to be on the KEY RR, but 
there's not much you can say about a key unless you know the type that 
determines its structure.  So its perfectly reasonable to compute it 
blindly over what data is presented.


So they _decode_ the DS HASH to binary - which will work. Apply the 
checksum, and you have a "keytag" - or something that looks like one.


By chance, DS has 4 RDATA fields: tag, alg, type, digest.  And DNSKEY 
has 4: flags, proto, alg, key.  In both cases, the first tree are 
decimal numbers.  So, they look the same to a decoder.


That said, I agree that it should be obvious what they want. E.g. put a 
sample record above the input box.  And say "KEY".  For extra credit, 
check that the length matches the key algorithm; make sure that an RSA 
key is odd (if not prime), ...


What I've seen from others is that DNSSEC is not viewed as important 
enough to merit a careful human factors design for the interfaces.  It's 
more "what's the minimum we can do to quiet those few people who insist 
on it?".    So they don't label the fields in their forms, don't provide 
meaningful help, don't advertise the capability.  And, surprise, only 
the truly motivated people use it.  And those customers are so grateful 
to have anything that no complaints are received.    Which discourages 
adoption, keeps the user base small, validates the "don't do much" 
strategy, and - catch-22, DNSSEC doesn't expand beyond the hardcore techies.


The problem is politics, not technology.


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



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)

[Mark Andrews]

Valid base64 includes spaces and new lines. Poorly written record parsers reject valid records. -- Mark AndrewsOn 30 Dec 2022, at 10:38, Eric Germann via bind-users  wrote:
On Dec 29, 2022, at 16:34, Timothe Litt  wrote:Yup, Eric's case was a classic example.  He tried to do the right
  thing, put in the wrong record, and the system didn't produce the
  expected results.  To his credit, he persisted.  Most people
  don't.  A while ago there was a study (cloudflare/APNIC)
  that showed that about only about 40% of people who enabled DNSSEC
  for their accounts successfully served DS records in their
  registry.The really annoying part is it isn’t obvious that they want the public key and not the result of dnssec-dsfromkey; they do it themselves.  The annoying part is they throw an error if the key isn’t valid Base64 (think spaces or newlines), but gladly accept the DS output from dnssec-dsfromkey.  Somehow or another they are getting the key tag from the incorrect DS  record, because they encode again the already encoded string.I looked in the docs for boto3 (the official API for AWS) and there appears no way to add a public key so you can’t do it programmatically.I’ll have to pass that on to my AWS contacts.  Doubt they’ll do anything but it is worth throwing it over the fence.Again, thanks for all the help!Eric-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users

signature.asc
Description: Binary data
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)

[Eric Germann via bind-users]

On Dec 29, 2022, at 16:34, Timothe Litt  wrote:



Yup, Eric's case was a classic example.  He tried to do the right thing, put in 
the wrong record, and the system didn't produce the expected results.  To his 
credit, he persisted.  Most people don't.  A while ago there was a study 
(cloudflare/APNIC 
) 
that showed that about only about 40% of people who enabled DNSSEC for their 
accounts successfully served DS records in their registry.



The really annoying part is it isn’t obvious that they want the public key and 
not the result of dnssec-dsfromkey; they do it themselves.  The annoying part 
is they throw an error if the key isn’t valid Base64 (think spaces or 
newlines), but gladly accept the DS output from dnssec-dsfromkey.  Somehow or 
another they are getting the key tag from the incorrect DS  record, because 
they encode again the already encoded string.

I looked in the docs for boto3 (the official API for AWS) and there appears no 
way to add a public key so you can’t do it programmatically.

I’ll have to pass that on to my AWS contacts.  Doubt they’ll do anything but it 
is worth throwing it over the fence.

Again, thanks for all the help!

Eric



signature.asc
Description: Message signed with OpenPGP
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2)) (2)

[Timothe Litt]

Apparently I didn't include the DNS script library link mentioned in my 
note.  Sorry.


https://github.com/srvrco/getssl/tree/master/dns_scripts

On 29-Dec-22 13:45, Peter wrote:


On Thu, Dec 29, 2022 at 09:17:26AM -0500, Timothe Litt wrote:

! (Manual processes
! are error-prone.  That getting registrars to adopt CDS/CDNSKEY - RFC7344 -
! has been so slow is unfortunate.)

Seconded. Do You have information about this moving at all? Because to
me it looks very much like dead-in-the-water, and my registrar didn't
even know what that is.

Otherwise I would have perfect automation for continuous rollover -
but still I have to either hack the data into their webinterface, or
figure out what kind of crappy api they might have - and in my view the
first option is boring and the second is superfluous work.

cheerio,
PMc


Yup, Eric's case was a classic example.  He tried to do the right thing, 
put in the wrong record, and the system didn't produce the expected 
results.  To his credit, he persisted.  Most people don't.  A while ago 
there was a study (cloudflare/APNIC 
) 
that showed that about only about 40% of people who enabled DNSSEC for 
their accounts successfully served DS records in their registry.


There are some registrars and registries who support CDS/CDNSKEY 
(RFC7344/8078).  Unfortunately, not enough.


I don't track it closely, but here are a few who claim support when last 
I looked.


.cz, .ch ,.li, .ne, .se, .sk

DNSSimple, domainnameshop

GoDaddy publishes CDS and CDNSKEY when it manages DNSSEC, but doesn't 
poll when delegated.  I don't think they bridge (poll & then use EPP for 
domain registries that don't poll.)


Cloudflare was an advocate, and has published for a long time. Again, 
the issue is registries.


https://github.com/oskar456/cds-updates has a list that seems more 
current.  Note that none of the big 13 are on it - .com, .net, .org, 
.info, .gov, .edu, ...


There are hybrid approaches.  Most of the registrars have some sort of 
proprietary API that allows a script to insert/delete/modify records.  
So you can let BIND generate them and script the registry updates.  But 
it's ad-hoc for each registrar.


For some idea of what a mess that is, here is a library of DNS update 
scripts for a number of registrars (used by a LetsEncrypt script, but 
the aggravation/diversity is the same).


I suspect that to get any forward progress, someone will have to come up 
with a business case that shows why the registries should take action.  
Or get ICANN to mandate it.  There are various user constituencies in 
ICANN, but that's a highly political process.


So much like DNSSEC itself, the technology is there, but the will to use 
it everywhere it's needed is not.


(I'm not involved with any of the players, aside from reviewing the RFC 
drafts.  Just an interested, and frustrated, observer.)


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




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2))

[Timothe Litt]

On 29-Dec-22 13:45, Peter wrote:

On Thu, Dec 29, 2022 at 09:17:26AM -0500, Timothe Litt wrote:

! (Manual processes
! are error-prone.  That getting registrars to adopt CDS/CDNSKEY - RFC7344 -
! has been so slow is unfortunate.)

Seconded. Do You have information about this moving at all? Because to
me it looks very much like dead-in-the-water, and my registrar didn't
even know what that is.

Otherwise I would have perfect automation for continuous rollover -
but still I have to either hack the data into their webinterface, or
figure out what kind of crappy api they might have - and in my view the
first option is boring and the second is superfluous work.

cheerio,
PMc


Yup, Eric's case was a classic example.  He tried to do the right thing, 
put in the wrong record, and the system didn't produce the expected 
results.  To his credit, he persisted.  Most people don't.  A while ago 
there was a study (cloudflare/APNIC 
) 
that showed that about only about 40% of people who enabled DNSSEC for 
their accounts successfully served DS records in their registry.


There are some registrars and registries who support CDS/CDNSKEY 
(RFC7344/8078).  Unfortunately, not enough.


I don't track it closely, but here are a few who claim support when last 
I looked.


.cz, .ch ,.li, .ne, .se, .sk

DNSSimple, domainnameshop

GoDaddy publishes CDS and CDNSKEY when it manages DNSSEC, but doesn't 
poll when delegated.  I don't think they bridge (poll & then use EPP for 
domain registries that don't poll.)


Cloudflare was an advocate, and has published for a long time. Again, 
the issue is registries.


https://github.com/oskar456/cds-updates has a list that seems more 
current.  Note that none of the big 13 are on it - .com, .net, .org, 
.info, .gov, .edu, ...


There are hybrid approaches.  Most of the registrars have some sort of 
proprietary API that allows a script to insert/delete/modify records.  
So you can let BIND generate them and script the registry updates.  But 
it's ad-hoc for each registrar.


For some idea of what a mess that is, here is a library of DNS update 
scripts for a number of registrars (used by a LetsEncrypt script, but 
the aggravation/diversity is the same).


I suspect that to get any forward progress, someone will have to come up 
with a business case that shows why the registries should take action.  
Or get ICANN to mandate it.  There are various user constituencies in 
ICANN, but that's a highly political process.


So much like DNSSEC itself, the technology is there, but the will to use 
it everywhere it's needed is not.


(I'm not involved with any of the players, aside from reviewing the RFC 
drafts.  Just an interested, and frustrated, observer.)


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




OpenPGP_signature
Description: OpenPGP digital signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RFC7344 (was: Funky Key Tag in AWS Route53 (2))

[Peter]

On Thu, Dec 29, 2022 at 09:17:26AM -0500, Timothe Litt wrote:

! (Manual processes
! are error-prone.  That getting registrars to adopt CDS/CDNSKEY - RFC7344 -
! has been so slow is unfortunate.)

Seconded. Do You have information about this moving at all? Because to
me it looks very much like dead-in-the-water, and my registrar didn't
even know what that is.

Otherwise I would have perfect automation for continuous rollover -
but still I have to either hack the data into their webinterface, or
figure out what kind of crappy api they might have - and in my view the
first option is boring and the second is superfluous work.

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Funky Key Tag in AWS Route53 (2)

[Timothe Litt]

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  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  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 

Re: Funky Key Tag in AWS Route53 (2)

[Eric Germann via bind-users]

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  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
> 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.)
> have you verified that the contents of the file that you are using matches 
> what's in the DNS?
> 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  
>>>  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 
>>> 

Re: Funky Key Tag in AWS Route53 (2)

[Timothe Litt]

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  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 

Re: Funky Key Tag in AWS Route53 (2)

[Eric Germann via bind-users]

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  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.
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Funky Key Tag in AWS Route53 (2)

[Timothe Litt]

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.





OpenPGP_signature
Description: OpenPGP digital signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Funky Key Tag in AWS Route53

[Timothe Litt]

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?



Perhaps you have TTL issues.

dnssec-dsfromkey and dnsviz are both accurate.

The keytag is visible in the DS record.  No decoding needed First field 
after "DS"|

|

|ericgermann.photography. 3600   IN  DS _22755___8 2 
2E81A125523957ED2C3076B4E58BE159027F659D74E184E2F0B81D92 2D1E7FA9||

|

See also Perl Net::DNS::SEC.  Here are some one-liners from your domain 
that print the keytag from DS and DNSKEY records.


| perl -MNet::DNS -MNet::DNS::SEC -e' print 
Net::DNS::RR->new("ericgermann.photography. DS 22755 8 2 
2E81A1255ED2C3076B4E58BE159027F659D74E184E2F0B81D92 
2D1E7FA9")->keytag,"\n"'_

22755_
|

|perl -MNet::DNS -MNet::DNS::SEC -e' print 
Net::DNS::RR->new("ericgermann.photography. DNSKEY  256 3 15 
9SM6gMjImcK0sKPvIlEr9ZNKxsqmSL9zO7P9kZTH8XQ=")->keytag,"\n"'||

|_|48248|_|
|

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



OpenPGP_signature
Description: OpenPGP digital signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Funky Key Tag in AWS Route53

[Eric Germann via bind-users]

I’m running bind 9.18.10 and having a hell of a time with AWS Route53 and 
DNSSEC.

I’m testing dnssec-policy and have algorithms 8, 13, and 15 set.  On the test 
domain I’m using, I wiped the old keys, deleted the DS records in the parent 
zone and basically started from scratch.

I started named and it created new .key/.private files in the key directory.  
My KSK is Kericgermann.photography.+008+32686.key and I run dnssec-dsfromkey 
and get a DS record.  I cut and paste that record in to Route53 DNSSEC config 
and it decodes the key tag as 22755 instead of 32686.

I get a DNSviz diagram that looks like this 
https://dnsviz.net/d/ericgermann.photography/dnssec/

In the diagram, .photography is looking for a key tag of 22755 instead of the 
correct 32686 for algorithm 8.

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?


--
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Medium: https://ekgermann.medium.com 
Twitter: @ekgermann
Telegram || Signal || Skype || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1









signature.asc
Description: Message signed with OpenPGP
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users