On Tue, Jul 25, 2023 at 08:19:21PM -0700, Brian Dickson wrote:
> At the name that does not exist, generate and sign (on the fly) a CNAME
> record with RDATA of something like "nxname.empty.as112.arpa" (or something
> functionally equivalent).
Sadly, this reports that the CNAME *target* does not exist, but the name
in question certainly does (it holds a CNAME). This also does not
exclude the existence of subdomains of the name (which NXDOMAIN does,
when one isn't bending over backwards to interoperate with servers that
return NXDOMAIN for ENTs!).
Also, with the target zone unsigned, the response is subject to forgery,
returning real data for the target.
> Only one signature is required, since there is an answer, rather than just
> an NSEC(3) with bitmap.
Does it mollify the folks who want an NXDOMAIN signal? I guess it is
not obviosly worse than an apparent NODATA, and the target could even
be a fixed non-existent name in a suitable zone under control of the
signer, which would have a real (signed) NXDOMAIN proof, avoiding
an unsigned target in as112. But I remain sceptical about the wisdom
of such a design.
> ENTs are distinguishable (they would get the current ENT response of
> NSEC/RRSIG bit map)
Well current, by the book, ENT response is NOT NSEC/RRSIG (unless you
mean current compact denial rule-bending behaviour).
Rather for a standard ENT, we have:
enszzz.example. IN aaa.ent.example. IN NSEC NSEC RRSIG A ...
The ENT is just an ancestor of the "next" name in a covering NSEC
record.
> Am I incorrect in the asserted behavior of such a synthesized CNAME
> (and that it would match the requirements)?
It would be a stretch. Mind you, with a target in globally shared zone,
caching of its non-existence saves followup queries for all zone using
the scheme. If the target is signed and has a long negative TTL,
efficiency is retained, but it we don't get "nothing below" semantics,
and with some auths mixing CNAME and other data, don't even necessarily
conclude there's no other data at the name.
So I am disinclined to go there, barring lots of evidence that it
actually satisfies the various motivating use-cases and has broad
support.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
