on "mollify".
Viktor Dukhovni wrote on 2023-07-25 22:59:
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.
as a pattern intended to replace signed nxdomain for those dnssec
authorities with an allergy to responses larger than 512 octets, a
bespoke cname would be a bad thing. however a validly signed cname to
validly signed nonexistent name would be fine, because the rcode in that
case would be 3 in the rdns->stub response. i'm not sure how this would
solve the 512 octet allergy threshold though.
olafur's original reasoning in the CF blog post was that since a client
would take the same next step if it received noerror/nodata as it would
if it received nxdomain, CF would be sending the shorter of these two
apparently equivalent signals. i disagreed, partly because there would
be a second query for A if a query for MX or for AAAA returned
noerror/nodata but not if it returned nxdomain, but mostly because DGA
botnets can be detected in formation by looking at nxdomain storms, but
not by looking at noerror/nodata storms.
any of the proposals that restore unambiguity to the name-doesn't-exist
condition are fine by me. notably, i'd vastly prefer signed nxdomain,
which most dnssec authorities don't have a 512 octet allergy threshold
for, including dnssec authorities who send a _lot_ more nxdomain answers
than any CDN send. however, if that won't be done, let there be an RFC
for some new more complex signal pattern to describe the trifecta of
"nxdomain, nonexistence proof, nonwildcard proof" condition.
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.
very few of the lookups where noerror/nodata vs. nxdomain ambiguity is
problematic are nonterminals. if that's making a solution elusive, feel
free to note that ENTs aren't nonexistent, so Compact DoE doesn't apply.
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.
it would be a hack. but not intolerable if the target wasn't bespoke.
you can get the same caching efficiencies from a per-CDN "Negative
Zone"(*) since it would be receiving CNAME chains from many millions of
customer domains.
(*) https://en.wikipedia.org/wiki/Negative_Zone
So I am disinclined to go there, barring lots of evidence that it
actually satisfies the various motivating use-cases and has broad
support.
be too, but if so it still deserves to be a Road Not Taken in the RFC,
along with a pointer to the wikipedia page above.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
