Re: [DNSOP] Compact DoE sentinel choice
On Mon, Aug 07, 2023 at 08:51:36PM -0400, Shumon Huque wrote: > Paging this thread back in after a break ... > > > For ENTs, there is no inconsistency, the nameserver can return a signed > > answer with an empty RDATA for the ENTHERE (TBD) rtype. > > > > ; QUESTION: > > ent.example. IN ENTHERE ? > > > > ; ANSWER: > > ent.example. IN ENTHERE "" > > ent.example. IN RRSIG ENTHERE ... > > That's an interesting idea, but it is contrary to our intention to make > ENT (and/or NXNAME) a meta-type, which is defined to not own any > cacheable zone data. How is that going to be understood by extant validators that are unaware of the new meta type code points? Why is the new meta type actually necessary? Would it not be simpler to avoid it, and instead differentiate the two cases by which combination of RRSIG and NSEC is present? In particular how is denial of the metatype itself handled? How should such a denial affect a resolver's cache... The draft should cover all the relevant query scenarios, rather than leave them unspecified. > It also seems to be an unnecessary complication that can be avoided. Another viewpoint is that such new metatypes are unnecessary complications. > My earlier proposal still seems simpler to me: define explicit queries > for ENT/NXNAME to return an NSEC bitmap with only "NSEC RRSIG" > (i.e exclude the meta type). I took a quick look at NS1 just now, and they > already appear to do this for ENT -- I tested a bunch of different resolver > implementations with such queries and they all seem to behave fine. So now the distinction between NXDOMAIN and ENT disappears, and the response supercedes any cached response with the NXNAME signal, and so now clients behind the resolver no longer see NXDOMAIN until the cached entry times out? Is that right??? > (My other suggestion was to treat ENT/NXNAME queries as real > meta-types that should elicit an error - BIND/Unbound appear to return > FORMERR for such types). So resolvers would then need to refuse these queries (return FORMERR or REFUSED) and stubs will have to learn over time to not ask? -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
Paging this thread back in after a break ...
On Tue, Jul 25, 2023 at 8:07 PM Viktor Dukhovni
wrote:
> On Tue, Jul 25, 2023 at 03:39:01PM -0700, Shumon Huque wrote:
>
> > Viktor - your original suggestion was to only define the ENT sentinel
> > instead of NXNAME. How would that solve the problem of systems and
> > applications needing to precisely obtain the NXDOMAIN signal. Resolvers
> > won't then be able to tell whether a NOERROR bitmap of "NSEC RRSIG"
> > is a normal ENT response from a non Compact DoE implementation, or an
> > NXDOMAIN response from a Compact DoE implementation.
>
> For ENTs, there is no inconsistency, the nameserver can return a signed
> answer with an empty RDATA for the ENTHERE (TBD) rtype.
>
> ; QUESTION:
> ent.example. IN ENTHERE ?
>
> ; ANSWER:
> ent.example. IN ENTHERE ""
> ent.example. IN RRSIG ENTHERE ...
>
That's an interesting idea, but it is contrary to our intention to make
ENT (and/or NXNAME) a meta-type, which is defined to not own any
cacheable zone data.
It also seems to be an unnecessary complication that can be avoided.
My earlier proposal still seems simpler to me: define explicit queries
for ENT/NXNAME to return an NSEC bitmap with only "NSEC RRSIG"
(i.e exclude the meta type). I took a quick look at NS1 just now, and they
already appear to do this for ENT -- I tested a bunch of different resolver
implementations with such queries and they all seem to behave fine.
(My other suggestion was to treat ENT/NXNAME queries as real
meta-types that should elicit an error - BIND/Unbound appear to return
FORMERR for such types).
On Thu, Jul 27, 2023 at 11:31 PM Viktor Dukhovni
wrote:
> On Tue, Jul 25, 2023 at 03:39:01PM -0700, Shumon Huque wrote:
>
> > Viktor - your original suggestion was to only define the ENT sentinel
> > instead of NXNAME. How would that solve the problem of systems and
> > applications needing to precisely obtain the NXDOMAIN signal. Resolvers
> > won't then be able to tell whether a NOERROR bitmap of "NSEC RRSIG"
> > is a normal ENT response from a non Compact DoE implementation, or an
> > NXDOMAIN response from a Compact DoE implementation.
>
> I may not have answered Shumon's question in full. The missing
> piece is that "NSEC RRSIG" isn't a "normal ENT response". In
> classic RFC 4035 DNSSEC, ENTs aren't part of the NSEC chain
> (NSEC records are associated only with names that appear as
> explicit nodes in the zone with at least one real RRset).
>
> To prove an ENT, a classic DNSSEC server returns:
>
> strictly-prior-node. IN NSEC descendent-of-ent.
>
> The fact that the next name is a descendent of the ENT, proves the
> existence of the ENT as an empty node.
>
> There are never any "NSEC RRSIG" bitmaps is classic DNSSEC. This
> combination has to mean something special is going on.
For classic "pre-computed" DNSSEC, yes. But we also need to distinguish
these responses from RFC4470 ("by-the-book" online signing) responses.
For empty non-terminals, they will return a minimally covering NSEC record
matching the ENT with a type bitmap of "NSEC RRSIG" -- that is not
distinguishable from a Compact DoE non-existent name response, if the
latter does not provide the NXNAME sentinel.
The NXNAME sentinel also provides the explicit means to implement
the signaled NXDOMAIN rcode restoration mechanism for DO=1 queries
that I mentioned in my IETF117 presentation. (The utility of that proposal
needs to be weighed of course against the additional complexity cost, and
against the possibility of misc software being updated to directly recognize
the NXNAME meta-type signal instead).
Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
On Tue, Jul 25, 2023 at 03:39:01PM -0700, Shumon Huque wrote: > Viktor - your original suggestion was to only define the ENT sentinel > instead of NXNAME. How would that solve the problem of systems and > applications needing to precisely obtain the NXDOMAIN signal. Resolvers > won't then be able to tell whether a NOERROR bitmap of "NSEC RRSIG" > is a normal ENT response from a non Compact DoE implementation, or an > NXDOMAIN response from a Compact DoE implementation. I may not have answered Shumon's question in full. The missing piece is that "NSEC RRSIG" isn't a "normal ENT response". In classic RFC 4035 DNSSEC, ENTs aren't part of the NSEC chain (NSEC records are associated only with names that appear as explicit nodes in the zone with at least one real RRset). To prove an ENT, a classic DNSSEC server returns: strictly-prior-node. IN NSEC descendent-of-ent. The fact that the next name is a descendent of the ENT, proves the existence of the ENT as an empty node. There are never any "NSEC RRSIG" bitmaps is classic DNSSEC. This combination has to mean something special is going on. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
On Thu, Jul 27, 2023 at 2:49 PM Brian Dickson wrote: > > > On Tue, Jul 25, 2023 at 10:59 PM Viktor Dukhovni > 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
Re: [DNSOP] Compact DoE sentinel choice
On Tue, Jul 25, 2023 at 10:59 PM Viktor Dukhovni 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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
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 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
Re: [DNSOP] Compact DoE sentinel choice
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
Re: [DNSOP] Compact DoE sentinel choice
On Tue, Jul 25, 2023 at 3:39 PM Shumon Huque wrote: > On Tue, Jul 25, 2023 at 11:28 AM Viktor Dukhovni > wrote: > >> On Tue, Jul 25, 2023 at 10:43:25AM -0700, Shumon Huque wrote: >> >> > Ok, yes, I understand now, thanks. An NXNAME ignorant validator >> > will treat a response to a query for the NXNAME type specifically >> > as bogus, and could spray a bunch of follow-on queries to other >> > servers for the zone before giving up and returning SERVFAIL. >> > >> > If the Compact DoE authority is specially defined to return only >> > "NSEC RRSIG" in the type bitmap for explicit NXNAME queries >> > for a non-existent name, doesn't that solve the problem? >> >> Yes, that could solve the problem, though NXNAME-aware resolvers would >> need a somewhat tricky cache state, that holds and returns: >> >> - The NSEC record with the "NSEC RRSIG NXNAME" bitmap for most >> RTYPEs >> - The "NSEC RRSIG" bitmap if explicitly asked for NXNAME. >> >> The draft should describe the behaviour expected from auth servers, >> and validating resolvers, including their responses upstream. >> > > Yes, we could certainly do that. > > >> To me a single signed record that proves NXDOMAIN regardless of the >> query RTYPE sure looks simpler! The above is noticeably kludgier. >> > > My preference would be to try to make this issue irrelevant by having > DNS servers treat meta-types specially and return an error, or at least, > in the case of resolvers, not cache any responses received for them. > > One challenge is that there isn't a unique range that identifies metatypes. > Range 128 - 255 seems to unfortunately be for both meta-types and > q-types. > I did a quick test of BIND and Unbound just now - they return FORMERR > for almost all of this range, but respond to specific q-types they support > (IXFR/AXFR/*). > > And then, there is the issue of the period of time where we are using > private RR type codes. There is no meta-type subset range in there that > is treated differentially. > > Viktor - your original suggestion was to only define the ENT sentinel > instead of NXNAME. How would that solve the problem of systems and > applications needing to precisely obtain the NXDOMAIN signal. Resolvers > won't then be able to tell whether a NOERROR bitmap of "NSEC RRSIG" > is a normal ENT response from a non Compact DoE implementation, or an > NXDOMAIN response from a Compact DoE implementation. > > >> Especially simple would be using just distinct combinations of >> "NSEC" and "RRSIG" for NXDOMAIN vs ENT, with no new sentinel >> types, provided resolvers can gracefully handle bare-bones >> bitmaps that include a proper subset of "NSEC RRSIG". >> > > I think that suggestion would need detailed testing and also possible > arguments with DNSSEC protocol correctness people. The NSEC > record is designed to prove its own existence and is required to have > NSEC and RRSIG in its type bitmap if I recall. > So, to recap the requirements that this is attempting to provide a solution for: - Online signers want to be able to provide a response for names that don't exist, in signed zones, without doing NXDOMAIN (which requires 2-3 signatures) - Some current implementations don't either provide answers that don't give clear distinction between NXDOMAIN and ENT - Other current implementations provide bitmaps in NSEC(3) records that claim types exist when they do not - The goal is to give answers that work for both CDoE and regular offline-signed zones, and permit distinguishing ENT from NXDOMAIN, and where CDoE signers only need to generate one signature. The non-NXDOMAIN answer is problematic already, I believe. What if it were possible to provide a solution to all of those requirements, AND give resolvers an actual cacheable NXDOMAIN? It's ugly, it's a kludge, it will likely be shouted down, but I think there is one method that could work. 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). Only one signature is required, since there is an answer, rather than just an NSEC(3) with bitmap. The target of the CNAME is out of bailiwick, so the resolver would need to obtain that, and get the NXDOMAIN result from that response (which results in NXDOMAIN to the client). All of these are cacheable. If/when empty.as112.arpa is signed, the full chain would be protected by DNSSEC. ENTs are distinguishable (they would get the current ENT response of NSEC/RRSIG bit map) Am I incorrect in the asserted behavior of such a synthesized CNAME (and that it would match the requirements)? (It's not a DNAME, but is kind of close to it. :-) ) Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
On Tue, Jul 25, 2023 at 03:39:01PM -0700, Shumon Huque wrote: > Viktor - your original suggestion was to only define the ENT sentinel > instead of NXNAME. How would that solve the problem of systems and > applications needing to precisely obtain the NXDOMAIN signal. Resolvers > won't then be able to tell whether a NOERROR bitmap of "NSEC RRSIG" > is a normal ENT response from a non Compact DoE implementation, or an > NXDOMAIN response from a Compact DoE implementation. For ENTs, there is no inconsistency, the nameserver can return a signed answer with an empty RDATA for the ENTHERE (TBD) rtype. ; QUESTION: ent.example. IN ENTHERE ? ; ANSWER: ent.example. IN ENTHERE "" ent.example. IN RRSIG ENTHERE ... While for other RTYPEs: ; QUESTION: ent.example. IN A ? ; AUTHORITY: example. IN SOA ... example. IN RRSIG SOA ... ent.example. IN NSEC \000.ent.example. NSEC RRSIG ENTHERE ent.example. IN RRSIG NSEC ... -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
On Tue, Jul 25, 2023 at 11:28 AM Viktor Dukhovni wrote: > On Tue, Jul 25, 2023 at 10:43:25AM -0700, Shumon Huque wrote: > > > Ok, yes, I understand now, thanks. An NXNAME ignorant validator > > will treat a response to a query for the NXNAME type specifically > > as bogus, and could spray a bunch of follow-on queries to other > > servers for the zone before giving up and returning SERVFAIL. > > > > If the Compact DoE authority is specially defined to return only > > "NSEC RRSIG" in the type bitmap for explicit NXNAME queries > > for a non-existent name, doesn't that solve the problem? > > Yes, that could solve the problem, though NXNAME-aware resolvers would > need a somewhat tricky cache state, that holds and returns: > > - The NSEC record with the "NSEC RRSIG NXNAME" bitmap for most > RTYPEs > - The "NSEC RRSIG" bitmap if explicitly asked for NXNAME. > > The draft should describe the behaviour expected from auth servers, > and validating resolvers, including their responses upstream. > Yes, we could certainly do that. > To me a single signed record that proves NXDOMAIN regardless of the > query RTYPE sure looks simpler! The above is noticeably kludgier. > My preference would be to try to make this issue irrelevant by having DNS servers treat meta-types specially and return an error, or at least, in the case of resolvers, not cache any responses received for them. One challenge is that there isn't a unique range that identifies metatypes. Range 128 - 255 seems to unfortunately be for both meta-types and q-types. I did a quick test of BIND and Unbound just now - they return FORMERR for almost all of this range, but respond to specific q-types they support (IXFR/AXFR/*). And then, there is the issue of the period of time where we are using private RR type codes. There is no meta-type subset range in there that is treated differentially. Viktor - your original suggestion was to only define the ENT sentinel instead of NXNAME. How would that solve the problem of systems and applications needing to precisely obtain the NXDOMAIN signal. Resolvers won't then be able to tell whether a NOERROR bitmap of "NSEC RRSIG" is a normal ENT response from a non Compact DoE implementation, or an NXDOMAIN response from a Compact DoE implementation. > Especially simple would be using just distinct combinations of > "NSEC" and "RRSIG" for NXDOMAIN vs ENT, with no new sentinel > types, provided resolvers can gracefully handle bare-bones > bitmaps that include a proper subset of "NSEC RRSIG". > I think that suggestion would need detailed testing and also possible arguments with DNSSEC protocol correctness people. The NSEC record is designed to prove its own existence and is required to have NSEC and RRSIG in its type bitmap if I recall. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
On Tue, Jul 25, 2023 at 10:43:25AM -0700, Shumon Huque wrote: > Ok, yes, I understand now, thanks. An NXNAME ignorant validator > will treat a response to a query for the NXNAME type specifically > as bogus, and could spray a bunch of follow-on queries to other > servers for the zone before giving up and returning SERVFAIL. > > If the Compact DoE authority is specially defined to return only > "NSEC RRSIG" in the type bitmap for explicit NXNAME queries > for a non-existent name, doesn't that solve the problem? Yes, that could solve the problem, though NXNAME-aware resolvers would need a somewhat tricky cache state, that holds and returns: - The NSEC record with the "NSEC RRSIG NXNAME" bitmap for most RTYPEs - The "NSEC RRSIG" bitmap if explicitly asked for NXNAME. The draft should describe the behaviour expected from auth servers, and validating resolvers, including their responses upstream. To me a single signed record that proves NXDOMAIN regardless of the query RTYPE sure looks simpler! The above is noticeably kludgier. Especially simple would be using just distinct combinations of "NSEC" and "RRSIG" for NXDOMAIN vs ENT, with no new sentinel types, provided resolvers can gracefully handle bare-bones bitmaps that include a proper subset of "NSEC RRSIG". -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
On Tue, Jul 25, 2023 at 8:42 AM Viktor Dukhovni wrote: > On Tue, Jul 25, 2023 at 07:35:41AM -0700, Shumon Huque wrote: > > > > 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. > > > > > > > For (a), apart from some mental incongruity, what practical > > operational problem do you see this causing? I am not seeing one, but > > I'd be happy to be educated. > > If the query is actually for the NXNAME rtype, the NSEC response is > bogus, because the bitmap promises the requested RTYPE, but the response > is NODATA (sentinel NXDOMAIN). Existing resolvers will servfail and > perhaps try a few more servers. There's also no correct response to > an upstream client that send DO=1. > > > The (proposed) response is: > > > >nxdomain.example. NSEC NSEC RRSIG NXNAME > > It is fine if the qtype is "A", "", "HTTPS", "MX", ... but not > when the qtype is the new NXNAME type. > Ok, yes, I understand now, thanks. An NXNAME ignorant validator will treat a response to a query for the NXNAME type specifically as bogus, and could spray a bunch of follow-on queries to other servers for the zone before giving up and returning SERVFAIL. If the Compact DoE authority is specially defined to return only "NSEC RRSIG" in the type bitmap for explicit NXNAME queries for a non-existent name, doesn't that solve the problem? Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
On Tue, Jul 25, 2023 at 07:35:41AM -0700, Shumon Huque wrote: > > 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. > > > > For (a), apart from some mental incongruity, what practical > operational problem do you see this causing? I am not seeing one, but > I'd be happy to be educated. If the query is actually for the NXNAME rtype, the NSEC response is bogus, because the bitmap promises the requested RTYPE, but the response is NODATA (sentinel NXDOMAIN). Existing resolvers will servfail and perhaps try a few more servers. There's also no correct response to an upstream client that send DO=1. > The (proposed) response is: > >nxdomain.example. NSEC NSEC RRSIG NXNAME It is fine if the qtype is "A", "", "HTTPS", "MX", ... but not when the qtype is the new NXNAME type. > If a resolver caches this, what problems can it cause? As a response to typical queries it is fine, but not as a response to an NXNAME query (bogus). > Even in the case of Aggressive negative cachers that perform type > inference, there is no actual data type whose existence could be > denied and lead to problems. Sure there is, the NXNAME type. > There is one other possible advantage to the NXNAME sentinel. It makes > the ENT response from both Compact DoE and RFC 4470 online signers > uniform (NODATA + type bitmap: RRSIG NSEC). My read of 4470 is that the server is supposed to return a *covering* record where neither endpoints is the denied name. ens.example. IN NSEC \000.ent.example. NSEC RRSIG This is because an ENT is not "instantiated name". However, 4470 fails to give concrete examples or advice of how to report ENTs. > There is no way to make the NXDOMAIN response uniform of course, but > at least there is some uniformity that was recovered. Again, as a > practical matter, I'm not sure how compelling this observation is > either (in terms of actual operational issues). To me, "uniformity" is less important than logical consistency, and putting an RTYPE other than NSEC or RRSIG in an NXDOMAIN response creates a logically inconsistent status for the sentinel RTYPE. How are authoritative servers supposed to respond to queries for that RTYPE??? How are existing resolvers supposed to handle that response? -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
On Mon, Jul 24, 2023 at 1:55 PM Viktor Dukhovni wrote: > 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. > Viktor, For (a), apart from some mental incongruity, what practical operational problem do you see this causing? I am not seeing one, but I'd be happy to be educated. The (proposed) response is: nxdomain.example. NSEC NSEC RRSIG NXNAME If a resolver caches this, what problems can it cause? Even in the case of Aggressive negative cachers that perform type inference, there is no actual data type whose existence could be denied and lead to problems. (The main operational issue I see is the more general one that already exists, unrelated to what sentinel we choose - NODATA for NXDOMAIN leads to unnecessary follow-on queries for other types at the same name. That issue can only be solved with rcode substitution or stub resolver code enhanced to recognize these sentinels). When we get a formal allocation for a meta-type for NXNAME (or ENT), servers could recognize that fact and return an error or at least refuse to cache (because it's not a data type or query type). I think there are implementations in the field that already deal with meta-types received in DNS queries in this way. There is one other possible advantage to the NXNAME sentinel. It makes the ENT response from both Compact DoE and RFC 4470 online signers uniform (NODATA + type bitmap: RRSIG NSEC). There is no way to make the NXDOMAIN response uniform of course, but at least there is some uniformity that was recovered. Again, as a practical matter, I'm not sure how compelling this observation is either (in terms of actual operational issues). Shumon ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
On Mon, Jul 24, 2023 at 07:08:29PM -0700, Brian Dickson wrote: > I believe there are three potential query/answer things that on-line > signers want to compactly respond to: > >1. Name exists, other types exist, queried type does not exist >2. Name exists, no types exist (ENT), queried type does not exist >3. Name does not exist > > What if, rather than a response that needs inference for (3), an explicit > response is provided, in the form of a signed record? > It might not ever need to occur in an NSEC bitmap, since the name itself > doesn't exist. > > For NXDOMAIN, respond with an actual NXNAME (no RDATA) and corresponding > RRSIG. The issue with that is that this is not the RTYPE in the query, and the response is therefore bogus/irrelevant from the perspective of legacy validating resolvers. This would require all validating resolvers to implement the NXNAME rtype as a new valid authenticated denial of existence signal, so the adoption path is noticeably more complex. Perhaps (interoperability permitting, TBD) another option is to send an empty type bitmap for one of NXDOMAIN vs. ENT and NSEC + RRSIG for the other, this involves no new RTYPEs, just a different "shape" answer. More generally, any two distinct bitmap choices from: - Empty - Just NSEC - Just RRSIG - Both NSEC and RRSIG -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Compact DoE sentinel choice
On Mon, Jul 24, 2023 at 1:55 PM Viktor Dukhovni wrote: > 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. > This "b" proposal is definitely prefered for all the reasons Viktor outlined. However, I had a thought about NSEC(3) bitmaps vs actual RRs. Since the compact responses are created and signed on-the-fly, there may be more explicit ways of signaling NXDOMAIN. I haven't thought this through completely, so it may be wrong or a really bad idea, but it might be worth thinking about and/or testing if it isn't totally wacky. I believe there are three potential query/answer things that on-line signers want to compactly respond to: 1. Name exists, other types exist, queried type does not exist 2. Name exists, no types exist (ENT), queried type does not exist 3. Name does not exist What if, rather than a response that needs inference for (3), an explicit response is provided, in the form of a signed record? It might not ever need to occur in an NSEC bitmap, since the name itself doesn't exist. So, for ENT, respond with "b" per Viktor (sentinel bitmap) For NXDOMAIN, respond with an actual NXNAME (no RDATA) and corresponding RRSIG. And for clarity, this would only be sent by an auth server doing compact DoE. Any other server doing offline signing would never *need* to send NXNAME records (but in theory, could, in addition to the normal NXDOMAIN response.) To explain the logic here: I'm borrowing this from DNAME, which provides DNAME (signed) plus CNAME (unsigned) to handle the backward compatibility issues in case the client does not understand DNAME. In the case of DNAME, DNAME is a (significant) optimization, is signed and validatable and cacheable; it is clearly preferable that the client understand and use DNAMEs if they exist. But, it is still only an optimization, as the legitimate (but unsigned) CNAME response is included. The reverse would be true for NXNAME: A client that didn't know about NXNAME would still be able to infer the NXDOMAIN (assuming it had the proper logic implemented). A client that knows about NXNAME might be able to use and cache that response with less work. I think the backward compatibility (if I am correct, and it tests true) would mean this could be unilaterally be deployed by auth servers immediately, avoiding any chicken/egg or critical mass problems. NB: *lack* of NXNAME does not automatically promote a name into existence. NXNAME is merely a shortcut to avoid inferences and extra work by signers and resolvers. Thoughts? Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
