--- Begin Message ---
On 18/07/2023 23.53, Viktor Dukhovni wrote:
On Tue, Jul 18, 2023 at 10:25:01PM +0200, Ondřej Surý wrote:
It’s exactly like the serve-stale. The inception of the protocol
change is driven by this isolated incident. That’s not a proper
design, that’s slapping more bandaids on
--- Begin Message ---
Ondřej Surý wrote on 2023-07-18 13:25:
...
There’s already mechanism for not serving a stale RRSIGs. The EXPIRE field in
the SOA record should be set to a value that’s lower than the RRSIG resigning
interval (the minimal interval between now and shortest RRSIG expiry in
Thanks Mark for the clarification.
I just hate adding new knobs and exceptions in a scramble mode. If the knob is
already there then it’s already there.
There’s already too many knobs in DNS and we all know that.
--
Ondřej Surý (He/Him)
> On 19. 7. 2023, at 0:43, Mark Andrews wrote:
>
> Ex
On Tue, Jul 18, 2023, 3:47 PM Mark Andrews wrote:
>
>
> If you have stale DS’s then you will get validation failures if the child
> zone had already remove the DNSKEYs those DS refer to.
>
The second level domain in question didn't have a DS at all. The problem,
as far as I could tell, was tha
> On 19 Jul 2023, at 05:51, Gavin McCullagh wrote:
>
>
>
> On Tue, Jul 18, 2023 at 12:45 PM Shumon Huque wrote:
> Yes, I agree. A resolver can't really tell that a response with an expired
> signature wasn't an attacker trying to replay old data. For robustness
> against attacks, it must r
Except BIND does exactly this. It retries and if all the servers for the zone
fail the is flagged as bad for 10 minutes and any validation that
depends on that lookup fails with DNS_R_BROKENCHAIN which results in SERVFAIL
rather than a retry. This was how we dealt with the so called “rollover
On Tue, Jul 18, 2023 at 10:25:01PM +0200, Ondřej Surý wrote:
> It’s exactly like the serve-stale. The inception of the protocol
> change is driven by this isolated incident. That’s not a proper
> design, that’s slapping more bandaids on the camel.
I don't even see a "protocol change" here. A bog
It’s exactly like the serve-stale. The inception of the protocol change is
driven by this isolated incident. That’s not a proper design, that’s slapping
more bandaids on the camel.
There’s already mechanism for not serving a stale RRSIGs. The EXPIRE field in
the SOA record should be set to a va
--- Begin Message ---
On Tue, Jul 18, 2023 at 7:53 PM Gavin McCullagh wrote:
> On Tue, Jul 18, 2023 at 12:45 PM Shumon Huque wrote:
>> Yes, I agree. A resolver can't really tell that a response with an expired
>> signature wasn't an attacker trying to replay old data. For robustness
>> against
On Tue, Jul 18, 2023 at 12:51:39PM -0700, Gavin McCullagh wrote:
> We definitely saw Unbound returning SERVFAIL for unsigned com domains
> though.
Failures for even for some "unsigned" domains were to be expected if
retries were either not happening or the retry count was at times
exceeded.
The
On Tue, Jul 18, 2023 at 07:38:51PM +, Matt Nordhoff via dns-operations
wrote:
> ³ Actually the xn--wgbh1c TLD is broken right now but I haven't told anyone.
Well, at least that IDN ccTLD (Egypt, "dotmasr") is broken for all
servers.
Nice to see a rollover in progress to algorithm 13, but of
On Tue, Jul 18, 2023 at 12:45 PM Shumon Huque wrote:
> Yes, I agree. A resolver can't really tell that a response with an expired
> signature wasn't an attacker trying to replay old data. For robustness
> against attacks, it must re-query other available other servers if they
> exist.
>
> Also, I
On Tue, Jul 18, 2023 at 3:29 PM Viktor Dukhovni
wrote:
> On Tue, Jul 18, 2023 at 08:54:04PM +0200, Ondřej Surý wrote:
>
> > With my implementor’s hat on, I think this is wrong approach. It
> > (again) adds a complexity to the resolvers and yet again based
> > (mostly) on isolated incident. I real
--- Begin Message ---
On Tue, Jul 18, 2023 at 6:21 PM Gavin McCullagh wrote:
> Hi,
>
> sorry to dredge this back up, but I just want to give anyone the chance to
> object.
>
> My read of what Viktor and others have indicated here is that, when a
> validating resolver receives a response with exp
--- Begin Message ---
i have two comments here.
Ondřej Surý wrote on 2023-07-18 11:54:
With my implementor’s hat on, I think this is wrong approach. It (again) adds a
complexity to the resolvers and yet again based (mostly) on isolated incident.
I really don’t want yet another “serve-stale” in
On Tue, Jul 18, 2023 at 08:54:04PM +0200, Ondřej Surý wrote:
> With my implementor’s hat on, I think this is wrong approach. It
> (again) adds a complexity to the resolvers and yet again based
> (mostly) on isolated incident. I really don’t want yet another
> “serve-stale” in the resolvers. I have
With my implementor’s hat on, I think this is wrong approach. It (again) adds a
complexity to the resolvers and yet again based (mostly) on isolated incident.
I really don’t want yet another “serve-stale” in the resolvers. I have to yet
see an evidence that serve-stale has helped anything since
Hi,
sorry to dredge this back up, but I just want to give anyone the chance to
object.
My read of what Viktor and others have indicated here is that, when a
validating resolver receives a response with expired rrsigs, it's okay (and
encouraged?) for that resolver to treat that as an invalid respo
18 matches
Mail list logo
