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
<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? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
