> On 9 Dec 2021, at 00:36, Philip Homburg wrote:
>
>> Also stop hiding this
>> breakage. Knot and unbound ignore the NSEC records which trigger
>> this when synthesising. All it does is push the problem down the
>> road and makes it harder for others to do proper synthesis based
>> on the
> Also stop hiding this
> breakage. Knot and unbound ignore the NSEC records which trigger
> this when synthesising. All it does is push the problem down the
> road and makes it harder for others to do proper synthesis based
> on the records returned.
I did some tests with unbound (version
On 30. 11. 21 19:38, John Levine wrote:
This blog post has been making the rounds. Since it is about a
sequence of DNS operational failures, it seems somewhat relevant here.
https://slack.engineering/what-happened-during-slacks-dnssec-rollout/
tl;dr first try was rolled back due to what turned
On 01. 12. 21 12:07, Tim Wicinski wrote:
What I noticed in reading this nice write up was the warning image they
missed in the Route53 console
because of the automation they use. But most folks use
automation/tooling/etc in their workflow, and
catching those warnings via automation is a bit
It appears that Viktor Dukhovni said:
>However, I do think that the skill level required need not always
>be or remain "wizard". They had some bad luck running into a not
>fully baked stack on the provider end.
While they should have caught the apex CNAME, I can't really blame
them for not
> On 1 Dec 2021, at 4:19 pm, Paul Vixie wrote:
>
> ... but if you're Slack or similar (cloud provider, ISP, MSSP, social network,
> xAAS provider), no automation will ever be good enough by itself (wizards will
> be needed.)
With that qualification, I think we're much less far apart. Yes,
the
Viktor Dukhovni wrote on 2021-12-01 13:06:
...
...
But I also don't agree with Paul that one needs to be an expert to play
the game. Tools are improving, and spinning up working DNSSEC with Knot,
BIND 9.16+, ... is increasingly easier.
...
with DNSSEC For Humans, we (ISC, at the time)
> On 1 Dec 2021, at 2:37 pm, Jim Reid wrote:
>
>> Wouldn't that create a vicious circle in which the only way to start
>> operating DNSSEC is already to have operated DNSSEC?
>
> I think we’ve been in that vicious circle (or downward spiral) for several
> years now.
The graph at:
> On 1 Dec 2021, at 18:49, Andrew Sullivan wrote:
>
> Wouldn't that create a vicious circle in which the only way to start
> operating DNSSEC is already to have operated DNSSEC?
I think we’ve been in that vicious circle (or downward spiral) for several
years now.
ObDisclaimer: work for Internet Society, speaking for me.
On Wed, Dec 01, 2021 at 01:39:19AM -0500, Viktor Dukhovni wrote:
The main advice that comes to mind is to use a DNS hosting provider
with a proven (multi-year) record of doing DNSSEC reliably.
Wouldn't that create a vicious circle in
two replies here.
Mark Andrews wrote on 2021-12-01 00:35:
Also stop hiding this breakage. Knot and unbound ignore the NSEC
records which trigger this when synthesising. All it does is push
the problem down the road and makes it harder for others to do proper
synthesis based on the records
> On 2 Dec 2021, at 01:57, Vladimír Čunát wrote:
>
> On 01/12/2021 15.49, Mark Andrews wrote:
>> Black lies is “QNAME NSEC \000.QNAME NSEC RRSIG”. There is no churn for
>> "black lies”. Black lies turns NXDOMAIN into NODATA.
>>
>> "DNS Shotgun" can produce churn of NSEC if you ask for a
On 01/12/2021 15.49, Mark Andrews wrote:
Black lies is “QNAME NSEC \000.QNAME NSEC RRSIG”. There is no churn for "black
lies”. Black lies turns NXDOMAIN into NODATA.
"DNS Shotgun" can produce churn of NSEC if you ask for a type that is listed as
existing but it doesn’t actually exist. The
> On 1 Dec 2021, at 23:57, Vladimír Čunát wrote:
>
> On 01/12/2021 13.43, Mark Andrews wrote:
>> Accepting 'QNAME NSEC \000.QNAME NSEC RRSIG’ (and other type maps) protects
>> you from random QTYPE attacks. It also makes 'black lies' work as intended.
>
> Black lies got bad caching if Knot
On 01/12/2021 13.43, Mark Andrews wrote:
Accepting 'QNAME NSEC \000.QNAME NSEC RRSIG’ (and other type maps) protects you
from random QTYPE attacks. It also makes 'black lies' work as intended.
Black lies got bad caching if Knot Resolver accepted this aggressively.
Asking two different
> On 1 Dec 2021, at 19:54, Vladimír Čunát wrote:
>
> On 01/12/2021 09.35, Mark Andrews wrote:
>> Also stop hiding this breakage. Knot and unbound ignore the NSEC records
>> which trigger this when synthesising.
>
> Knot Resolver stopped treating minimally-covering NSEC* aggressively, but
>
What I noticed in reading this nice write up was the warning image they
missed in the Route53 console
because of the automation they use. But most folks use
automation/tooling/etc in their workflow, and
catching those warnings via automation is a bit tricky.
Right after this happened several
Hi Philip,
Dne 01. 12. 21 v 11:46 Philip Homburg napsal(a):
qqq.slackexperts.com. 2370IN NSEC\000.qqq.slackexperts.com.
RRSIG NSEC
This is returned in response to a query. The intent was that the NSEC
record should have the 'A' bit as well.
What exactly do Knot and
> Also stop hiding this
> breakage. Knot and unbound ignore the NSEC records which trigger
> this when synthesising. All it does is push the problem down the
> road and makes it harder for others to do proper synthesis based
> on the records returned.
I'm confused what this means. In the report
On 01/12/2021 09.35, Mark Andrews wrote:
Also stop hiding this breakage. Knot and unbound ignore the NSEC records which
trigger this when synthesising.
Knot Resolver stopped treating minimally-covering NSEC* aggressively,
but there are *two* different reasons.
1) breakages like this. We
Also stop hiding this breakage. Knot and unbound ignore the NSEC records which
trigger this when synthesising. All it does is push the problem down the road
and makes it harder for others to do proper synthesis based on the records
returned.
--
Mark Andrews
> On 1 Dec 2021, at 18:36,
Add tests to DNSVIZ to catch this sort of error. There is an open issue for
this.
--
Mark Andrews
> On 1 Dec 2021, at 05:38, John Levine wrote:
>
> This blog post has been making the rounds. Since it is about a
> sequence of DNS operational failures, it seems somewhat relevant here.
>
>
>It is clear from the blog post that this is a fairly sophisticated
>group of ops people, who had a reasonable test plan, a bunch of test
>points set up in dnsviz and so forth. Neither of these bugs seem
>very exotic, and could have been caught by routine tests.
It not clear to whether or not
> On 30 Nov 2021, at 1:38 pm, John Levine wrote:
>
> Can or should we offer advice on how to do this better, sort of like
> RFC 8901 but one level of DNS expertise down?
The main advice that comes to mind is to use a DNS hosting provider
with a proven (multi-year) record of doing DNSSEC
This blog post has been making the rounds. Since it is about a
sequence of DNS operational failures, it seems somewhat relevant here.
https://slack.engineering/what-happened-during-slacks-dnssec-rollout/
tl;dr first try was rolled back due to what turned out to be an unrelated
failure at some
25 matches
Mail list logo
