Not really. Using ECDSA (or EdDSA) CSK is pretty lightweight even during
rollover.
Ondrej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 3. 8. 2022, at 19:10, Peter wrote:
>
I generally agree with you - comments in line
On 8/3/22 5:56 PM, Peter wrote:
I see a two-fold issue with DNSSEC:
1. The wide-spread tutorials seem to explain a key rollover as an
exceptional activity, a *change* that is infrequently done. And
changes, specifically the infrequent ones,
I see a two-fold issue with DNSSEC:
1. The wide-spread tutorials seem to explain a key rollover as an
exceptional activity, a *change* that is infrequently done. And
changes, specifically the infrequent ones, bring along the
possibility of failure, mostly due to human error.
I don't s
> One more thing should *in theory* not matter much. Personally, I'm not too
> happy about short TTLs. This trend is likely significantly undermining the
> stability and redundancy of the internet as a whole already.
In the days of limited, expensive hardware and slow links, long TTLs made
sens
Am 2022-08-03 15:27, schrieb Bob Harold:
I think the best way to soften the effect, and make DNSSEC much less
brittle, without losing any of the security, is to reduce the TTL of
the DS record in the parent zone (usually TLD's) drastically - from 2
days to like 30 minutes. That allows quick reco
On 03-Aug-22 09:27, Bob Harold wrote:
I think the best way to soften the effect, and make DNSSEC much less
brittle, without losing any of the security, is to reduce the TTL of
the DS record in the parent zone (usually TLD's) drastically - from 2
days to like 30 minutes. That allows quick reco
I think the best way to soften the effect, and make DNSSEC much less
brittle, without losing any of the security, is to reduce the TTL of the DS
record in the parent zone (usually TLD's) drastically - from 2 days to like
30 minutes. That allows quick recovery from a failure. I realize that
will c
On 02-Aug-22 13:51, Brown, William wrote:
my guess is that they see dnssec as fragile, have not seen _costly_
dns subversion, and measure a dns outages in thousands of dollars a
minute.
No one wants to be this guy:
http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201
18_FINA
On 8/2/22 11:51 AM, Brown, William wrote:
Or perhaps some way of the client side deciding how to handle hard v./
soft failure.
Wouldn't this require the client side being aware of DNSSEC and making
decision based on it?
Maybe it's just me, but I think client application side DNSSEC
validati
>>> my guess is that they see dnssec as fragile, have not seen _costly_
>>> dns subversion, and measure a dns outages in thousands of dollars a
>>> minute.
>> No one wants to be this guy:
>> http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_201201
>> 18_FINAL.pdf
>so, to me, a cru
>> my guess is that they see dnssec as fragile, have not seen _costly_
>> dns subversion, and measure a dns outages in thousands of dollars a
>> minute.
> No one wants to be this guy:
> http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf
so, to me, a crucial question
> my guess is that they see dnssec as fragile, have not seen _costly_ dns
> subversion, and measure a dns outages in thousands of dollars a minute.
>randy
No one wants to be this guy:
http://www.dnssec.comcast.net/DNSSEC_Validation_Failure_NASAGOV_20120118_FINAL.pdf
Confidentiality Notice: T
> TLD Signed? Comments
> -----
> google.comno
> gmail.com no
> youtube.com no
> apple.com no
> microsoft.com no
> amazon.comno
> walmart.com no
> outlook.com no
> 1e100.net no
> facebook.com no
> twitter.com no
> instagram.com
13 matches
Mail list logo
