Re: [DNSOP] Compact DoE sentinel choice

[Paul Vixie]

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

[Viktor Dukhovni]

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

[Brian Dickson]

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

[Viktor Dukhovni]

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

[Shumon Huque]

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

[Viktor Dukhovni]

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] Questions on DNS HTTPS/SVCB spec and deployment

[Tommy Pauly]

> 
> I don't know much about the state of client implementations.


Regarding client implementations, for the one we use on iOS/macOS/etc, we built 
this into our happy eyeballs algorithm — so as we receive addresses from the 
hints in SVCB, and A, and , we add them to our list that we are racing 
various attempts based on. If we get the hints first, we’ll start trying with 
those, but will add in the other answers as they come and use them if needed.

Thanks,
Tommy

> --Ben Schwartz
> From: DNSOP mailto:dnsop-boun...@ietf.org>> on 
> behalf of Hongying Dong  >
> Sent: Monday, July 24, 2023 1:13 PM
> To: dnsop@ietf.org   >
> Subject: [DNSOP] Questions on DNS HTTPS/SVCB spec and deployment
>  
> Hello,
> We are researchers at the University of Virginia studying some aspects of the 
> DNS HTTPS/SVCB specification and how it is deployed in practice. We had a few 
> questions we are hoping you can provide the answers to. Primarily we are 
> examining HTTPS right now, but if the answers can be generally provided for 
> SVCB too, that would be great.
> * IPv4 and IPv6 hints.
> The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use 
> to reach the service.  If A and  records for TargetName are locally 
> available, the client SHOULD ignore these hints. Otherwise, clients SHOULD 
> perform A and/or  queries for TargetName as in Section 3, and clients 
> SHOULD use the IP address in those responses for future connections.  Clients 
> MAY opt to terminate any connections using the addresses in hints and instead 
> switch to the addresses in response to the TargetName query.  Failure to use 
> A and/or  response addresses could negatively impact load balancing or 
> other geo-aware features and thereby degrade client performance.
> It seems to us that unless the IPv4 and IPv6 hints are kept diligently in 
> sync with the actual addresses in the A and  records, this could easily 
> pose operational problems in the field. The draft appears to concur and says 
> clients should see if they are "locally available", and otherwise "SHOULD" 
> perform A/ address lookups. If so, under what circumstances is it 
> beneficial for an implementation to follow the "MAY" instruction of the first 
> line in the above quoted paragraph and use the hints?
> Also what does "If the A and  records for Targetname are _locally 
> available_" mean? Is the expectation that HTTPS client applications run a 
> local DNS cache from which this information could be extracted?
> The  answer to the "MAY use hints" is suggested later on in this paragraph:
> These parameters are intended to minimize additional connection latency when 
> a recursive resolver is not compliant with the requirements in Section 4, and 
> SHOULD NOT be included if most clients are using compliant recursive 
> resolvers.
> First, how would a client application generally know that a recursive server 
> is compliant with Section 4 (i.e. proactively fetching the A and  records 
> for the HTTPS Targetname and providing them in the response)? Is there a 
> proposed DNS API function that provides this information, or are clients 
> expected to write custom code to parse the full response from a recursive 
> server to figure this out? Second, how would a service operator publishing 
> HTTPS records know if most of their clients are using compliant recursive 
> servers to help them make a decision about including IP hints? Or does this 
> statement imply that everyone should deploy IP hints until the ecosystem has 
> gained a critical mass of recursive servers that are compliant?
> What recursive servers today support this optimization? We've examined 
> several of the public DNS resolvers (Google, Cloudflare, Quad9, and OpenDNS) 
> and none of them appear to. We haven't looked at the open source 
> implementations yet, but if anyone can answer that would be appreciated too.
> Client implementation behavior in the field: What do existing web 
> browsers/clients (e.g. Firefox, Chrome, Safari, etc) that support DNS HTTPS 
> records do today? Under what conditions do they use the hints vs. query 
> explicitly for address records?
> 
> Thank you so much!
> Hongying
> 
> -- 
> Hongying Dong
> Ph.D. Candidate in Computer Engineering
> University of Virginia
> ___
> 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

[Shumon Huque]

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

[Viktor Dukhovni]

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

[Shumon Huque]

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

[Viktor Dukhovni]

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] [Last-Call] Dnsdir last call review of draft-ietf-dnsop-zoneversion-02

[Joe Abley]

On Tue, Jul 25, 2023 at 11:56, Abdussalam Baryun 
<[abdussalambar...@gmail.com](mailto:On Tue, Jul 25, 2023 at 11:56, Abdussalam 
Baryun < wrote:

> IMHO, the doc does make changes to two RFCs which are normative, so this LC 
> document should update RFC1035 and RFC 6891. If you agree please mention that 
> in the document.

I may have missed something, but I don't think this document updates 1035 or 
6891.

Joe

>>___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] Dnsdir last call review of draft-ietf-dnsop-zoneversion-02

[Abdussalam Baryun]

IMHO, the doc does make changes to two RFCs which are normative, so this LC
document should update RFC1035 and RFC 6891. If you agree please mention
that in the document.

AB

On Tue, Jul 25, 2023 at 11:17 AM Nicolai Leymann via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Nicolai Leymann
> Review result: Ready with Nits
>
> I am the designated DNS Directorate reviewer for
> draft-ietf-dnsop-zoneversion.
> The draft is well written and defines an EDNS option which can be used for
> debugging purposes.
>
> In general I think the draft is ready for publication.
>
> Nits:
> During the WGLC there were a some discussions on the -02 version of the
> document to clarify a few details in wording. I have not seen any update
> to the
> document and it might be useful to check if those comments need to be
> addressed.
>
> The size of an "unsigned decimal integer" is not defined (see rfc6891).
>
> It might be useful to extend some of the abbrevation if they are used the
> first
> time (e.g., meaning of RR, SOA, ... depends on context).
>
>
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Dnsdir last call review of draft-ietf-dnsop-zoneversion-02

[Nicolai Leymann via Datatracker]

Reviewer: Nicolai Leymann
Review result: Ready with Nits

I am the designated DNS Directorate reviewer for draft-ietf-dnsop-zoneversion.
The draft is well written and defines an EDNS option which can be used for
debugging purposes.

In general I think the draft is ready for publication.

Nits:
During the WGLC there were a some discussions on the -02 version of the
document to clarify a few details in wording. I have not seen any update to the
document and it might be useful to check if those comments need to be addressed.

The size of an "unsigned decimal integer" is not defined (see rfc6891).

It might be useful to extend some of the abbrevation if they are used the first
time (e.g., meaning of RR, SOA, ... depends on context).


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop