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
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
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
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
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
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
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
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
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?
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
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
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
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,
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
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
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
17 matches
Mail list logo
