>… I do want to point out that Compact DoE handles wildcards quite differently,
>and this may not be readily apparent to the casual observer.
FWIW, I noticed. (Not meaning to say “I’m not a casual observer” but…). This
is something that was playing in my mind when reviewing the proposal.
In
On Tue, Aug 8, 2023 at 9:13 AM Edward Lewis wrote:
> On Mon, Jul 31, 2023 at 11:58 AM Edward Lewis
> wrote:
>
> >You've probably stumbled across Cloudflare's differential behavior for
> DO=0 vs
>
> >DO=1 queries. With non-DNSSEC queries it provides a vanilla, unsigned
>
> >NXDOMAIN response.
On Wed, Jul 26, 2023 at 11:05 PM Edward Lewis
wrote:
> [...]
> In some sense, this proposal is establishing a (set of) wildcard(s)
> (source[s] of synthesis) that owns just an NSEC record when it applies to
> otherwise NXDOMAIN responses. Mulling this over, it becomes apparent that
> the next
On Tue, Aug 8, 2023 at 9:21 AM Edward Lewis wrote:
> >Compact DoE, and RFC4470 already appear to violate it for ENT responses.
> And it was (arguably) already violated by
>
> >pre-computed NSEC3 (5155), where an empty non-terminal name (or rather
> the hash of it) does solely own an
>
> >NSEC3
>Compact DoE, and RFC4470 already appear to violate it for ENT responses. And
>it was (arguably) already violated by
>pre-computed NSEC3 (5155), where an empty non-terminal name (or rather the
>hash of it) does solely own an
>NSEC3 record.
NSEC3 is different. Because NSEC3 hashes the labels
On Mon, Jul 31, 2023 at 11:58 AM Edward Lewis
mailto:edward.le...@icann.org>> wrote:
>You've probably stumbled across Cloudflare's differential behavior for DO=0 vs
>DO=1 queries. With non-DNSSEC queries it provides a vanilla, unsigned
>NXDOMAIN response. With DNSSEC enabled queries, it provides
> On 8 Aug 2023, at 11:27, Shumon Huque wrote:
>
> On Mon, Aug 7, 2023 at 9:20 PM Mark Andrews wrote:
>
> You can’t query for NSEC3 records. NSEC3 names do not prevent wildcard
> matches nor are NSEC3 records or their RRSIGs returned for * queries at the
> hashed name. They are pure
On Mon, Aug 7, 2023 at 9:20 PM Mark Andrews wrote:
>
> You can’t query for NSEC3 records. NSEC3 names do not prevent wildcard
> matches nor are NSEC3 records or their RRSIGs returned for * queries at the
> hashed name. They are pure metadata. NSEC3 records and their RRSIGs exist
> in their
> On 8 Aug 2023, at 10:58, Shumon Huque wrote:
>
> On Wed, Jul 26, 2023 at 11:05 PM Edward Lewis wrote:
> On 7/24/23, 1:55 PM, "DNSOP on behalf of Viktor Dukhovni"
> wrote:
> >2. That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN
> >responses:
> >
> >
On Mon, Jul 31, 2023 at 11:58 AM Edward Lewis
wrote:
>
> E.g., while preparing this message I tried these two dig messages:
>
> dig somename.cloudflare.com a @ns3.cloudflare.com.
> and
> dig somename.cloudflare.com a
>
> The first returned NXDOMAIN, the later NoError/NoData. If I were a human
>
On Wed, Jul 26, 2023 at 11:05 PM Edward Lewis
wrote:
> On 7/24/23, 1:55 PM, "DNSOP on behalf of Viktor Dukhovni" <
> dnsop-boun...@ietf.org on behalf of ietf-d...@dukhovni.org> wrote:
> >2. That said, there are multiple ways to *distinguish* ENT vs.
> NXDOMAIN
> >responses:
> >
> >
On 7/28/23, 1:48 PM, "DNSOP on behalf of Viktor Dukhovni"
wrote:
>We rolled out NSEC3 by introducing new algorithm code points, and
>eventually these weere widely enough deployed to allow zones to be
>signed with 7/8/10/13/14 without being seen as insecure by a significant
>
On Thu, Jul 27, 2023 at 03:04:37AM +, Edward Lewis wrote:
> >2. That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN
> >responses:
> >
> >a. Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for ENT.
> >b. Sentinel RTYPE for ENT with
On 7/24/23, 1:55 PM, "DNSOP on behalf of Viktor Dukhovni"
wrote:
>2. That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN
>responses:
>
>a. Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for ENT.
>b. Sentinel RTYPE for ENT with just NSEC
14 matches
Mail list logo
