Re: [DNSOP] I-D Action: draft-ietf-dnsop-compact-denial-of-existence-03.txt

[Shumon Huque <[e-mail]>]

On Sat, Mar 16, 2024 at 1:10 AM Stephane Bortzmeyer <[e-mail]>
wrote:

> On Mon, Mar 04, 2024 at 02:15:55PM -0800,
>  [e-mail] <[e-mail]> wrote
>  a message of 48 lines which said:
>
> > Internet-Draft draft-ietf-dnsop-compact-denial-of-existence-03.txt is now
> > available. It is a work item of the Domain Name System Operations
> (DNSOP) WG
> > of the IETF.
>
> I just implemented it at the IETF 119 hackathon in Brisbane
> (programming details at the end), on an authoritative-only server. I
> think I have done everything that's in the draft, including the EDNS
> signaling (new flag CO).
>
> This was quite simple and the draft is enough to guide the
> implementor. I find the draft clear and useful.
>

Thanks! Glad to hear that.

Among the questions raised:
>
> * is there an EDE which is recommended when replying to an
> explicit request for a meta-type (like QTYPE=NXNAME)? The draft says
> to set the rcode to FormErr but does not discuss EDE.
>

It doesn't, but could. I don't see an obviously applicable EDE code that
covers this (apart from the catch-all "Other Error"), so perhaps we could
define a new one, "Invalid Query Type"?


> * the draft does not discuss the consequences of compact denial for
> synthesis of negative answers by a resolver (RFC 8020 and 8198).
>

That's a good suggestion and it's worth saying something about this.
The negative answer synthesis capability for 8198 is already gone for
any minimally covering NSEC mechanism, so Compact Denial doesn't
make this any worse than White Lies or other similar methods.

RFC 8020 is affected differently though. Since the NSEC owner
matches a non-existent name, negative answer synthesis below
that name is possible only if a resolver recognizes NXNAME (which
is recommended but optional behavior currently).

* [this one is outside the scope of the draft] Is it
> reasonable/legitimate to reply NODATA for a non-existing name when
> the client did not set the DO flag, or even when it did not use EDNS?
>

We do have some text that discusses this, which I'll excerpt here:

   For non-existent names, implementations should try wherever possible,
   to preserve the response code value of 3 (NXDOMAIN).  This is
   generally possible for non-DNSSEC enabled queries, namely those which
   do not set the DNSSEC_OK EDNS flag (DO bit).  For such queries,
   authoritative servers implementing Compact Denial of Existence could
   return a normal NXDOMAIN response.  There may be limited benefit to
   doing this however, since most modern DNS resolvers are DNSSEC-aware,
   and by [RFC3225] Section 3, DNSSEC-aware recursive servers are
   required to set the DO bit on outbound queries, regardless of the
   status of the DO bit on incoming requests.

Basically, we're not trying to prescribe the behavior for DO=0 or non EDNS.
One current implementation does not differentiate DO=0 vs 1 and gives the
same NODATA answer for both cases.

Programming details: the change was made on the Drink authoritative
> dynamic server <https://framagit.org/bortzmeyer/drink/>. Since Drink
> only has dynamic signing, it implemented the white lies of RFC
> 4470. Adding compact denial was mostly removing code since, for the
> authoritative name server, compact denial is simpler than white
> lies. But it challenged some assumptions in the code (for instance
> that the rcode, once set, is not changed during processing of the
> request) and, in the case of Drink, required changes in several
> places. The code is in the branch compact-denial
> <
> https://framagit.org/bortzmeyer/drink/-/tree/compact-denial?ref_type=heads
> >.


Thanks! I've implemented it in my prototyping server too, and agree
it wasn't that hard. The bulk of the work was implementing online signing.
If you already have that, implementing the Compact DoE bits is fairly
simple.

( https://github.com/shuque/adns_server )

Shumon.