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
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 o
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
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'
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-se
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
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
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
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 r
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/
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,
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 accep
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 a
13 matches
Mail list logo
