In today's session we had some discussion of the choice of sentinel
RTYPEs for ENTs vs. NXDOMAIN.
There isn't much in the meeting to cover the fine details of various
alternatives, so I hope a followup message will make my comments more
clear.
1. I am all in favour of distinguishing NXDOMAIN from ENT. This is
a reasonable prerequisite for any proposal.
2. That said, there are multiple ways to *distinguish* ENT vs. NXDOMAIN
responses:
a. Sentinel RTYPE for NXDOMAIN with just NSEC + RRSIG for ENT.
b. Sentinel RTYPE for ENT with just NSEC + RRSIG for NXDOMAIN.
c. Distinct sentinel RTYPEs for both ENTs and NXDOMAIN.
Presently, the draft is proposing option "a". My point is that with "a"
we get a response that is promising the existence of an RRset for a name
that does not exist:
Q: nxdomain.example. IN NXNAME ?
A: ???
- How should such a query be answered? How should the answer be cached?
- How is denial of existence of that RRset validated by legacy resolvers?
It is far from clear that there's a clean/consistent answer to the above
questions.
On the other hand, with "b", we can still distinguish NXDOMAIN from ENT,
because NSEC records with just "NSEC RRSIG" in the type bitmap are not
valid for ENTs. Once the providers currently "abusing" this response
form also for NXDOMAIN adopt the final spec, the ambiguity goes away.
And, in this, it is possible to answer queries for the ENT sentinel
RTYPE, by returning an associated empty RDATA and RRSIG that can be
cached. The ENT is then a bit less "empty" than before, but the
resulting state is consistent.
Q: enthere.example. IN ENTNAME ? ;
A: enthere.example. IN ENTNAME "" ; Zero-length RDATA
enthere.example. IN RRSIG ENTNAME ...
The result can be cached, and it is not inconsistent with the existence
of the node as an (almost) empty non-terminal.
The compact version of an ENT gains a additional RRset, but this can be
validated by legacy resolvers with no issues.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
