On Tue, Jul 25, 2023 at 10:59 PM Viktor Dukhovni <[email protected]> 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. > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
