On 2023-03-06 03:35, Shumon Huque wrote:
On Sun, Mar 5, 2023 at 12:20 PM Peter Thomassen <pe...@desec.io> 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 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 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. But we'd need to conduct a wider study of
deployed implementations in the field before we could make such a
suggestion.
In my opinion, an architecturally cleaner 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.
Returning NXDOMAIN while not supplying the correct NSEC/NSEC3 proofs
does break resolvers last I checked. It would likely be a barrier to
adoption where the NODATA->NXDOMAIN "upgrade" is potentially less work
and not breaking existing resolver implementations.
/Christian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
