Christian Elmerot wrote on 2023-03-29 08:24:
On 2023-03-29 15:45, Paul Vixie wrote:
however, olafur's original CF blog post about CDoE also talked about
packet size (desiring explicitly to fit in 512b). justification was
about fragmentation avoidance, not CPU time needed to construct
On 2023-03-29 15:45, Paul Vixie wrote:
Joe Abley wrote on 2023-03-29 01:56:
Hi Paul,
On Tue, Mar 28, 2023 at 14:51, Paul Vixie
... for perspective, no root name
server has deployed this alternative form of Denial of Existence, ...
Root servers don't do online signing; they serve a
Joe Abley wrote on 2023-03-29 01:56:
Hi Paul,
On Tue, Mar 28, 2023 at 14:51, Paul Vixie
... for perspective, no root name
server has deployed this alternative form of Denial of Existence, ...
Root servers don't do online signing; they serve a pre-signed zone. They
don't have a
Hi Paul,
On Tue, Mar 28, 2023 at 14:51, Paul Vixie
wrote:
> Viktor Dukhovni wrote on 2023-03-27 18:00:
>>
>> * How compelling is compact DoE?
>
> that may depend on the beholder's eye. for perspective, no root name
> server has deployed this alternative form of Denial of Existence, and i
>
On 2023-03-28 05:51 -07, Paul Vixie wrote:
> see inline.
>
> Viktor Dukhovni wrote on 2023-03-27 18:00:
>> [ Multi-response to four upthread messages. ]
>> ---
>> ...
>> A possibly inconvenient question, just to make sure we're not
>> ignoring
>> the obvious sceptical position:
>> * How
On 2023-03-28 06:41, Shumon Huque wrote:
On Tue, Mar 28, 2023 at 10:01 AM Viktor Dukhovni
wrote:
[ Multi-response to four upthread messages. ]
---
On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote:
> Thanks for your comments. We've posted an updated draft
see inline.
Viktor Dukhovni wrote on 2023-03-27 18:00:
[ Multi-response to four upthread messages. ]
---
...
A possibly inconvenient question, just to make sure we're not ignoring
the obvious sceptical position:
* How compelling is compact DoE?
that may depend on the beholder's eye.
On Tue, Mar 28, 2023 at 10:01 AM Viktor Dukhovni
wrote:
>
> On Wed, Mar 15, 2023 at 08:48:29AM -0400, Shumon Huque wrote:
>
> > So, if a resolver sends EDNS CompactAnswersOK signal to an authority
> > server, which returns a NODATA+NXNAME proof + RCODE=3 response, then the
> > resolver would
On Tue, Mar 28, 2023 at 10:01 AM Viktor Dukhovni
wrote:
> [ Multi-response to four upthread messages. ]
>
> ---
>
> On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote:
>
> > Thanks for your comments. We've posted an updated draft (-01):
> >
> >
>
[ Multi-response to four upthread messages. ]
---
On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote:
> Thanks for your comments. We've posted an updated draft (-01):
>
> https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01
[ Copied from today's
On 3/15/23 13:48, Shumon Huque wrote:
So, if a resolver sends EDNS CompactAnswersOK signal to an authority server,
which returns a NODATA+NXNAME proof + RCODE=3 response, then the resolver would
have to intelligently manage that answer in its cache. To downstream DO=1
queriers that also set
I think it's worth taking a step back though and asking a larger question:
if we are restoring the NXDOMAIN signal with the NXNAME pseudo type in the
NSEC record of NODATA responses, why do we also need to restore NXDOMAIN
into the RCODE field?
Because a bazillion existing clients expect to
Hi Shumon,
> Currently, the focus of this draft is to more surgically deal with NXDOMAIN
> visibility in Compact Answers (formerly Black Lies). Most customers of these
> implementations today are enterprises, application service providers, and
> other non-TLDs that appear to be comfortable
Thanks Johan for bringing up this topic.
Currently, the focus of this draft is to more surgically deal with NXDOMAIN
visibility in Compact Answers (formerly Black Lies). Most customers of
these implementations today are enterprises, application service providers,
and other non-TLDs that appear to
-
> From: Shumon Huque
> Date: 3/15/23 09:18 (GMT-05:00)
> To: John Levine
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] Updated: Compact Denial of Existence
>
> Only for Compact Answers, otherwise downstream validators may treat the
> response as unvalidatable because the
Subject: Re: [DNSOP] Updated: Compact Denial of Existence Only
for Compact Answers, otherwise downstream validators may treat the response as
unvalidatable because the rcode doesn't match the DNSSEC proof. So, I actually
see this is unbreaking things.I think it's worth taking a step back though
Hi Shumon and Christian,
As one of the authors of RFC 4470 I most certainly care about this topic.
However, to my mind the major issue isn’t so much optimising the amount of work
done at the edge when generating the negative response. Nor is it the size of
the response. Instead my view is
0)
> To: Ralf Weber
> Cc: John R Levine , dnsop@ietf.org, pe...@desec.io
> Subject: Re: [DNSOP] Updated: Compact Denial of Existence
>
>>
>>
> Precisely, but it can still work if the signal is used in a hop by hop
> fashion.
>
> So, if a resolver sends EDNS Com
Subject: Re: [DNSOP] Updated:
Compact Denial of Existence Precisely, but it can still work if the signal is
used in a hop by hop fashion.So, if a resolver sends EDNS CompactAnswersOK
signal to an authority server, which returns a NODATA+NXNAME proof + RCODE=3
response, then the resolver would have
On Wed, Mar 15, 2023 at 2:01 AM Ralf Weber wrote:
> Moin!
>
> On 14 Mar 2023, at 22:57, John R Levine wrote:
>
> >> John it won’t work with chained validators.
> >
> > How about if I only send a "lie to me" option upstream if I get one from
> my client? I realize this means takeup will be
Moin!
On 14 Mar 2023, at 22:57, John R Levine wrote:
>> John it won’t work with chained validators.
>
> How about if I only send a "lie to me" option upstream if I get one from my
> client? I realize this means takeup will be pretty slow.
Clients have no control over what a resolver does
John it won’t work with chained validators.
How about if I only send a "lie to me" option upstream if I get one from
my client? I realize this means takeup will be pretty slow.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before
John it won’t work with chained validators.
--
Mark Andrews
> On 15 Mar 2023, at 07:59, John Levine wrote:
>
> It appears that Peter Thomassen said:
>> So I take it that when the EDNS signal is there, compact DoE responses get
>> an NXDOMAIN code.
>>
>> In case the EDNS flag is not set,
It appears that Peter Thomassen said:
>So I take it that when the EDNS signal is there, compact DoE responses get an
>NXDOMAIN code.
>
>In case the EDNS flag is not set, does the nameserver return (a) the compact
>proof (with sentinel in
>the type map) is sent, but with a NOERROR code, or (b)
On 3/14/23 17:05, Shumon Huque wrote:
The NXDOMAIN or NOERROR "state" definitely has to be proven by the signed
records inside the message.
(...)
So, I think the only way we could safely do RCODE replacement for signed
responses is by the use of an EDNS signal.
I'd like to understand
Shumon Huque wrote on 2023-03-14 09:05:
...
So, I think the only way we could safely do RCODE replacement for signed
responses is by the use of an EDNS signal.
sadly, +1.
--
P Vixie
___
DNSOP mailing list
DNSOP@ietf.org
On Sun, Mar 12, 2023 at 6:03 AM Vladimír Čunát
wrote:
> On 06/03/2023 03.35, Shumon Huque wrote:
>
> I suspect that unilaterally putting NXDOMAIN into the rcode field will
> break a lot of validator code. They are likely to use the rcode to advise
> them on what type of proof to look for in the
On 06/03/2023 03.35, Shumon Huque wrote:
I suspect that unilaterally putting NXDOMAIN into the rcode field will
break a lot of validator code. They are likely to use the rcode to
advise them on what type of proof to look for in the message body, and
they won't find a traditional NXDOMAIN
On Mon, Mar 6, 2023 at 5:13 PM John Levine wrote:
> It seems like a poor economy. If you really are worried about making the
> bitmap smaller, I suppose there's unused type 54.
Without advocating for that, I wanted to explore this a bit. Does anyone
know
why it is unassigned? Is there any
On Tue, Mar 7, 2023 at 7:34 PM Mark Andrews wrote:
>
> > On 8 Mar 2023, at 11:16, Evan Hunt wrote:
> >
> > On Tue, Mar 07, 2023 at 11:15:55AM +0100, Peter Thomassen wrote:
> >> Oops, touché! I stand corrected. Thanks, Mark.
> >>
> >> What I meant is rrtype 0. I used the wrong mnemonic.*
> >
> >
> On 8 Mar 2023, at 11:16, Evan Hunt wrote:
>
> On Tue, Mar 07, 2023 at 11:15:55AM +0100, Peter Thomassen wrote:
>> Oops, touché! I stand corrected. Thanks, Mark.
>>
>> What I meant is rrtype 0. I used the wrong mnemonic.*
>
> IMHO, you're almost definitely correct that NULL (type 10) would
On Tue, Mar 07, 2023 at 11:15:55AM +0100, Peter Thomassen wrote:
> Oops, touché! I stand corrected. Thanks, Mark.
>
> What I meant is rrtype 0. I used the wrong mnemonic.*
IMHO, you're almost definitely correct that NULL (type 10) would be safe to
use for this. Type 0, thought, would not - it's
It appears that Peter Thomassen said:
>It seems that this perspective is generally shared, as nobody seems to have a
>fundamental problem with changing the semantics
>of NODATA and essentially abandoning NXDOMAIN (for "do" queries).
The reason nobody's arguing is that we resolved that issue
<>
Raises hand.
I object to any weakening of the nxdomain signal, which must continue to be
district from nodata.
p vixie
On Mar 7, 2023 02:16, Peter Thomassen wrote:
On 3/7/23 01:26, Mark Andrews wrote:
>> 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the
On 3/7/23 01:26, Mark Andrews wrote:
2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL type). So far it only
has meaning for "type covered" fields in signature records such as SIG(0) (RFC 2931). There appears
to be no collision with usage in the NSEC type bitmap,
> On 6 Mar 2023, at 04:20, Peter Thomassen wrote:
>
> 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL
> type). So far it only has meaning for "type covered" fields in signature
> records such as SIG(0) (RFC 2931). There appears to be no collision with
> usage
It appears that Peter Thomassen said:
>> It will require more process work (potentially blocking) to revise other
>> documents too.
>
>I checked before proposing it, and couldn't find anything that would need
>revision. RFC 1035 calls that type experimental, no
>NULL RRs allowed in zone file,
It appears that Shumon Huque said:
>2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 ...
>> If I didn't get the math wrong, it would also save 11 bytes in the type
>> bitmap (compared to using the lowest available meta type code, 128),
>> slightly reducing the chance of packet
On 2023-03-06 03:35, Shumon Huque wrote:
On Sun, Mar 5, 2023 at 12:20 PM Peter Thomassen wrote:
Hi,
I like this draft. Some thoughts:
1.) Maybe it's worth pointing out that zones using compact denial
SHOULD (MUST?) use NSEC, not NSEC3.
Yes, we could do that. I agree with
On 3/6/23 03:35, Shumon Huque wrote:
2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL type). So far it
only has meaning for "type covered" fields in signature records such as SIG(0) (RFC 2931). There
appears to be no collision with usage in the NSEC type
On 2023-03-06 05:00, Paul Vixie wrote:
Peter Thomassen wrote on 2023-03-05 14:56:
(Compact NSEC answers prevent zone enumeration just as well, if not
better.)
that makes it even cooler, and it was already cool. (so long as the
nxdomain signal is not suppressed as in the cloudflare
Peter Thomassen wrote on 2023-03-05 14:56:
(Compact NSEC answers prevent zone enumeration just as well, if not better.)
that makes it even cooler, and it was already cool. (so long as the
nxdomain signal is not suppressed as in the cloudflare prototype.)
--
P Vixie
On Fri, Mar 3, 2023 at 6:23 PM Shumon Huque wrote:
> Thanks for your comments. We've posted an updated draft (-01):
>
> https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01
>
I wanted to mention that I had an off list exchange with Paul Vixie over
the weekend about this
On Sun, Mar 5, 2023 at 12:20 PM Peter Thomassen wrote:
> Hi,
>
> I like this draft. Some thoughts:
>
> 1.) Maybe it's worth pointing out that zones using compact denial SHOULD
> (MUST?) use NSEC, not NSEC3.
>
Yes, we could do that. I agree with Geoff's later point that this mechanism
could in
On 3/6/23 02:08, John Levine wrote:
The introduction does mention NSEC3.
Fair enough!
The mention is not part of the compact DoE description, though. It only adds
context on how non-compact DoE causes enlarged responses and extra
computational load, and is otherwise unrelated to the
It appears that Peter Thomassen said:
>I suspect it is intentional, because there seems little value in jumping
>through the NSEC3 extra hoops like hashing and
>dealing with NSEC3PARAM when you don't get any of the benefit NSEC3 was
>designed for. (Compact NSEC answers prevent zone
On 3/5/23 23:17, Geoff Huston wrote:
1.) Maybe it's worth pointing out that zones using compact denial SHOULD
(MUST?) use NSEC, not NSEC3.
Could you please explain your thinking here? In the same way that the ‘compact'
NSEC record specifies a minimal span of non-existence across the
> On 6 Mar 2023, at 4:20 am, Peter Thomassen wrote:
>
> Hi,
>
> I like this draft. Some thoughts:
>
>
> 1.) Maybe it's worth pointing out that zones using compact denial SHOULD
> (MUST?) use NSEC, not NSEC3.
>
Could you please explain your thinking here? In the same way that the
Given that we just abandoned the "lie" moniker, I forgot to mention that
Resource Record type to signal the presence of a non-existent name
is my favorite sentence in the draft ;-)
Cheers,
Peter
On 3/5/23 18:20, Peter Thomassen wrote:
Hi,
I like this draft. Some thoughts:
1.)
Hi,
I like this draft. Some thoughts:
1.) Maybe it's worth pointing out that zones using compact denial SHOULD
(MUST?) use NSEC, not NSEC3.
2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0 (the NULL type). So far it only
has meaning for "type covered" fields in signature
Thanks for your comments. We've posted an updated draft (-01):
https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01
Some smaller updates:
* Remove the "Lies" moniker. We now refer to this mechanism as just
Compact Denial of Existence, or Compact Answers if you prefer
51 matches
Mail list logo
