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.
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 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.
Shumon.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
