Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misc #3

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Misc #3

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 8 additions & 16 deletions draft-ietf-dnsop-compact-denial-of-existence.xml
View file
Open in desktop
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason behind changing MUST to SHOULD here and in the next difference, about NSEC/RRSIG at an owner name that has no other records?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current text says "MUST", which is an "absolute requirement". Right after, it has an exception. I think this is better expressed via "SHOULD" followed by an explanation of "valid reasons in particular circumstances to ignore" it. (Quotes from RFC 2119)

Also, if we think there's no interoperability problem in ignoring the MUST, then I think there's limited justification for requiring it.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right, I was only looking at the diff and not the full context. The new context definitely makes SHOULD more warranted.

Original file line number Diff line number Diff line change
Expand Up @@ -348,8 +348,9 @@
<section anchor="rcode" numbered="true" toc="default">
<name>Response Code Restoration</name>
<t>
For non-existent names, implementations should try wherever
possible, to preserve the response code value of 3 (NXDOMAIN).
For non-existent names, implementations SHOULD try, whenever
possible, to use response code 3 (NXDOMAIN), as is consistent with
client expectations when the NXNAME signal is not understood.
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
Expand Down Expand Up @@ -453,17 +454,8 @@
</li>
</ul>
<t>
This paragraph is updated to the following:
This paragraph is removed.
</t>
<ul>
<li>
Bits representing pseudo-types MUST be clear, as they do not appear
in zone data. If encountered, they MUST be ignored upon being read.
There is one exception to this rule for Compact Denial of Existence
(RFC TBD), where the NXNAME pseudo-type is allowed to appear in
responses to non-existent names.
</li>
</ul>
<t>
Note: as a practical matter, no known resolver insists that
pseudo-types must be clear in the NSEC type bitmap, so this
Expand All @@ -490,13 +482,13 @@
</li>
</ul>
<t>
This paragraph is updated to the following::
This paragraph is updated to the following:
</t>
<ul>
<li>
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
An NSEC record (and its associated RRSIG RRset) SHOULD NOT be the only
RRset at any particular owner name. That is, the signing process
MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
SHOULD NOT create NSEC or RRSIG RRs for owner name nodes that were not
the owner name of any RRset before the zone was signed. The main
reasons for this are a desire for namespace consistency between
signed and unsigned versions of the same zone and a desire to reduce
Expand All @@ -512,7 +504,7 @@
</section>
</section>

<section anchor="implementation" numbered="true" toc="default">
<section anchor="implementation" numbered="true" toc="default" removeInRFC="true">
<name>Implementation Status</name>
<t>
Cloudflare, NS1, and Amazon Route53 currently implement the
Expand Down