[DNSOP] Updated: Compact Denial of Existence
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 pithy. (Renaming the draft filename is too much work - we'll do that if/when the WG adopts this.) * Move the various types of responses into subsections and provide an expanded treatment of them. * Update the operational implications section with the observation by Paul Vixie that this can cause additional queries from name lookup functions/methods. But the main change is to move from the ENT distinguisher RR type to an explicit one for NXDOMAIN (with mnemonic NXNAME). When I originally devised the ENT distinguisher, it was because we could use the same type bitmap pattern (NSEC RRSIG) to identify NXDOMAIN at those implementations and also at other implementations like Cloudflare that used a broad bit pattern of many types in ENT responses. Secondarily, I thought this would cause less work at servers since ENTs are far less common than NXDOMAIN (but that is likely just in the noise compared to the crypto work to generate the response). After chatting this through with Christian/Cloudflare, we've now agreed that a precise distinguisher for NXDOMAIN is better. We hope others will also agree. There are more details in Section 2. Cloudflare colleagues also have an interest in using the NXDOMAIN signal to allow resolvers to modify the response code from NOERROR to NXDOMAIN back to non-validating clients. I'm not yet persuaded that this is worth doing, but the draft enables that. Ultimately, if all client systems run validating stubs/resolvers, they will need to fully authenticate the contents of the DNS message (the RCODE is then merely a hint for what to look for, and not essential to that task). Shumon ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 records such as SIG(0) (RFC 2931). There appears
to be no collision with usage in the NSEC type bitmap, and IMHO it appears to be a very natural meta type
fit. ("This is NULL, There Really Is Nothing Underneath.")
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 size issues e.g. when double-signing etc.
(The type bitmap is zero-indexed and its size governed by the highest code in
the map. Sentinel 128 thus requires 17 bytes. With sentinel 0, NSEC is the
largest, which needs only 6 bytes.)
[One could ponder defining that NXDOMAIN is indicated with a type bitmap that
has *only* the sentinel in it, or even an empty bitmap. There would be no
information loss, as a validator already knows about the NSEC (+ RRSIG)
record's existence simply by looking at them; the type map adds nothing at all.
The idea is only semi-serious (because of its risk to cause confusion). I'm
bringing it up only to observe that such an empty bitmap would require no
sentinel type at all!]
3.) Section 2:
An alternative way to distinguish NXDOMAIN from ENT is to define the
synthetic Resource Record type for ENTs instead, as specified in
[ENT-SENTINEL], and this has already been deployed in the field. This
typically imposes less work on the server since NXDOMAIN responses
are a lot more common than ENTs.
It's likely I'm missing something, but I'm not following. Here's my line of
thinking:
Constructing the NODATA response for a name without data records requires
checking whether the name is an ENT. Depending on the outcome, a bit is
set/unset. How can inverting the condition affect the amount of work on the
server?
4.) Section 4:
A signed zone at an authoritative server implementing Compact Answers
will never return a response with a response code of NXDOMAIN.
Is this meant literally, or only for queries with "do" flag?
For responses to queries without "do" flag, there is no DoE processing. To
preserve the DoE information, the return code fur such responses should IMO continue to
be NXDOMAIN.
If the return code is not allowed to depend on the "do" flag, it may be better to return
NXDOMAIN even to "do" queries, in combination with the Compact Denial NSEC record. The
draft correctly says that it is not authenticated, but retaining it probably wouldn't hurt.
Peter
On 3/4/23 00:23, 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
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 pithy.
(Renaming the draft filename is too much work - we'll do that if/when
the WG adopts this.)
* Move the various types of responses into subsections and provide
an expanded treatment of them.
* Update the operational implications section with the observation
by Paul Vixie that this can cause additional queries from name
lookup functions/methods.
But the main change is to move from the ENT distinguisher RR type
to an explicit one for NXDOMAIN (with mnemonic NXNAME).
When I originally devised the ENT distinguisher, it was because
we could use the same type bitmap pattern (NSEC RRSIG) to identify
NXDOMAIN at those implementations and also at other implementations
like Cloudflare that used a broad bit pattern of many types in ENT
responses. Secondarily, I thought this would cause less work at servers
since ENTs are far less common than NXDOMAIN (but that is likely just
in the noise compared to the crypto work to generate the response).
After chatting this through with Christian/Cloudflare, we've now
agreed that a precise distinguisher for NXDOMAIN is better. We hope
others will also agree. There are more details in Section 2.
Cloudflare colleagues also have an interest in using the NXDOMAIN
signal to allow resolvers to modify the response code from NOERROR
to NXDOMAIN back to non-validating clients. I'm not yet persuaded
that this is worth doing, but the draft enables that. Ultimately, if all
client systems run validating stubs/resolvers, they will need to fully
authenticate the contents of the DNS message (the RCODE is then
merely a hint for what to look for, and not essential to that task).
Shumon
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
Like our community service
Re: [DNSOP] Updated: Compact Denial of Existence
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.) 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 records such as SIG(0) (RFC 2931). There appears
to be no collision with usage in the NSEC type bitmap, and IMHO it appears to be a very natural meta type
fit. ("This is NULL, There Really Is Nothing Underneath.")
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 size issues e.g. when double-signing etc.
(The type bitmap is zero-indexed and its size governed by the highest code in
the map. Sentinel 128 thus requires 17 bytes. With sentinel 0, NSEC is the
largest, which needs only 6 bytes.)
[One could ponder defining that NXDOMAIN is indicated with a type bitmap that
has *only* the sentinel in it, or even an empty bitmap. There would be no
information loss, as a validator already knows about the NSEC (+ RRSIG)
record's existence simply by looking at them; the type map adds nothing at all.
The idea is only semi-serious (because of its risk to cause confusion). I'm
bringing it up only to observe that such an empty bitmap would require no
sentinel type at all!]
3.) Section 2:
An alternative way to distinguish NXDOMAIN from ENT is to define the
synthetic Resource Record type for ENTs instead, as specified in
[ENT-SENTINEL], and this has already been deployed in the field. This
typically imposes less work on the server since NXDOMAIN responses
are a lot more common than ENTs.
It's likely I'm missing something, but I'm not following. Here's my line of
thinking:
Constructing the NODATA response for a name without data records requires
checking whether the name is an ENT. Depending on the outcome, a bit is
set/unset. How can inverting the condition affect the amount of work on the
server?
4.) Section 4:
A signed zone at an authoritative server implementing Compact Answers
will never return a response with a response code of NXDOMAIN.
Is this meant literally, or only for queries with "do" flag?
For responses to queries without "do" flag, there is no DoE processing. To
preserve the DoE information, the return code fur such responses should IMO continue to
be NXDOMAIN.
If the return code is not allowed to depend on the "do" flag, it may be better to return
NXDOMAIN even to "do" queries, in combination with the Compact Denial NSEC record. The
draft correctly says that it is not authenticated, but retaining it probably wouldn't hurt.
Peter
On 3/4/23 00:23, 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
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 pithy.
(Renaming the draft filename is too much work - we'll do that if/when
the WG adopts this.)
* Move the various types of responses into subsections and provide
an expanded treatment of them.
* Update the operational implications section with the observation
by Paul Vixie that this can cause additional queries from name
lookup functions/methods.
But the main change is to move from the ENT distinguisher RR type
to an explicit one for NXDOMAIN (with mnemonic NXNAME).
When I originally devised the ENT distinguisher, it was because
we could use the same type bitmap pattern (NSEC RRSIG) to identify
NXDOMAIN at those implementations and also at other implementations
like Cloudflare that used a broad bit pattern of many types in ENT
responses. Secondarily, I thought this would cause less work at servers
since ENTs are far less common than NXDOMAIN (but that is likely just
in the noise compared to the crypto work to generate the response).
After chatting this through with Christian/Cloudflare, we've now
agreed that a precise distinguisher for NXDOMAIN is better. We hope
others will also agree. There are more details in Section 2.
Cloudflare colleagues also have an interest in using the NXDOMAIN
signal to allow resolvers to modify the response code from NOERROR
to NXDOMAIN back to non-validating clients. I'm not yet persuaded
that this is worth doing, but the draft enables that. Ultimately, if all
client systems run validating stubs/resolvers, they will need to fully
authenticate the contents of the DNS message (the RCODE is then
merely a
Re: [DNSOP] Updated: Compact Denial of Existence
> 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 ‘compact' NSEC record specifies a minimal span of non-existence across the sorted namespace, then why can’t a compact NSEC3 record define a minimal span in the sorted space of hashed names? I must be missing something here. Geoff ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 sorted namespace, then why can’t a compact NSEC3 record define a minimal span in the sorted space of hashed names? I must be missing something here. No, you're right, it surely can. However, the draft says "NSEC" everywhere and makes no mention of NSEC3. I tried to make the point that if this is intentional, it's worth pointing out that intention. 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 enumeration just as well, if not better.) I'm not sure if there are use cases where one would want compact DoE together with NSEC3 opt-out. It doesn't seem to me like that would be a good idea: after all, you're online signing a compact DoE, so what care about opt-out? -- If there is no such use case, NSEC should suffice. Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 >enumeration just as well, if not better.) The introduction does mention NSEC3. It seems worth mentioning that if you can do compact answers, NSEC3 has little (no?) benefit. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 proposal (as it stands). Cheers, Peter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 theory use NSEC3 also. But NSEC is simpler, so unless someone has
a compelling argument to do NSEC3, I'm fine with stating that restriction.
All known implementations to date use NSEC.
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, and IMHO it appears to be a
> very natural meta type fit. ("This is NULL, There Really Is Nothing
> Underneath.")
>
> 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 size issues e.g. when double-signing
> etc.
>
I'm a bit allergic to re-using an RR type already designated for another
purpose. It will require more process work (potentially blocking) to revise
other documents too. Also, I've been told by a few folks who deal with RR
type allocation, that if we standardize this mechanism, it will have to be
a meta-type.
It's certainly true that using a type in the meta-type range will increase
the size of the type bitmap some. Your calculation sounds right. By
comparison, the ENT private type used by NS1 presently consumes only 3 more
octets (window number 255, 1 byte bitmap). This all still seems to be in
the noise to me, and perhaps not worth worrying about. To your comment
about double signing, I suspect the bigger concern will be about the
computational cost to perform multiple cryptographic operations rather than
a few extra bytes in the signature input. (I've proposed algorithm
negotiation mechanisms in the past to deal with that, but so far the
community hasn't been receptive).
[One could ponder defining that NXDOMAIN is indicated with a type bitmap
> that has *only* the sentinel in it, or even an empty bitmap. There would be
> no information loss, as a validator already knows about the NSEC (+ RRSIG)
> record's existence simply by looking at them; the type map adds nothing at
> all. The idea is only semi-serious (because of its risk to cause
> confusion). I'm bringing it up only to observe that such an empty bitmap
> would require no sentinel type at all!]
>
I briefly had the same thought, but dismissed it. You will get bogged down
in long, arduous debates about protocol and cryptographic proof
correctness. By design, the NSEC record needs to prove its own existence.
By contrast, the NSEC3 record can't, so can have an empty type bitmap (see
"The NSEC3 Paradox").
> 3.) Section 2:
>
> An alternative way to distinguish NXDOMAIN from ENT is to define
> the
> synthetic Resource Record type for ENTs instead, as specified in
> [ENT-SENTINEL], and this has already been deployed in the field.
> This
> typically imposes less work on the server since NXDOMAIN responses
> are a lot more common than ENTs.
>
> It's likely I'm missing something, but I'm not following. Here's my line
> of thinking:
>
> Constructing the NODATA response for a name without data records requires
> checking whether the name is an ENT. Depending on the outcome, a bit is
> set/unset. How can inverting the condition affect the amount of work on the
> server?
>
I probably didn't explain myself clearly here. It isn't inverting the
condition. But comparing the work needed to set the distinguisher RR type
in ENT responses versus setting it in NXDOMAIN responses. Since the latter
are far more common.
> 4.) Section 4:
>
> A signed zone at an authoritative server implementing Compact
> Answers
> will never return a response with a response code of NXDOMAIN.
>
> Is this meant literally, or only for queries with "do" flag?
> For responses to queries without "do" flag, there is no DoE processing. To
> preserve the DoE information, the return code fur such responses should IMO
> continue to be NXDOMAIN.
>
This isn't defined clearly in the original draft or in this one, and we
should state explicitly what we want it to be. I believe Cloudflare already
does what you suggest. But NS1 always returns NODATA, regardless of the DO
flag.
Note that many modern DNS resolver implementations always send DO=1,
regardless of whether they are validating the response, or what setting the
downstream client set. They have to be DNSSEC "aware" at least in order to
support potential validating clients behind them. So, we'd have to
weigh the cost/benefit of such differential behavior.
If the return code is not allowed to depend on the "do" flag, it may be
> better to return NXDOMAIN even to "do" queries, in combination with the
> Compact Deni
Re: [DNSOP] Updated: Compact Denial of Existence
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 draft, and (with his agreement) wanted to surface his main concern, which I agree with. To quote Paul, "NXDOMAIN is a vital signal, which must not be withheld". He would like this concern to be top of mind during deliberations on this draft, along with explicit proposals to address it. As you have already seen, we are in fact trying to address the gap by proposing to bring back that signal in a different way, along with other enhancements that could be built on top. But I would like to more prominently mention the concern up front in the abstract of the draft in the next revision. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 prototype.) We intend to follow the specification. The NXDOMAIN type signal is going to be deployed before the end of the month ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 bitmap, and IMHO it appears to be a very natural meta
type fit. ("This is NULL, There Really Is Nothing Underneath.")
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 size issues e.g. when double-signing etc.
I'm a bit allergic to re-using an RR type already designated for another
purpose.
I'm fully with you (= also allergic), but that doesn't mean I'm strictly
opposed. I think it's fine to use an already assigned rrtype for another
purpose, if there are good reasons for doing so and there's no risk of
collision/confusion.
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, and content opaque (if used on the wire). To me, that actually looks like
a rather ideal set of pre-conditions.
Also, I've been told by a few folks who deal with RR type allocation, that if
we standardize this mechanism, it will have to be a meta-type.
Sure. But I'm not proposing to allocate anything; the NULL type is already allocated.
Also, I think it is "meta enough", as the type is already specified to not show
up as the type of an actual record.
I find the natural semantics of "This is NULL, There Really Is Nothing Underneath."
really appealing, as opposed to "This is 0xFF01, ...".
It's certainly true that using a type in the meta-type range will increase the
size of the type bitmap some. Your calculation sounds right. By comparison, the
ENT private type used by NS1 presently consumes only 3 more octets (window
number 255, 1 byte bitmap).
There's a contradiction of goals here: the meta type values lie entirely in
window block 0. All of those, except the NULL type, are in the second half of
the window.
This all still seems to be in the noise to me, and perhaps not worth worrying
about. To your comment about double signing, I suspect the bigger concern will
be about the computational cost to perform multiple cryptographic operations
rather than a few extra bytes in the signature input.
I agree for now, but we don't know the size constraints of the future, such as
which algorithms one will have to roll to. My take is that barring a technical
reason to spend 11 bytes, we should pick the more compact data structure unless
that would cause confusion or an interop problem.
It's unclear whether the 11 bytes will ever be important, and I don't feel
strongly about it. I find the natural semantic fit much more important.
As you pointed out in a separate message, keeping NXDOMAIN signaling clean and
healthy is an important concern. Just assume for a moment that Compact DoE with
NULL type had been around for years. It would feel very clean and almost
obvious for this signal to live in the first bit of the type map.
This bit is currently unused and happens to have a fitting name already.
For responses to queries without "do" flag, there is no DoE processing. To
preserve the DoE information, the return code fur such responses should IMO continue to
be NXDOMAIN.
This isn't defined clearly in the original draft or in this one, and we should
state explicitly what we want it to be. I believe Cloudflare already does what
you suggest. But NS1 always returns NODATA, regardless of the DO flag.
Hm, at least the latter I find rather unexpected.
If the return code is not allowed to depend on the "do" flag, it may be better to
return NXDOMAIN even to "do" queries, in combination with the Compact Denial NSEC record.
The draft correctly says that it is not authenticated, but retaining it probably wouldn't hurt.
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 proof. Maybe we can ask resolver implementers on the list
to speak up about what the actual impact would be for them.
I second the idea of asking them!
Peter
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 Geoff's later point that this
mechanism could in theory use NSEC3 also. But NSEC is simpler, so
unless someone has a compelling argument to do NSEC3, I'm fine with
stating that restriction. All known implementations to date use NSEC.
I'm not opposed to adding the restriction though I'm more in favor of
adding a mention that using NSEC3 increases complexity and processing
requirements while providing no additional benefit
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, and
IMHO it appears to be a very natural meta type fit. ("This is
NULL, There Really Is Nothing Underneath.")
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 size issues
e.g. when double-signing etc.
I'm a bit allergic to re-using an RR type already designated for
another purpose. It will require more process work (potentially
blocking) to revise other documents too. Also, I've been told by a few
folks who deal with RR type allocation, that if we standardize this
mechanism, it will have to be a meta-type.
It's certainly true that using a type in the meta-type range will
increase the size of the type bitmap some. Your calculation sounds
right. By comparison, the ENT private type used by NS1 presently
consumes only 3 more octets (window number 255, 1 byte bitmap). This
all still seems to be in the noise to me, and perhaps not worth
worrying about. To your comment about double signing, I suspect the
bigger concern will be about the computational cost to perform
multiple cryptographic operations rather than a few extra bytes in the
signature input. (I've proposed algorithm negotiation mechanisms in
the past to deal with that, but so far the community hasn't been
receptive).
[One could ponder defining that NXDOMAIN is indicated with a type
bitmap that has *only* the sentinel in it, or even an empty
bitmap. There would be no information loss, as a validator already
knows about the NSEC (+ RRSIG) record's existence simply by
looking at them; the type map adds nothing at all. The idea is
only semi-serious (because of its risk to cause confusion). I'm
bringing it up only to observe that such an empty bitmap would
require no sentinel type at all!]
I briefly had the same thought, but dismissed it. You will get bogged
down in long, arduous debates about protocol and cryptographic proof
correctness. By design, the NSEC record needs to prove its own
existence. By contrast, the NSEC3 record can't, so can have an empty
type bitmap (see "The NSEC3 Paradox").
3.) Section 2:
An alternative way to distinguish NXDOMAIN from ENT is to
define the
synthetic Resource Record type for ENTs instead, as
specified in
[ENT-SENTINEL], and this has already been deployed in the
field. This
typically imposes less work on the server since NXDOMAIN
responses
are a lot more common than ENTs.
It's likely I'm missing something, but I'm not following. Here's
my line of thinking:
Constructing the NODATA response for a name without data records
requires checking whether the name is an ENT. Depending on the
outcome, a bit is set/unset. How can inverting the condition
affect the amount of work on the server?
I probably didn't explain myself clearly here. It isn't inverting the
condition. But comparing the work needed to set the distinguisher RR
type in ENT responses versus setting it in NXDOMAIN responses. Since
the latter are far more common.
4.) Section 4:
A signed zone at an authoritative server implementing
Compact Answers
will never return a response with a response code of NXDOMAIN.
Is this meant literally, or only for queries with "do" flag?
For responses to queries without "do" flag, there is no DoE
processing. To preserve the DoE information, the return code fur
such responses should IMO continue to be NXDOMAIN.
This isn't defined clearly in the original draft or in this one, and
we should state explicitly what we want it to be. I believe Cloudflare
already does what you suggest. But NS1 always returns NODATA,
regardless of the DO flag.
Yes, for queries without the DO-flag we (Cloudflare) return NXDOMAIN
RCODE when appropriate.
Note that many modern DNS resolver implem
Re: [DNSOP] Updated: Compact Denial of Existence
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 size issues e.g. when double-signing >> etc. >> > >I'm a bit allergic to re-using an RR type already designated for another >purpose. It seems like a poor economy. If you really are worried about making the bitmap smaller, I suppose there's unused type 54. Anyone who's using DNSSEC is already prepared for large responses so I wouldn't worry about it. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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, and content opaque (if used on the wire). To >me, that actually looks like a rather ideal set of >pre-conditions. RFC 6895 says: RRTYPE zero is used as a special indicator for the SIG(0) RR [RFC2931] [RFC4034] and in other circumstances and must never be allocated for ordinary use. I suppose we can have a meta-discussion about whether this is an ordinary use, but I would prefer not to. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
> 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 in the NSEC type bitmap, and IMHO it appears to be a very natural meta
> type fit. ("This is NULL, There Really Is Nothing Underneath.")
NULL is type 10. This was assigned in RFC 1035.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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, and IMHO it appears to be a very natural meta type
fit. ("This is NULL, There Really Is Nothing Underneath.")
NULL is type 10. This was assigned in RFC 1035.
Oops, touché! I stand corrected. Thanks, Mark.
What I meant is rrtype 0. I used the wrong mnemonic.*
Based on that, I looked up the wrong things. NULL stuff that I subsequently
quoted doesn't apply, obviously (apologies).
As John pointed out, RFC 6895 has some words about the zero type, including that IANA
must not assign it for use as a regular rrtype (perfect) and allowing its use as a
special indicator also in "other" circumstances (perfect).
Still sounds like a very good fit to me.
The response to the zero type proposal so far was dominated by meta discussions about what's
"meta", what's "ordinary" and so on. I think we should keep in mind that a new
mechanism is being invented, and there's really nothing wrong with thinking out of the box and
changing the ordinary as long as it doesn't cause problems.
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). Looking at this change, I don't understand the non-technical
resistance against considering the zero type in this context. That seems a much less
severe change to me.
I have to say that I'm a bit surprised at the absence of *technical* discussion
around this. It's entirely possible that the proposal is technically not solid
and does cause problems; I'd have loved to hear some arguments in that
direction.
Thanks,
Peter
* Possibly because my native language is German, where "null" means zero.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
<>
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 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, and IMHO it appears to be a very natural meta
>> type fit. ("This is NULL, There Really Is Nothing Underneath.")
>
> NULL is type 10. This was assigned in RFC 1035.
Oops, touché! I stand corrected. Thanks, Mark.
What I meant is rrtype 0. I used the wrong mnemonic.*
Based on that, I looked up the wrong things. NULL stuff that I subsequently
quoted doesn't apply, obviously (apologies).
As John pointed out, RFC 6895 has some words about the zero type, including
that IANA must not assign it for use as a regular rrtype (perfect) and allowing
its use as a special indicator also in "other" circumstances (perfect).
Still sounds like a very good fit to me.
The response to the zero type proposal so far was dominated by meta discussions
about what's "meta", what's "ordinary" and so on. I think we should keep in
mind that a new mechanism is being invented, and there's really nothing wrong
with thinking out of the box and changing the ordinary as long as it doesn't
cause problems.
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). Looking at this change, I don't
understand the non-technical resistance against considering the zero type in
this context. That seems a much less severe change to me.
I have to say that I'm a bit surprised at the absence of *technical* discussion
around this. It's entirely possible that the proposal is technically not solid
and does cause problems; I'd have loved to hear some arguments in that
direction.
Thanks,
Peter
* Possibly because my native language is German, where "null" means zero.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 seven years ago in RFC 8020. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 used internally by name servers in ways that could be pretty difficult to untangle. I would lean toward using a newly allocated type code, though, because I'm 100% sure that wouldn't cause any conflict with existing implementations, and I'm only 99.7% sure that NULL wouldn't. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
> 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 be safe to > use for this. Type 0, thought, would not - it's used internally by name > servers in ways that could be pretty difficult to untangle. NULL would also be difficult to use as they can exist in the wild. > I would lean toward using a newly allocated type code, though, because I'm > 100% sure that wouldn't cause any conflict with existing implementations, > and I'm only 99.7% sure that NULL wouldn't. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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.* > > > > IMHO, you're almost definitely correct that NULL (type 10) would be safe > to > > use for this. Type 0, thought, would not - it's used internally by name > > servers in ways that could be pretty difficult to untangle. > > NULL would also be difficult to use as they can exist in the wild. > And they do! Don't break my zone please :-) $ dig +short null.huque.com. NULL | python -c "import sys,binascii;print(binascii.unhexlify(sys.stdin.readline().split()[-1]))" b'DNS is weird' > > I would lean toward using a newly allocated type code, though, because > I'm > > 100% sure that wouldn't cause any conflict with existing implementations > ... > Yeah, that's certainly true, and perhaps that should be our primary goal. I am partly sympathetic to Peter's view that RR type 0 would have been a natural fit for this purpose, but the key is "would have been". The concern about message size constraints is misplaced I think. (Pseudo) NXDOMAIN compact answers I just examined in a few of my zones are between 350 and 400 octets. So, we have > 1000 octets of buffer in UDP before problems. If we look to a future where online signers are double signing with a PQC algorithm, type bitmap sizes won't be a factor - and moving to alternate transports that don't have size constraints is more likely (or negotiation of algorithms). Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 history behind that? And would current meta type allocation rules even allow it to be used for this purpose? (OPT is meta and uses type 41, but that probably predates the DNS IANA considerations doc by ages.) Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 proof. My understanding of RFCs is that NXDOMAIN or NOERROR are a mandatory part of what needs to be proven by the records inside. If the proof doesn't match the RCODE, surely validators should SERVFAIL. I don't think you can salvage this by a simple new EDNS option; it's the signed records where you need to prove the result you want. --Vladimir | knot-resolver.cz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 message body, and they won't > find a traditional NXDOMAIN proof. > > My understanding of RFCs is that NXDOMAIN or NOERROR are a mandatory part > of what needs to be proven by the records inside. If the proof doesn't > match the RCODE, surely validators should SERVFAIL. I don't think you can > salvage this by a simple new EDNS option; it's the signed records where you > need to prove the result you want. > The NXDOMAIN or NOERROR "state" definitely has to be proven by the signed records inside the message. I haven't found anywhere in the spec that says that this state has to match the RCODE value though (I skimmed RFC 4035 and 5155 a couple of days ago). Let me know if it's there and I didn't spot it. Those specs solely talk about how to determine various responses from signed records without reference to RCODE (RCODE is mentioned only in connection with setting SERVFAIL for responses that fail to or cannot be validated, and parenthetically in the example message contents in the appendix). It may be an implicit assumption that they should match the RCODE, but I think there is room for a debate. As I mentioned previously, the RCODE is unauthenticated, and so at most it should only be used as a hint as to what proof exists in the message body. And it is certainly not required to validate such proofs. For example, RFC9102 (TLS DNSSEC Chain Extension) delivers a chain of signed RRsets without any response code, and validators are expected to verify them and determine the appropriate state (e.g. Answer vs NXDOMAIN vs NODATA vs unsigned delegation along the path). In any case, my assumption remains that unconditionally changing the RCODE for compact answer nxdomains will break many existing validators. I'm assuming from your response that that's the case with Knot. I was waiting to see if other implementers would confirm the behavior in their implementations. But in the meantime, I've done some very quick empirical tests (with a hacked up DNS authoritative server that returns NXDOMAIN for all signed responses) and the results are interesting: BIND and 8.8.8.8 SERVFAIL on everything that doesn't contain a real NXDOMAIN proof; Unbound appears to authenticate NODATA responses fine, and sets AD=1 and resets RCODE=NOERROR to downstream queries, but SERVFAILS on other non NXDOMAIN proofs; and Cloudflare/1.1.1.1 appears to authenticate all responses fine and sets AD=1, but returns the lied about RCODE intact to downstream queriers. So, I think the only way we could safely do RCODE replacement for signed responses is by the use of an EDNS signal. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 better how that could work specifically. In another
message (March 5), you explained:
proposal to have compact answer proofs AND an NXDOMAIN rode, would be to introduce an
EDNS signaling flag or option ("Compact Answers OK"). If the authoritative
server receives that from a resolver, it could provide the compact answer proof as well
as set RCODE 3. Resolvers would also have to support this on the downstream hops.
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)
a classical proof (no sentinel), but with an NXDOMAIN code?
It occurs to me that if you want to ensure the cryptographic statement cannot
be undermined, then (b) is not an option. It would allow an on-path attacker to
replace the NSEC proof in an answer with a classical proof (which the attacker
can obtain via an extra query without the EDNS signal). The response that the
client receives will then not be distinguishable from an ENT response, i.e. an
on-path attacker can downgrade an NXDOMAIN proof to an ENT proof.
That can only be avoided if the nameserver never ever returns an NSEC proof
without sentinel bit in an NXDOMAIN situation.*
That's option (a). However, that means that client not supporting the EDNS
option won't get NXDOMAIN, i.e. it's a semantics change.
One way to retain the NXDOMAIN code for legacy clients without opening this
attack vector would be to add *yet another* sentinel to the type bitmap, which
would be present at both ENT and non-existent names, when compact DoE support
was signaled via EDNS. This would prove to clients signaling compact DoE
support that an answer that looks like an ENT answer really is one (i.e. was
not exchanged as described above).
I've done some very quick empirical tests (with a hacked up DNS authoritative
server that returns NXDOMAIN for all signed responses) and the results are
interesting:
Indeed! Thanks for doing the experiment.
~Peter
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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) a classical proof (no >sentinel), but with an >NXDOMAIN code? It would return a RFC 4470 white lie, which does the same thing but is larger since it needs two NSEC and two RRSIG records, one for the name and one to show there's no wildcard. I wouldn't try to get any more clever. Just use an EDNS0 code in the query to say compact results are OK. I'd like to use the same code to say this result is really NXDOMAIN, but those aren't signed, so I think we do need to assign a metatype to go in the signed NSEC. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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, does the nameserver return (a) the compact >> proof (with sentinel in >> the type map) is sent, but with a NOERROR code, or (b) a classical proof (no >> sentinel), but with an >> NXDOMAIN code? > > It would return a RFC 4470 white lie, which does the same thing but is > larger since it needs two NSEC and two RRSIG records, one for the name > and one to show there's no wildcard. > > I wouldn't try to get any more clever. Just use an EDNS0 code in the > query to say compact results are OK. I'd like to use the same code to > say this result is really NXDOMAIN, but those aren't signed, so I > think we do need to assign a metatype to go in the signed NSEC. > > R's, > John > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 upstream, EDNS0 is hop by hop and we don’t have good track record of singling anything in DNS. What you want is really not doable with EDNS0 IMHO, as we have that spaghetti as Geoff Houston always says that is DNS and unfortunately has chains of resolvers before getting to any auth. So long -Ralf ——- Ralf Weber ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 pretty slow. > > Clients have no control over what a resolver does upstream, EDNS0 is hop > by hop and we don’t have good track record of singling anything in DNS. > What you want is really not doable with EDNS0 IMHO, as we have that > spaghetti as Geoff Houston always says that is DNS and unfortunately has > chains of resolvers before getting to any auth. > > So long > -Ralf > ——- > Ralf Weber > 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 to intelligently manage that answer in its cache. To downstream DO=1 queriers that also set CompactAnswersOK, it could return that answer as is. To those that don't, it would have to reset the RCODE to NOERROR. This imposes more complexity on the resolver implementation of course, but I don't see any reason why it wouldn't work - and it would be optional anyway. Clients that want to see the NXDOMAIN signal in the RCODE might push their resolver service to implement it. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
Wait, so if my cache does this and I change nothing, it silently turns NXDOMAIN into NOERROR? That is badly broken.Sent from my Galaxy Original message From: Shumon Huque Date: 3/15/23 07:48 (GMT-05:00) 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 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 CompactAnswersOK, it could return that answer as is. To those that don't, it would have to reset the RCODE to NOERROR. This imposes more complexity on the resolver implementation of course, but I don't see any reason why it wouldn't work - and it would be optional anyway. Clients that want to see the NXDOMAIN signal in the RCODE might push their resolver service to implement it.Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 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? The answer to that I think is that a number of folks have argued to me that there are tons of security, analytics, and traffic characterization tools in existence today that look at the RCODE field for this purpose, and they are presently already broken because of this. We could ask them to modify their implementations to infer NXDOMAIN from the NXNAME pseudo-type, but who knows how long that will take (if ever). Shumon. On Wed, Mar 15, 2023 at 10:04 AM John Levine wrote: > Wait, so if my cache does this and I change nothing, it silently turns > NXDOMAIN into NOERROR? That is badly broken. > > > > > Sent from my Galaxy > > Original message > From: Shumon Huque > Date: 3/15/23 07:48 (GMT-05:00) > 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 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 CompactAnswersOK, it could return > that answer as is. To those that don't, it would have to reset the RCODE to > NOERROR. This imposes more complexity on the resolver implementation of > course, but I don't see any reason why it wouldn't work - and it would be > optional anyway. Clients that want to see the NXDOMAIN signal in the RCODE > might push their resolver service to implement it. > > Shumon. > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 that for our idea (generating negative responses on the fly) to ever become more than a fringe phenomena we need to talk about alternatives for having private keys located at the edge (i.e. in the authoritative servers generating the response). I.e this section in the draft is the crux of the matter: > 6. Security Considerations > Online signing of DNS records requires authoritative servers for the DNS zone > to have > access to the private signing keys. Exposing signing keys on Internet > reachable > servers makes them more vulnerable to attack. Our original idea was to propose a different type of DNSKEY, i.e. a new flag bit in the DNSKEY that would signal “this key is only allowed to sign negative responses”. We were, however, talked out of that idea based on the strong wish to get DNSSEC out the door ASAP and therefore under no circumstances open up the Pandoras Box of further tweaks to the existing protocol. And yet, here we are, seventeen years later, still discussing this. For white lies, black lies, compact lies or whatever we choose to call them to ever become mainstream my view is still that we need a mechanism that works for *all* zones. In particular it needs to work for TLD zones, as they are the one’s that care most about prohibiting zone walking. And the TLDs most certainly are not about to hand over their private keys to their contracted DNS service providers (and I say this as previously having been responsible for DNS at a major service provider for many years and now working for a ccTLD registry). It just aint gonna happen. So either we’re limiting scope to optimising black lies, and there’s nothing wrong with that. Or we decide to talk about the real issue: what change is needed to DNSSEC to allow a third party DNS provider to generate negative responses on the fly without having access to the private keys of the customer? Otherwise, and my cynicism may be showing here, we will still be talking about this seventeen years from now, i.e. sometime around 2040. Unless, of course, the Internet stops working in 2038, when we, literally, run out of time :-) Regards, Johan smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
Now it sounds like NXDOMAIN turns into SERVFAIL. When I have a decent keyboard I'll suggest a way this might not break unmodified downstream clients. Sent from my Galaxy Original message 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 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 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?The answer to that I think is that a number of folks have argued to me that there are tons of security, analytics, and traffic characterization tools in existence today that look at the RCODE field for this purpose, and they are presently already broken because of this. We could ask them to modify their implementations to infer NXDOMAIN from the NXNAME pseudo-type, but who knows how long that will take (if ever).Shumon.On Wed, Mar 15, 2023 at 10:04 AM John Levine wrote:Wait, so if my cache does this and I change nothing, it silently turns NXDOMAIN into NOERROR? That is badly broken.Sent from my Galaxy Original message From: Shumon Huque Date: 3/15/23 07:48 (GMT-05:00) 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 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 CompactAnswersOK, it could return that answer as is. To those that don't, it would have to reset the RCODE to NOERROR. This imposes more complexity on the resolver implementation of course, but I don't see any reason why it wouldn't work - and it would be optional anyway. Clients that want to see the NXDOMAIN signal in the RCODE might push their resolver service to implement it.Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
Sorry, I don't follow. The whole point of the conditional behavior based on the EDNS signal, is to allow RCODE replacement without causing SERVFAIL. Perhaps I have not clearly described the details, and I also should write it up more precisely. I'll also wait for your write-up. Shumon. On Wed, Mar 15, 2023 at 10:49 AM John Levine wrote: > Now it sounds like NXDOMAIN turns into SERVFAIL. When I have a decent > keyboard I'll suggest a way this might not break unmodified downstream > clients. > > > > Sent from my Galaxy > > > Original message > 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 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 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? > > The answer to that I think is that a number of folks have argued to me > that there are tons of security, analytics, and traffic characterization > tools in existence today that look at the RCODE field for this purpose, and > they are presently already broken because of this. We could ask them to > modify their implementations to infer NXDOMAIN from the NXNAME pseudo-type, > but who knows how long that will take (if ever). > > Shumon. > > On Wed, Mar 15, 2023 at 10:04 AM John Levine wrote: > >> Wait, so if my cache does this and I change nothing, it silently turns >> NXDOMAIN into NOERROR? That is badly broken. >> >> >> >> >> Sent from my Galaxy >> >> ---- Original message ---- >> From: Shumon Huque >> Date: 3/15/23 07:48 (GMT-05:00) >> 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 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 CompactAnswersOK, it could return >> that answer as is. To those that don't, it would have to reset the RCODE to >> NOERROR. This imposes more complexity on the resolver implementation of >> course, but I don't see any reason why it wouldn't work - and it would be >> optional anyway. Clients that want to see the NXDOMAIN signal in the RCODE >> might push their resolver service to implement it. >> >> Shumon. >> >> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 be comfortable with (or at least resigned to) the DNS provider holding the signing keys. I agree that it's useful to solve the problem you describe, and I'm interested in it myself, but it sounds to me like a larger effort and should be tackled separately (or in parallel). Shumon. On Wed, Mar 15, 2023 at 10:29 AM Johan Stenstam < johan.stens...@internetstiftelsen.se> wrote: > 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 that for our idea (generating > negative responses on the fly) to ever become more than a fringe phenomena > we need to talk about alternatives for having private keys located at the > edge (i.e. in the authoritative servers generating the response). > > I.e this section in the draft is the crux of the matter: > > > 6. Security Considerations > > Online signing of DNS records requires authoritative servers for the DNS > zone to have > > access to the private signing keys. Exposing signing keys on Internet > reachable > > servers makes them more vulnerable to attack. > > Our original idea was to propose a different type of DNSKEY, i.e. a new > flag bit in the DNSKEY that would signal “this key is only allowed to sign > negative responses”. We were, however, talked out of that idea based on the > strong wish to get DNSSEC out the door ASAP and therefore under no > circumstances open up the Pandoras Box of further tweaks to the existing > protocol. > > And yet, here we are, seventeen years later, still discussing this. > > For white lies, black lies, compact lies or whatever we choose to call > them to ever become mainstream my view is still that we need a mechanism > that works for *all* zones. In particular it needs to work for TLD zones, > as they are the one’s that care most about prohibiting zone walking. And > the TLDs most certainly are not about to hand over their private keys to > their contracted DNS service providers (and I say this as previously having > been responsible for DNS at a major service provider for many years and now > working for a ccTLD registry). > > It just aint gonna happen. > > So either we’re limiting scope to optimising black lies, and there’s > nothing wrong with that. Or we decide to talk about the real issue: what > change is needed to DNSSEC to allow a third party DNS provider to generate > negative responses on the fly without having access to the private keys of > the customer? > > Otherwise, and my cynicism may be showing here, we will still be talking > about this seventeen years from now, i.e. sometime around 2040. Unless, of > course, the Internet stops working in 2038, when we, literally, run out of > time :-) > > Regards, > Johan > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 with (or at least resigned to) > the DNS provider holding the signing keys. > > I agree that it's useful to solve the problem you describe, and I'm > interested in it myself, but it sounds to me like a larger effort and should > be tackled separately (or in parallel). I fully agree with that. My message was badly put, I don’t in any way think it is either or, but rather two separate things. The reason that I brought it up here and now is, well, because of the rather obvious connection. Johan smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 find it there. I think we are talking past each other. If you're saying this approach is better than black lies, I agree it is, but we would never standardize black lies because it returns wrong results. I think this rather hacky approach could work: a client sends a request with the compact denial flag. The upstream does whatever it does and gets a result. If the result is anything other than an NXNAME, return the result and cache it normally. If it's a NXNAME, return the result, but put it in a special cache that only returns results to subsequent queries with the compact denial flag set, since they're the only ones that know what NXNAME means. You might have the same result cached with a NXNAME for compact denial clients and a white lie for other clients, but so be it. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 CompactAnswersOK, it could return that answer as is. To those that don't, it would have to reset the RCODE to NOERROR. If I understood that correctly, this is like option (a) from my earlier message (https://mailarchive.ietf.org/arch/msg/dnsop/PdK2ZTaTruQ-klI8ZH6C-ij0R6Y/), this time through an RCODE change done by the resolver. Now this means that this draft would, I believe for the first time, specify that it's fine to withhold the NXDOMAIN signal from legacy clients that don't send the EDNS CompactAnswersOK signal. If I didn't get something wrong and that is indeed the case, my view is that it should say so explicitly -- namely, (1) that it does not only introduce a way to return a smaller DoE to supporting clients, but it also introduces a change for legacy clients, (2) it requires resolver-side support. (In my message linked above, I was talking about what the *auth* would send when receiving a query without the EDNS flag. Would it do the same as described above, like the resolver?) Peter This imposes more complexity on the resolver implementation of course, but I don't see any reason why it wouldn't work - and it would be optional anyway. Clients that want to see the NXDOMAIN signal in the RCODE might push their resolver service to implement it. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
[ 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 dns-operations post on the same general topic. ] A possibly inconvenient question, just to make sure we're not ignoring the obvious sceptical position: * How compelling is compact DoE? The reason to ask is that both the original and now modified protocols involve non-trivial complexity, and would likely require resolvers to respond differently to queries with the DO bit set (pass them the NODATA "truth" along with the NXNAME signal) vs. queries that don't request validated answers (pass them the inferred NXDOMAIN). The savings vs. actual by-the-book NSEC responses appear to be a 2x reduction in the number of signatures to compute (the SOA RRSIG is presumably easily cached) and a 1.5x reduction in the number of signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC). Do the CPU and packet size reductions justify the additional protocol complexity? * There is perhaps another way to ask the question: what is the motivation for compact DoE? Perhaps CPU and packet sizes are a side show and this is all about avoiding zone walking? In that case, might not NSEC3 "1 0 0 -" be good enough? Sure a sufficiently motivated offline dictionary brute-force attacker may be able to discover some names faster with fewer online queries, but is this **really** a concern. How secret do you expect your DNS data to be? A big chunk of many zones ends up for free in certificate transparency logs, or available from various (sometimes paywalled) sources. I am personally not impressed by arguments that DNS names require confidentiality protection stronger than sufficient to deter "casual" zone walking ala plain NSEC. > But the main change is to move from the ENT distinguisher RR type > to an explicit one for NXDOMAIN (with mnemonic NXNAME). The draft fails to explain how queries for the proposed new RRtype are to be handled by authoritative servers and resolvers. --- On Wed, Mar 15, 2023 at 02:29:56PM +, Johan Stenstam wrote: > Our original idea was to propose a different type of DNSKEY, i.e. a > new flag bit in the DNSKEY that would signal “this key is only allowed > to sign negative responses”. We were, however, talked out of that idea > based on the strong wish to get DNSSEC out the door ASAP and therefore > under no circumstances open up the Pandoras Box of further tweaks to > the existing protocol. This runs into a critical problem. A security-critical function of DNSSEC at the public suffix layer (TLDs, ...) is to not be vulnerable to forged denial of existence of DS records for securely delegated domains. **This**, and not avoiding opportunistic DANE TLSA downgrade attacks (also good to have) is the reason that DNSSEC MUST have secure denial of existence. Therefore, signing keys for denial of existence are no less sensitive (at least for zones that sign secure delegations) than signing keys for positive response, and so the various TLD and ccTLD operators need to be just as concerned about handing out negative signing keys. [ And no, I am not about to suggest/endorse NSEC5. ] > And yet, here we are, seventeen years later, still discussing this. So I don't believe that idea can pan out. On Sun, Mar 05, 2023 at 06:20:34PM +0100, Peter Thomassen wrote: > 1.) Maybe it's worth pointing out that zones using compact denial > SHOULD (MUST?) use NSEC, not NSEC3. As others pointed out, "NSEC3 1 0 0 -" could be used, but there's no point. So indeed best to not define a needlessly elaborate variant. > 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0. This *could* be worth exploring, and has some appeal, but may be too difficult to know to be safe against as yet unseen resolvers that would later come out of the woodwork. Someone would have to be willing to run the experiment at scale. > 3.) Section 2: > > An alternative way to distinguish NXDOMAIN from ENT is to define the > synthetic Resource Record type for ENTs instead, as specified in > [ENT-SENTINEL], and this has already been deployed in the field. This > typically imposes less work on the server since NXDOMAIN responses > are a lot more common than ENTs. Or both. In other words, use two sentinel RRtypes, one to unambiguously signal an ENT, and another to signal NXDOMAIN. This disambiguates the protocol from current practice, though perhaps the ambiguity would not last long if the current operators migrate to the new protocol quickly. > A signed zone at an authoritative server implementing Compact Answers > will never return a respo
Re: [DNSOP] Updated: Compact Denial of Existence
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): > > > > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01 > > [ Copied from today's dns-operations post on the same general topic. ] > > A possibly inconvenient question, just to make sure we're not ignoring > the obvious sceptical position: > > * How compelling is compact DoE? > > The reason to ask is that both the original and now modified protocols > involve non-trivial complexity, and would likely require resolvers to > respond differently to queries with the DO bit set (pass them the NODATA > "truth" along with the NXNAME signal) vs. queries that don't request > validated answers (pass them the inferred NXDOMAIN). > > The savings vs. actual by-the-book NSEC responses appear to be a 2x > reduction in the number of signatures to compute (the SOA RRSIG is > > > presumably easily cached) and a 1.5x reduction in the number of > signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC). > > Do the CPU and packet size reductions justify the additional protocol > complexity? > I'll also regurgitate my message here from the dns-operations@ list thread: That's a reasonable question, and perhaps best directed to the originators of the scheme at Cloudflare. I don't know if there have been any measurement studies or analyses of the cost benefits vs by-the-book DNSSEC. There are currently 3 large commercial DNS providers that have had it deployed for a while now, so I suspect that it is here to stay. Note that one other provider (UltraDNS) does support traditional NSEC White "Lies" that give by-the-book DNSSEC proofs for NXDOMAIN, so apparently they are bearing the additional costs just fine. One other point -- without the additional rcode substitution schemes under discussion, Compact Answers can cause additional work for authority servers, since NODATA responses may lead to follow-on queries by DNS client applications (e.g. the common followed by A pattern; note: most DNS resolution API functions don't do happy eyeballs today). So, the per-response crypto & size reductions need to also be weighed against the cost of these additional queries. > But the main change is to move from the ENT distinguisher RR type > > to an explicit one for NXDOMAIN (with mnemonic NXNAME). > The draft fails to explain how queries for the proposed new RRtype are > to be handled by authoritative servers and resolvers. > Since this is a "meta" type for which we don't expect normal applications to ever issue queries, its behavior could be undefined I suppose. But it's probably better to explicitly say what the response should be. Maybe NODATA for an existing name, and NODATA + NXNAME NSEC bitmap sentinel for non-existent names? Sending FORMERR or SERVFAIL might invoke unwanted additional follow-on queries by resolvers (or their downstreams), although I suppose SERVFAIL + a new EDE value might be a possibility. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 have to intelligently manage that answer in its cache. > > Adding EDNS0 signals here is much too complex. The DO bit is > sufficient. A validating resolver that supports the proposed > specification can infer NXDOMAIN from the form of the NSEC RR. > If it does not support the proposed specification, then the presented > DoE proof is NODATA, and that must be sent. So just always send NODATA > (NOERROR) when the DO bit is set in the query. > > The clients that see the restored NXDOMAIN will be the stub resolvers > that don't do validation, and sit behind a local validating forwarder. > The issue is that there are a lot of security, diagnostic, and traffic characterization tools that examine the RCODE field and want that to be accurate even for DO=1 queries -- not just a converted RCODE by a NXNAME recognizing resolver, but in the response from the authorities too. In theory those could be enhanced to recognize NXNAME, but I think there is a lot of pessimism that would happen anytime soon, since many of them are generally not developed by DNS experts, and older deployed code generally hangs around forever. I recently spoke to the vendor of one such tool, and suggested that they need to look deeper in the packet to get the info out of the NSEC bitmap, but they seemed pessimistic that they could do that at wire speed with high volume DNS traffic. Maybe this problem is too complex to solve, but let's at least talk through the details first before disbanding it. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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. for perspective, no root name server has deployed this alternative form of Denial of Existence, and i believe this includes the f-root anycast instances operated by cloudflare under ISC's management. root name servers receive an awful lot of junk, and aren't in general overfunded, so if compactness of DoE was compelling for anybody, it seems like it would be for them. yet: ; <<>> DiG 9.18.9 <<>> +dnssec luasfluh. @f.root-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55686 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;luasfluh. IN A ;; AUTHORITY SECTION: . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023032800 1800 900 604800 86400 . 86400 IN RRSIG SOA 8 0 86400 2023041005 2023032804 951 . lNcrq1jIeyKGIpkcgMdpPW77yeCLJ+2vU9+HM9Jwr0m1g6RZE8YyxlRA +q2oIuDHailclFDPMdjgX2lAMhxaNjWl/H+c2fjZN4+yIRWDcUPnDou5 sn0S5s2fZQTqdnVghSz4JVXJUCo6bTPWDoA8kt/kuXL/bamISWiI0P39 VYplvnIVVm7/oQ8gYmWChNfl3TkCXZsbLtsKc2sW5Ssjb50Gs7WKduvo UCJRmviRNfJvWcZt1nzZWNGTlwDQcJKTLQDSdXXQd+j4FyUpgIAS3THd GzpQblEEKSgYRrGUGbZJ9QKAy0niI2D0JVqHmeHP+g3M8CC7QKKK3FsH Xb9Paw== lu. 86400 IN NSEClundbeck. NS DS RRSIG NSEC lu. 86400 IN RRSIG NSEC 8 1 86400 2023041005 2023032804 951 . KS2/AAlD6atD3EfuRwCciYyBtl4aedoOMd2Z60EzZFoXbbGm9ghYPFeB xO+7MpYUTeNQ8ZSI9hZXeNf5ood3QORw4Wevo+XxoQoFnHxyXnLjlpXA 2h+N3/yPjt20iCTD6zF1n/AOxDnATzIabj6StaMO4dMD7pXTHQxWE+a5 vCQNRrWVQKv43QFj7zkEBaYX7YHFwKyODdIXnIBnrq1sItGqpZ8nYoaZ odCGzFyaMh3vN1FPbrgVhTDeDFFAkQ8k9nZjmQ+r6YtZqgdsx9zY5Lao K/EfL6+2UtGiQSVi1O/KzxjZ933t0BkyFNv6jqZANNfTIt1PBvbFWDH+ jfiCbw== . 86400 IN NSECaaa. NS SOA RRSIG NSEC DNSKEY . 86400 IN RRSIG NSEC 8 0 86400 2023041005 2023032804 951 . s9mtWsArs0D1e93ri9e7FVsvMH8gQE/R2zO2plcvd+gkbNuuQwR+SyYT rJu7s0mUkuKCsNyU26k8E4ve5S7RbI7Zkg5mGVUoaoLOlk229l3PGPzj pj1k8fyHUh1ed1PyYxq1UlnIxPAGiSCocKHlB5Dp1CHACCw4zYT4bl/V czCCcyqesCD+eTI+CF1hMiZOOIc9heViHENFzG1qPCH8PLDHJVpl3cJm H0zriGwGQk8D/JGp2M7SEgr/JmJCSpmHwmMbwC//UUaPKvpFLqoEFr5x 6TCxDDg5u8eynptBeuoRqKYBWey+nl1pAC30tBhkjwqCjS19fNBVhmbh BbygbA== ;; Query time: 3 msec ;; SERVER: 2001:500:2f::f#53(f.root-servers.net) (UDP) ;; WHEN: Tue Mar 28 12:42:04 UTC 2023 ;; MSG SIZE rcvd: 1028 i strongly suspect that the era has passed during which compactness of DoE was worth its complexity cost. however, i think that's a decision for each operator. my only objective concern is that all Denial of Existence signals emitted by any DNS server be distinguishable from NODATA and distinguishable from ENT. so if "compact DoE" goes forward those should be hard requirements. The reason to ask is that both the original and now modified protocols involve non-trivial complexity, and would likely require resolvers to ... i feel you, brother. however, if operators insist that they've got to have this, we'll have to accept the complexity costs necessary to meet my above-described hard requirements. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 (-01): > > https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01 [ Copied from today's dns-operations post on the same general topic. ] A possibly inconvenient question, just to make sure we're not ignoring the obvious sceptical position: * How compelling is compact DoE? The reason to ask is that both the original and now modified protocols involve non-trivial complexity, and would likely require resolvers to respond differently to queries with the DO bit set (pass them the NODATA "truth" along with the NXNAME signal) vs. queries that don't request validated answers (pass them the inferred NXDOMAIN). The savings vs. actual by-the-book NSEC responses appear to be a 2x reduction in the number of signatures to compute (the SOA RRSIG is presumably easily cached) and a 1.5x reduction in the number of signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC). Do the CPU and packet size reductions justify the additional protocol complexity? I'll also regurgitate my message here from the dns-operations@ list thread: That's a reasonable question, and perhaps best directed to the originators of the scheme at Cloudflare. I don't know if there have been any measurement studies or analyses of the cost benefits vs by-the-book DNSSEC. There are currently 3 large commercial DNS providers that have had it deployed for a while now, so I suspect that it is here to stay. Compact DoE should be seen through the lens of online signing and that changes the perspective quite a bit for large providers. That the answer is compact is a clear benefit but reducing the amount of work the authoritative server has to perform is more important. The server does not need to know the contents of the full zone, just that either the name or the type in question does not exists. No need to lookup closest enclosers etc. Depending on how you've designed the internals of your server this reduction in the work you have to perform is likely substantial. The proposal for Compact DoE is also of benefit to validating resolvers for normal workloads as less signatures have to be validated. On the flip side there is the question of a random prefix attacks and RFC 8198, but then again "white-lies" and NSEC3 opt-out was kind of the needle to that balloon so this (Compact DoE) is not making that situation any worse. /Christian___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 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 believe this includes the f-root anycast instances operated by > cloudflare under ISC's management. root name servers receive an awful > lot of junk, and aren't in general overfunded, so if compactness of > DoE was compelling for anybody, it seems like it would be for > them. yet: It would be scary if any of the root name servers could deploy this because that meant that they have access to the zone signing private key. Which they don't. -- In my defence, I have been left unsupervised. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 > believe this includes the f-root anycast instances operated by > cloudflare under ISC's management. root name servers receive an awful > lot of junk, and aren't in general overfunded, so if compactness of DoE > was compelling for anybody, it seems like it would be for them. Root servers don't do online signing; they serve a pre-signed zone. They don't have a motivation to reduce the cost of signature generation at response time because that cost is already zero. Online signing by root servers would be a significant policy departure from how things are currently organised, since it would imply that individual root server operators bear some kind of responsibility for the contents of the root zone. Offline signing seems to work quite well with a zone that is not updated with high frequency. A more compact signed, negative response would reduce the capacity required to send negative responses, of which as you pointed out root servers send a lot. However, I seem to think that root server instances are already quite well-provisioned with spare capacity over and above their steady-state requirements in order to be prepared for flash crowds and attack traffic. It's always good to be frugal, I guess, but it's not obvious to me that this is a problem in search of a solution in this case. I'm not sure that root servers (or the root zone) are obvious candidates for compact negative responses. Joe___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 motivation to reduce the cost of signature generation at response time because that cost is already zero. oops. duh. 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 responses that were smaller than 512b being less than for responses that were larger than 512b. i think it's worth asking if this still matters, or else, is the current perceived benefit of CDoE simply that a NODATA response is easier to construct and contains no wildcard disproof? -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 pre-signed zone. They don't have a motivation to reduce the cost of signature generation at response time because that cost is already zero. oops. duh. 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 responses that were smaller than 512b being less than for responses that were larger than 512b. i think it's worth asking if this still matters, or else, is the current perceived benefit of CDoE simply that a NODATA response is easier to construct and contains no wildcard disproof? The original blog does bring up the CPU argument: https://blog.cloudflare.com/black-lies/ from the Conclusion: "We’re proud of our negative answers. They help us keep packet size small, and CPU consumption low enough for us to provide DNSSEC for free for any domain" and yes packet size still matters / Christian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Updated: Compact Denial of Existence
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 responses that were smaller than 512b being less than for responses that were larger than 512b. i think it's worth asking if this still matters, or else, is the current perceived benefit of CDoE simply that a NODATA response is easier to construct and contains no wildcard disproof? The original blog does bring up the CPU argument: https://blog.cloudflare.com/black-lies/ from the Conclusion: "We’re proud of our negative answers. They help us keep packet size small, and CPU consumption low enough for us to provide DNSSEC for free for any domain" after X years your load has scaled to use all headroom added by your supply chain? usually these things relax. are you sure you still need to ask the world to accept NODATA in place of NXDOMAIN? be sure that while olafur's blog is proud of its negative answers, those answers are non-negative, denying rrsets but not names, and the cost of that shortcut is a burden on internet security workers everywhere. we need to know when a name is asserted to not exist, and when. and yes packet size still matters can you help me understand why? for the networks i touch, PPS matters quite a lot but BPS differences between 512b and 1500b do not. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
