On Thu, Jul 27, 2023 at 2:49 PM Brian Dickson <brian.peter.dick...@gmail.com> wrote:
> > > On Tue, Jul 25, 2023 at 10:59 PM Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > >> 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. >> > > Never mind, I was wrong. Please ignore. (non-apex BNAME might have been a good thing, combining CNAME+DNAME). Brian > Hmmm... I think I have a solution (which is an even uglier hack), which > does all of the above PLUS the nothing-below semantics (I think). > The added bonus is it lowers the bar for auth implementers (I think?). > It goes against the letter of rfc4592, but because the target is intended > to be an empty zone, the coherence problem becomes moot. > > The idea is to add to each zone served by the CDoE provider, the following > record (relative to the owner name of the zone): > * DNAME signed_providers_own_empty_zone.example > > This still has the single signature benefit. > It's cacheable. > The cost of also returning the empty zone SOA denying all children (plus > signatures) gets to be amortized over all the responses from each resolver > (modulo TTL obviously). > Since the DNAME targets always result in NXDOMAIN, the signal is preserved > (or resurrected). > Since the results are ALWAYS going to be NXDOMAIN no matter how resolvers > do the rewriting, the incoherence is moot. > It has the side effect of generating CNAMEs too, I think, so fully > backward compatible to anything really ancient. > Yes, it is incredibly ugly and hacky. > And yes, I managed to drag DNAME into one of my wonky solutions. :-) > > But seriously, I think it might be workable, if the CDoE implementers can > live with it (or can generate those on-the-fly). > The add-to-zone method avoids needing to write any software, and reduces > the signatures needed in answers, so possibly even of use to the non-CDoE > situations. > > Brian > > >> >> 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 >> >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
