> On Tue, Dec 10, 2024 at 9:39 AM Paul Hoffman <paul.hoff...@icann.org>
wrote:
> [ replying to Mukund Sivaraman <m...@mukund.org> ]
> Given that the IETF just started an IETF-wide last call, it is
inappropriate > to send messages about the draft just to DNSOP. The
instructions in the last > call message describe where the messages should
be sent:
>
> Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2024-12-23. Exceptionally, comments
may
> be sent to i...@ietf.org instead. In either case, please retain the
beginning
> of the Subject line to allow automated sorting.
>
> If a thread about the draft happens only here in DNSOP, that excludes the
rest of the IETF.
I was waiting for Mukund to re-post his note to the IETF last-call list,
but since that didn't happen and now that the last-call has ended, I'll
make some quick remarks here ...
Several of the comments have already been discussed in detail during
normal working group and IETF meeting deliberations, so I'll focus on the
more salient ones. (Since you say you haven't followed the working group
in a while, you may want to look back through the mailing list archives.
There are several hundred messages related to this draft over the past
2 years.)
> On Mon, Dec 9, 2024 at 11:21 PM Mukund Sivaraman <m...@mukund.org> wrote:
>
> The authors should clearly state that this draft breaks existing DNS
> behavior and returns NOERROR (NODATA) where NXDOMAIN should be returned,
> and that is why there are these operational implications. I strongly
> suggest including such text that states the issue clearly.
The doc already clearly states that the protocol returns NODATA instead
of NXDOMAIN. There has been lots of prior discussion about whether a
stronger statement needs to be made about negative impacts, but there did
not appear to be support for that. The text reflects the current consensus
of the working group. Feel free to bring it up again on list and see you
can get consensus for a stronger statement, but it's a bit late in the
game for that.
> [snip]
>
> > Protocol optimizations that permit DNS resolvers to synthesize
> > NXDOMAIN responses, like [RFC8020] and [RFC8198], cannot be realized
> > with zones using Compact Denial of Existence. In general, no online
> > signing scheme (including this one) that employs minimally covering
> > NSEC records permits RFC 8198 style NXDOMAIN synthesis.
> > Additionally, this protocol also precludes RFC 8020 style NXDOMAIN
> > synthesis for DNSSEC enabled responses.
>
> Is the use of RFC 8198 fine with traditional "covering" NSEC responses
> from a zone which also returns compact responses of this draft for
> different queries, if some implementation wants to do it? Is there
> anything in the protocol that prevents mixed ("covering" as well as this
> draft's "compact" scheme) NSEC answers from a single zone? The above
> text says "cannot be used with zones", perhaps it can be rewritten to:
>
I think this is already addressed with the phrase "with zones using
Compact Denial of Existence".
(In theory yes, the same zone could be using a mixture of compact and
non-minimal NSEC, but I'm not aware of anyone doing this in the same
implementation or provider. It does happen more frequently in multi-provider
scenarios where one provider uses traditional nsec/nsec3 and the other uses
compact DOE.)
> ".. cannot be realized from Compact Denial of Existence responses."
>
> [snip]
>
> > 7. Implementation Status
>
> > Cloudflare, NS1, and Amazon Route53 currently implement the Compact
> > Denial of Existence method.
>
> This current draft appears to be deployed e.g. by Cloudflare, which
> trickles down from my resolver as a NOERROR with TYPE128 in the NSEC
> bitmap:
Cloudflare and NS1 currently.
> This signalling is a little unexpected/confusing even to a human who is
> expecting an NXDOMAIN rcode. The software will be updated to convert the
> TYPE128 to the mnemonic NXNAME, but still, the syntax of the message is
> non-intuitive. There may not be a way to do anything about this other
> than rewrite the RCODE, or display a message near the RCODE that this is
> indeed an NXDOMAIN response.
See the section in the draft that discusses RCODE restoration.
> > 8. Security Considerations
>
> [snip]
>
> > scheme will help recover NXDOMAIN visibility for these tools. Note
> > that the DNS header is not cryptographically protected, so the
> > response code field cannot be authenticated. Thus inferring the
> > status of a response from signed data in the body of the DNS message
> > is actually more secure. These tools could be enhanced to recognize
> > the (signed) NXNAME signal.
>
> The signed NXNAME signal appears to be a side-effect of this design,
> rather than a desired requirement. The way this text is written
> describes the advantage, but the big disadvantage is that it breaks
> existing behavior.
> [snip]
>
> At a high level, it is uncomfortable that such changes to the DNS
> protocol be merged that change existing basic behavior (removing an
> important signal such as NXDOMAIN in existing protocol that deployed
> implementations use, requiring updation of at least resolvers to
> implement NXNAME -> rcode=NXDOMAIN to "fix" things). Yet this draft is
> in last call, which may imply most people here are ok with it.
>
> IMO, as a general guideline this sort of change should be discouraged
> though I concede in specific cases behavioral changes to DNS protocol
> may be necessary. Are this draft's proposed changes necessary for DNS?
See my previous remark about making stronger statements about negative
impacts.
In my view, I don't think the proposed changes were actually necessary.
However this protocol is already widely deployed in the field, so that
argument is moot. The IETF work here is attempting to improve the
protocol and reduce its negative effects by restoring NXDOMAIN visibility
in a different way.
> On Mon, Dec 9, 2024 at 11:44 PM Mukund Sivaraman <m...@mukund.org> wrote:
> One more question: Is it necessary to add section 4.1 Signaled Response
> Code Restoration? A client that knows to set CO=1 can instead use
> NXNAME from the NSEC bitmap to rewrite the rcode for its use.
The signaled RCODE restoration mechanism is intended to help clients
and diagnostic software that are oblivious to NXNAME and can only
inspect the RCODE field.
Shumon.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
