Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-dane-03.txt

[Viktor Dukhovni]

> On 29 Nov 2023, at 1:14 pm, Ben Schwartz  wrote:
> 
> This draft is essentially identical to -02 except for the new Appendix A, 
> which discuss the impact of Unknown Key-Share Attacks: 
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-dane-03#name-unknown-key-share-attacks
> 
> I would appreciate more review on that section, which attempts a fairly 
> tricky security analysis.
> 
> Otherwise, I believe this draft is ready for WGLC (except for the 
> Acknowledgements section, which still needs to be filled in).

Thanks for this work.  I have read the draft and on an initial read-through,
only found a trivial editorial nit:

Section 5.2, second paragraph:

s/To prevents the above .../To prevent the above .../

Otherwise, the text looks good.  That said, indeed Appendix A deserves more 
care than
an initial read-through.

Do you know whether the requirements of 
https://www.rfc-editor.org/rfc/rfc9110#section-7.4
essentially universally supported by HTTPS (1.1 or later) servers?  Or is a 
non-trivial,
perhaps significant, minority of servers that would be vulnerable to UKS 
despite section 7.4?

The non-HTTPS protocols are easier to reason about, and for these I don't 
expect to need to
search for unexplored corner cases.

-- 
Viktor.

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

Re: [DNSOP] Compact DoE sentinel choice

[Viktor Dukhovni]

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] [Ext] Compact DoE sentinel choice

[Viktor Dukhovni]

On Thu, Jul 27, 2023 at 03:04:37AM +, Edward Lewis 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:
> 
> Launching off this observation (and realizing there's a whole thread
> following it), I wanted to register some discomfort with this
> approach.

It is decidedly pragmatic.  Negative responses (NODATA or NXDOMAIN)
require presenting NSEC or NSEC3 RRs to extant resolvers.  Introducing a
new flavour of denial existence would require a fresh batch of DNSSEC
algorithms (just like NSEC3 required adding algorithm 7 to supplment
algorithm 5).  Requiring broad support for a new algorithm would make
CDoE impractical for quite some time.

> #   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
> #   RRset at any particular owner name.  That is, the signing process
> #   MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
> #   the owner name of any RRset before the zone was signed.  The main
> #   reasons for this are a desire for namespace consistency between
> #   signed and unsigned versions of the same zone and a desire to reduce
> #   the risk of response inconsistency in security oblivious recursive
> #   name servers.
>
> What is most significant in that text is the "desire for namespace
> consistency between signed and unsigned versions of the same zone".
> With this proposal providing an answer that says "yes the name exists
> but it doesn't have what you want" contradicts the unsigned response
> that would indicate NXDOMAIN, there is an inconsistency in what is
> seen in the signed and unsigned zone.

That's admirable for pre-signed zones, but for on-the-fly signing with
zones that may not even have a well-defined whole zone point in time
snapshot (loosely coherent, eventually consistent, across various
authoritative copies) that text has little relevance.

> With signing on the fly, that approach makes no sense - you should be
> able to send a tailored response.

The cleanest solution is to use an *EMPTY* type bitmap for NXDOMAIN
responses.  It likely works just fine in extant resolvers.  The apparent
denial of the very NSEC and RRSIG records that evidence the denial of
existence is unlikely to be an issue.  In particular, (and I believe
this to be a feature), even for a qtype "NSEC" query, the answer section
remains empty (the name does not exist), and the type bitmap denies the
existence of the NSEC RRset.

;
; QUESTION
nxdomain.example. IN NSEC ?

; AUTHORITY
example. IN SOA ...
example. IN RRSIG SOA ...

nxdomain.example. IN NSEC \0.nxdomain.example. ; (EMPTY type bitmap)
nxdomain.example. IN RRSIG NSEC ...

The NSEC RRs in the authority section are not answer records, and don't
constitute an answer to the request for the NSEC records associated with
the qname.  It would be greate to see some interop testing of this or a
similar variant of pruned type bitmaps.  We already know that the
unexpected "NSEC RRSIG" is working out OK, can we prune the bitmap even
more?

> A tailored response, i.e., "there's no name matching the QNAME", means
> there's no need to mention the next name.  This would be great - no
> need to sort the zone, no need to assist zone walking, etc.  The NSEC
> record is just not built for that though, it's an entirely ill-fit.

This is entirely impractical with extant algorithm codepoints.

> We have the NSEC record, it's implemented and deployed.  (I'm just not
> considering NSEC3 as it's similar in approach despite it working on
> hashes and not names.)  Rolling out a new approach (say "NSEC17")
> would be an uphill battle (although we did roll out NSEC3...), assumed
> to be more work that force-fitting on-the-fly signing into NSEC.

We rolled out NSEC3 by introducing new algorithm code points, and
eventually these weere widely enough deployed to allow zones to be
signed with 7/8/10/13/14 without being seen as insecure by a significant
fraction of resolvers.  I don't expect CDoE to wait for the ~5 years or
more that this would take.

-- 
Viktor.

___
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.

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] what could we do with 15 unused bits of QDCOUNT?

[Viktor Dukhovni]

On Thu, Jul 27, 2023 at 09:11:33AM +1000, George Michaelson wrote:

> if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in
> the header.

We don't actually have that freedom.  There's no mechanism to make those
bits mean something other than a larger (invalid QDCOUNT) for a normal
query.

> maybe the truth is, we've got 15 bits of zero in the header forever, amen.

This.  There's nothing we can do with the "extra bits" (and even if we
could, that wouldn't better be done with a suitable EDNS(0) extension).

The meaning of the message of course depends on the OPCODE.  A new
OPCODE can bring in new semantics for the rest of the packet.

-- 
Viktor.

___
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

[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

[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] 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

[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

[DNSOP] Compact DoE sentinel choice

[Viktor Dukhovni]

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.

-- 
Viktor.

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

[DNSOP] FYI: Google Public DNS now reports EDEs

[Viktor Dukhovni]

[ I hope a brief "public announcement" is not out of place.
  The same post will shortly also be sent to dns-operations. ]

Google Public DNS (also "dns.google", or, colloquially, "Quad8") now
includes EDEs in most error responses.  For details see:


https://developers.google.com/speed/public-dns/docs/troubleshooting/domains#edes

-- 
Viktor.

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

Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

[Viktor Dukhovni]

On Tue, Jul 11, 2023 at 07:06:49PM +, Hollenbeck, Scott wrote:

> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/
>
> The draft includes descriptions of current known practices and
> suggests that some should be avoided, some are candidates for "best",
> and there are others that haven't been used that might also be
> candidates for "best". The authors would like to learn if others agree
> with our assessments and/or can suggest improvements.

Thanks for reaching out, I'll do my best to share what I hope is a
sensible perspective.  But first some followups to already posted
feedback.

On Tue, Jul 11, 2023 at 03:22:40PM -0700, Brian Dickson wrote:

> For example, the registrar for the domain that is the parent of a host
> entry, should be able to "disavow" a particular reference (delegation
> to said host). It would be the responsibility of the other registrar
> (for the domain being disavowed) to clean up the broken delegations.
> This is basically giving authority to the DNS operator as a party to
> the situation, even if only indirectly.

Just checking the intent here, I think you're saying the "disavowal" is
potentially a case-by-case option.  So that e.g. at the time that DNS
service for a domain is discontinued, the DNS operator (perhaps via
their registrar) should be able to break drop NS records from a
*particular* delegation.

This is an interesting proposal.  It reasonably aligns with the
operational reality that it takes mutual agreement between two parties
to provide working DNS for a domain that isn't self-hosted.

In the DANE/DNSSEC survey, I am tracking almost ~350k zones (out of
~22.8M) with no SEP, roughly half of which are just lame delegations
(the listed servers return "REFUSED"), but for various reasons it is
difficult for the former DNS operator to get the delegations terminated.

The chief difficulty here is that this does not work for "external"
nameserver objects.  If we're really going to solve this problem, the
solution should I think also work for the case when the nameserver and
the client zone live in different registries.

We need a protocol by which such disavowal can happen regardless of
where the nameserver might be found.

Of course if that's too difficult to solve in a timely manner, and we
can reduce barriers in host object management within a registry, that's
fine too, and the larger goal need not hold up progress on the more
focused problem.

> Maybe having the otherwise dangling or otherwise blocking references
> converted to their respective in-bailiwick names might be a solution. E.g.
> if domain2.example had an NS record pointing to ns1.domain1.example, and
> domain1.example were deleted (or ns1.domain1.example were deleted), having
> the reference converted (by whom??) to ns1.domain2.example would suffice.
> But, that would also require picking a new IP address to use for the glue
> for that (new) host object. It's a thorny problem, a real can of worms.

In the most typical situation, the servers in question will have for
some time already discontinued DNS service for the objects to be
removed, and the dependent domain loses nothing (only gains!) from
having the no longer willing nameservers deleted.

Therefore, my take is that the delegation NS record should be simply
removed from the dependent zone.  No renaming, or other steps to paper
over the issue.  Subsequent replacement is up to the owner of the
dependent zone.  Indeed if everything was done optimally, the dependent
delegations would have proactively switched to working nameservers
first.

Now we do want to prevent accidents, and so deletion of host objects
that are still used as nameservers by zones not being deleted should
perhaps require some form of confirmation that some dependencies are
being forcibly broken.  How to do that, and whether confirmation should
actually require the requesting party to submit a second request, ...
is user interface design that should be discussed with care.  I don't
claim to have the right answer on how to balance safety vs. usability.

> This means that unrelated glue records could point at the same IP
> address, even if the host records are distinct with different owners.
> First-to-register does not guarantee that the correct ownership could
> be determined by creation time (i.e.  it's a race condition without a
> stronger mechanism.)

Explicit disavowal should be able to solve this too, if the IP addresses
targetted can be reasonably safely (multiple samples over a period of
time, or a confirmed request from the point of contact for the IP space,
...) determined to be refusing service for the disavowed zones.

So my own position is that:

- The host object owner should be able to delete it at will, with
  any friction solely to help avoid difficult to recover accidents,
  rather than prevent the nameserver owner/operator from
  discontinuing service.

- The dependent zones would then have the corresponding nameserver
  

Re: [DNSOP] draft-dnsop-dnssec-extension-pkix on IETF117 dnsop agenda?

[Viktor Dukhovni]

On Sun, Jul 16, 2023 at 03:06:35PM -0400, Viktor Dukhovni wrote:
> I see that draft-dnsop-dnssec-extension-pkix is included on the IETF117 dnsop 
> agenda.
> 
> https://datatracker.ietf.org/doc/draft-dnsop-dnssec-extension-pkix/
> 
> I haven't seen prior discussion of this item on the list, and,
> personally, rather suspect it unlikely to gain meaningful support from
> the WG and see adoption.
> 
> Would it possible to defer discussion of this document to such time as
> some evidence of support emerges, and in the meantime use the timeslot
> for more realistically productive proposals?

I should perhaps have stated the technical criteria on which I consider
the proposal non-viable.  To whit:

- The proposed protocol lacks all downgrade resistance.
- Without a signed delegation from the parent, the existence of the
  zone apex CERT MRs and associated RRSIGs is trivially denied  by
  an on-path attacker.
- This protocol adds failure modes (CERTs and RRSIGs are available,
  but don't match), without adding any security.

Since the point of DNSSEC is to thwart active attacks, and the protocol
in the proposed draft offers no such protection, I consider it
non-viable.

There are other substantial issues, but the above is sufficient to stop
looking for more reasons why this is a dead-end.

-- 
Viktor.

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

[DNSOP] draft-dnsop-dnssec-extension-pkix on IETF117 dnsop agenda?

[Viktor Dukhovni]

I see that draft-dnsop-dnssec-extension-pkix is included on the IETF117 dnsop 
agenda.

https://datatracker.ietf.org/doc/draft-dnsop-dnssec-extension-pkix/

I haven't seen prior discussion of this item on the list, and,
personally, rather suspect it unlikely to gain meaningful support from
the WG and see adoption.

Would it possible to defer discussion of this document to such time as
some evidence of support emerges, and in the meantime use the timeslot
for more realistically productive proposals?

-- 
Viktor.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-05.txt

[Viktor Dukhovni]

On Mon, Jul 10, 2023 at 03:48:34PM -0700, internet-dra...@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Domain Name
> System Operations (DNSOP) WG of the IETF.
> 
>Title   : DNS Error Reporting
>Authors : Roy Arends
>  Matt Larson
>Filename: draft-ietf-dnsop-dns-error-reporting-05.txt
>Pages   : 11
>Date: 2023-07-10

Some comments on on the -05 update.

* Spelling:  s/unsollicited/unsolicited/

* Substance: The new text suggests using TCP **and** cookies:

   Resolvers that send error reports SHOULD send these over TCP
   [RFC7766] and SHOULD use DNS COOKIEs [RFC7873].  This makes it
   hard to falsify the source address.  The monitoring agent SHOULD
   respond to queries received over UDP with the truncation bit (TC
   bit) set to challenge the resolver to re-query over TCP.

I don't believe it is at all common to combine TCP with cookies,
typically cookies are used over UDP, with fallback to TCP (sans
cookies) if the server's cookie is missing or invalid.

So above should be "either TCP **or** COOKIES".  If error reports are
infrequent no recent cookies will be cached for the monitoring agent,
and obtaining a cookie will require a round trip.  So perhaps simplest
to just use TCP.

I don't yet see any text about rate-limiting of reports beyond per
qname/qtype/info-code caching.  And yet the resolver has significant
additional context:

- The IP address of the problem nameserver.

* It can rate-limit the frequency of reports per nameserver IP.

- The server zone.

* It can rate-limit the frequency of reports per zone.

The per IP limit can be significantly more "generous", than the per-zone
limit, because some nameservers serve O(1M) zones, of which a few
thousand might exhibit a problem, while the server's overall health is
fine.  Reports for many different qnames in the same zone are likely
to be substantially redundant.

-- 
Viktor.

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

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Viktor Dukhovni]

On Mon, Jul 10, 2023 at 10:27:45PM +0100, Roy Arends wrote:

> > Right, but surely the monitoring agent can decide whether to solicit
> > such a prefix label or not.  That is whether an "_er" prefix label is
> > signalled is a *local matter* betweent the authoritative server
> > signalling the option and the monitoring agent.
> 
> I agree that a monitoring agent can specify a domain that may include
> a separator as the least significant label. However, it also requires
> the monitoring agent to understand that it should sometimes include
> this separator, and that it may be redundant at other times.

If all the monitoring agent's "customers" (authoritative servers that
return its "suffix" in the new option) are informed to signal an
"_er.agent.example" name, there's no "sometimes".  The agent, by mutual
agreement with the nameservers it supports can choose whatever suffix
format meets its needs, fixed across all customers, or customer-specific.

I haven't yet seen a reason to insist on a fixed suffix pattern.  The
resolver just stutters back the suffix it was handed by the
authoritative server's extension payload.  What problem does mandating
the least significant label of the suffix solve, that can't be solved by
just signalling the desired suffix, special label and all?

> It assumes that those running the authoritative server that returns
> the agent domain and those that run the reporting agent are in sync.
> Those are a lot of assumptions.

If they're not in sync, surely reporting will be broken, whether or not
an "_er" suffix label is used.

> >  Why should resolvers have to be responsible for this?
> 
> Because this separating label is trivial to include and avoids a lot of 
> hassle.

The hassle in question remains unclear.  I see two relevant/likely
deployment models:

* Self-hosted reporting, directly by the authoritative server:

- Error reports are special by virtue of a dedicated qname
  suffix and perhaps qtype.

- No special coördination required, the server both publishes
  and consumes the error reporting suffix.

 * Outsourced/centralised reporting, via server IPs dedicated to
   error report processing.

 - Here again no need for "_er", because all queries are
   presumptively error reports, and if the signal from the
   "customer" auth server was wrong (whether or not an "_er"
   label is included) the error report will not be handled
   correctly.

  - If the signal has the correct (mutually agreed) suffix,
again no problem.

  - And of course the monitoring agent can specify the use
of "_er" (or whatever) if that's convenient.

What use-case actually benefits from the "_er" LSL (least-significant
label) in the signal?  How is this benefit not obtained by mutual
agreement between the monitoring agent and its customers?

> >> The sole purpose of the leading “least-significant” “_er” is to
> >> distinguish between qname-minimized queries (for lack of a better
> >> term) and “full” queries. I understand that you argue that a
> >> monitoring agent can determine this without the _er labels (as
> >> described below), but that seem suboptimal to me.
> > 
> > The qname minimised query (whether or not a dedicated qtype is used)
> > will be for "A" or "NS" records, not TXT or the dedicated qtype, so
> > there's no need for "_er" in the first label, the qtype is sufficient.
> 
> RFC9156 contains no hard requirement to use A/NS. So I’m not confident
> that all current and future qname-minimisation implementations use
> A/NS. 

This is where this document can specify that qname minimised error
reports MUST use a qtype other than the qtype for the final error
report.

> > However, to avoid forwarding junk reports to the monitoring agent, a
> > resolver may well sensibly choose to not forward such queries, and
> > only source them internally.
> 
> I’m not following.

If the qtype is "TXT", then an open resolver is easily subject to
proxying forged error reports purporting errors that the resolver did
not observe.  Some client of the open resolver sends an explicit query
for:

. IN TXT ?

which then looks like an error report from *that* resolver to the
monitoring agent.  If instead we have a dedicated qtype for error
reports, it becomes a simple matter of refusing to iterate queries for 

. IN  ?

Any resolver wanting to report an error must do so directly, not via a
forwarder.  Especially because the forwarders won't be passing the
agent extension through to their clients!

> > The specification might also recommend that "stub" resolvers that
> > forward most queries to a "full service" resolver, should send error
> > reports *directly* to the monitoring agent.  And, of course, "full
> > service" resolvers MUST NOT *forward* the monitoring agent OPTION to
> > clients, if they send such an option, it should be locally generated
> > to signal the monitoring agent for 

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Viktor Dukhovni]

On Wed, Jul 05, 2023 at 12:17:34PM +0100, Roy Arends wrote:

> > I would prefer to require resolvers to be more tolerant of unexpected 
> > options, and would have servers report the channel without explicit
> > solicitation.
> 
> That is indeed the plan. I shall make that explicit in the new text.

Thanks.  That will be helpful.

> > What is a "recipient"?  Is it a monitoring agent "zone", or a monitoring
> > agent transport endpoint?  If we're concerned about DoS, perhaps it
> > should be the latter, since many zones can resolve to the same set of
> > underlying nameservers...
> 
> I will deal with this text in the update.

Appreciated.

> > Requiring cookies would be great, but they have not yet seem broad
> > adoption.  Can we reasonably expect the monitoring agent zones to
> > support them (and ensure consistent cookie keys across the server
> > pool behind each server IP)?
> > 
> > Requiring TCP, combined with per-IP rate limits is probably simpler.
> 
> I will include a note to implementors that reports received over TCP
> will be more reliable. The rate limiting you mentioned can be managed
> by resolver caching, right?

Yes.

> > The proposed qname structure is suboptimal:
> > 
> >- There is insufficient justification for the "_er" labels
> >  at either end of the error report qname.
> > 
> >o  If the monitoring agent wants to see some particular prefix,
> >   (perhaps even periodically rotated to quickly drop stale
> >   junk) the authoritative server can vend the prefix with the
> >   agent domain.  So the "most-significant" parent "_er" is
> >   IMNHSO redundant.
> 
> The monitoring agent has to determine where the QNAME ends, and the
> agent domain starts. If you assume that a monitoring agent only uses a
> single agent domain for all its reports, then sure, the _er_ label
> between the strings is redundant.
> 
> If however, the monitoring agent has domains in use, where the least
> significant labels collide with existing top level domains, it needs
> to determine heuristically where the agent domain starts. This is IMHO
> suboptimal.

Right, but surely the monitoring agent can decide whether to solicit
such a prefix label or not.  That is whether an "_er" prefix label is
signalled is a *local matter* betweent the authoritative server
signalling the option and the monitoring agent.  Why should resolvers
have to be responsible for this?  If a given monitoring agent does
not need such signalling, what value does it add?

> >o The leading "least-significant" "_er" is likewise (see below)
> >  not adequately justified.
> 
> The sole purpose of the leading “least-significant” “_er” is to
> distinguish between qname-minimized queries (for lack of a better
> term) and “full” queries. I understand that you argue that a
> monitoring agent can determine this without the _er labels (as
> described below), but that seem suboptimal to me.

The qname minimised query (whether or not a dedicated qtype is used)
will be for "A" or "NS" records, not TXT or the dedicated qtype, so
there's no need for "_er" in the first label, the qtype is sufficient.

> > Also, qtypes are cheap, and I rather think that a dedicated qtype (one
> > that a supporting resolver might refuse to accept in queries from
> > clients for example) makes sense here.  There's no need to overload
> > TXT here.
> 
> This seems counter intuitive to me. A qtype that a supporting resolver
> might refuse to accept in queries from clients is either a temporary
> state (it may be accepted in the near future when this qtype will be
> implemented), or it needs to be specified that this qtype should not
> be accepted in queries from clients, which makes this qtype not cheap
> (that is, we won’t be able to simply use the template to request one,
> as it requires additional work). 

There's no need to require that it not be accepted from clients, but
it is easier to do that with a dedicated qtype.  It can be added to:

- RRSIG (semantically vacuous sans the associated RRset)
- NSEC3 (not part of the zone's qname namespace).
- ANY (if that's what the resolver chooses to do).

However, to avoid forwarding junk reports to the monitoring agent, a
resolver may well sensibly choose to not forward such queries, and
only source them internally.

The specification might also recommend that "stub" resolvers that
forward most queries to a "full service" resolver, should send error
reports *directly* to the monitoring agent.  And, of course, "full
service" resolvers MUST NOT *forward* the monitoring agent OPTION to
clients, if they send such an option, it should be locally generated
to signal the monitoring agent for the resolver itself.

> Allocating a new QTYPE for this purpose just seems redundant. 

It is not.  This is not a normal query, it is an error report.

> >> This document gives no guidance on the content of the TXT resource
> >> record RDATA for this record.
> > 
> > The 

Re: [DNSOP] DNSOPReminder: Please review draft-ietf-dnsop-svcb-dane

[Viktor Dukhovni]

Ben Schwartz  writes:

> I wanted to remind DNSOP to take another look at
> draft-ietf-dnsop-svcb-dane [1], which is intended as a straightforward
> clarification of how DANE interacts with SVCB/HTTPS records (and
> QUIC/HTTP/3).  I don't think this document is controversial, and I'd
> like to proceed to WGLC soon.

Quoting from the draft:

>3.  Using DANE with Service Bindings
>
>   Section 6 of [RFC7671] says:
>
> With protocols that support explicit transport redirection via DNS
> MX records, SRV records, or other similar records, the TLSA base
> domain is based on the redirected transport endpoint rather than
> the origin domain.
>
>   This draft applies the same logic to SVCB-compatible records.
>   Specifically, if SVCB resolution was entirely secure (including any
>   AliasMode records and/or CNAMEs), then for each connection attempt
>   derived from a SVCB-compatible record,
>
>   *  The initial TLSA base domain MUST be the final SVCB TargetName
> used for this connection attempt.  (Names appearing earlier in a
> resolution chain are not used.)
>
>   *  The transport prefix MUST be the transport of this connection
> attempt (possibly influenced by the "alpn" SvcParam).
>
>   *  The port prefix MUST be the port number of this connection attempt
> (possibly influenced by the "port" SvcParam).
>
>   If the initial TLSA base domain is the start of a secure CNAME chain,
>   clients MUST first try to use the end of the chain as the TLSA base
>   domain, with fallback to the initial base domain, as described in
>   Section 7 of [RFC7671].

I should perhaps mention, without necessarily implying a burden on this
draft to correct the past sins of others (primarily myself), that the
CNAME chasing of the target specified in RFC7671 was in retrospect
perhaps a mistake:

- CNAMEs in MX records are rarely used.  At least in SMTP the
  vast majority of published TLSA records are direct.
  CNAME-derived TLSA base domains occur only in:

* 182 out of 20,397 MX host TLSA base domains
* 3,035 out ouf 4,053,744 email domains

(less than 0.5% or even 0.1% of cases).

- Such CNAME chasing is not compatible with the DANE chain
  extension:
  https://datatracker.ietf.org/doc/html/rfc9102#section-3
  https://datatracker.ietf.org/doc/html/rfc9102#name-virtual-hosting

- It is difficult to explain to implementors and users.

- If deduplication for the TLSA RRSet across multiple aliases to
  the same ultimate host is desired, a parallel CNAME can always
  be added:

some.host.example. IN CNAME other.host.example.
; Choose either of the below:
_8080._tcp.some.host.example IN CNAME _8080._other.host.example.
_tcp.some.host.example IN DNAME _tcp.other.host.example.

However, if CNAME chasing is no longer required then the final server
may need to present a much more diverse set of certificates, with a
matching name for each alias, rather than just one for the
CNAME-resolved name.  Of course in a mixed ecosystem with only some
clients supporting DANE, the server will need to do that anyway (with
even more names for the various domains at the start of the SVCB or
HTTPS indirection).


If we don't expect prolific use of SVCB or HTTPS targets that are in
turn CNAMEs, perhaps it is time to reconsider the advice in 7671 which
was written when operational experience was still evolving.

>   If a TLSA RRSet is securely resolved, the client MUST set the SNI to
>   the TLSA base domain of the RRSet.  In usage modes other than DANE-
>   EE(3), the client MUST validate that the certificate covers this base
>   domain, and MUST NOT require it to cover any other domain.

Note that after 7671 was published it was pointed out by Richard Barnes
in https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00 that
not verifying the server name with DANE-EE(3) is problematic in the
web browser use-case, because it can lead to cross-origin issues that
are absent in protocols such as SMTP.

Therefore, barring specific knowledge that the application protocol in
question faces no similar issues, the certificate name should by default
always be checked.  This is reflected in the OpenSSL DANE
implementation, which requires a non-default flag to turn off name
checks when validating a peer via a matching DANE-EE(3) TLSA record.


>5.1.  Recommended configurations
>
>   Service consumers are expected to use CNAME or SVCB AliasMode to
>   point at provider-controlled records, e.g.:
>
>   alias.net.  HTTPS 0 xyz.provider.com.
>   www.alias.net.  CNAME xyz.provider.com.
>   xyz.provider.com.   HTTPS 1 . alpn=h2 ...
>   xyz.provider.com.   A 192.0.2.1
>   

Re: [DNSOP] With multi-algo DS, what to do if an RRSIG is missing?

[Viktor Dukhovni]

On Mon, Jul 03, 2023 at 08:25:08PM +0200, Peter Thomassen wrote:

> Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is
> not an uncommon transition (ietf.org did it last month, except that
> they went unsigned). In such a scenario, a resolver on Red Hat would
> only consider the algo 13 DS records.

Yes, the only way to move and stay signed in the case of ietf.org was to
complete a transition to algorithm 13 while still self-hosted, and only
then migrate to Cloudflare's hosting platform (based on the expectation
that Cloudflare don't support signing with algorithm 7).

This IIRC was more complexity than they were willing to take on.

> Under the relaxed RRSIG presence rule, it would be fine to serve
> signatures of *one* algorithm only (either 7 or 13). If only 7 is
> served, my understanding is that this would lead to SERVFAIL, because
> signatures are missing for the only supported algorithm. There is no
> valid path.

The relaxed RRSIG presence rule (for signers) is fundamentally
incompatible with the DNSSEC security model.  So long as there exists a
non-negligible population of resolvers that support only one of the two
algorithms, queries for a zone where some or all servers return RRSIGs
for just one of the two algorithms will sporadically fail validation.

And since the whole point of multiple (dual) providers is to be able to
operate in the face of an outage of one of the providers, if the one
that fails is the only one with supported RRSIGs (for a given resolver)
the outage is then total, rather than sporadic.

So long as both providers are up, some queries will randomly find an
acceptable resolver, and caching might then keep the failure rate low,
but note also that not all resolvers try another server when a bogus
response is detected.

Some notable resolvers do "late" validation, where the query with all
necessary referral chasing and retransmissions is performed first, and
the response is validated at the end, with no opportunity to retry the
query at another server.  So when the cache is cold, failures will
happen until some query eventually hits a compatible server.

> Here are the questions:
> 
> 1.) Is SERVFAIL the correct behavior in the above scenario?

Yes, unless a better server happens to be found (see above).  The
response is bogus.

> 2.) Does anyone think that "insecure" is the right behavior? ("I can
> see another signature of algorithm 7 which I can't validate; it might
> match, so I'll pass this.")

Absolutely not.  DNSSEC without resistance to active attacks is mere
security theatre.  You get all the failure modes, and none of the
protection.

> 3.) If anyone thinks that "insecure" is fine: Why should the resolver
> assume that things are fine, and that the lack of signature is not an
> indication of a downgrade-to-insecure attack?

The question is moot.  Anyone who thinks that "insecure" is fine is
sadly quite mistaken.

> 4.) In fact, how would the resolver distinguish this from a
> downgrade-to-insecure attack?

Not possible.

> 5.) If the authoritative server can't know what the resolver supports,
> how could it ever be safe, by not sending RRSIGs for all algorithms,
> to introduce the confusion of question (4)?

The only scenario (difficult to know for sure) under which the RRSIGs
can be partitioned by provider is when both operators and the zone owner
are absolutely sure that effectively all resolvers support both
algorithms and only a negligible population they're willing to let break
do not.

This may be somewhat true at present if the two algorithms are 8 and 13,
which one expects every validating resolver to support.  These two
algorithms account for roughly 55% and 45% of all signed zones, and
both are used by major TLDs, ...

So, it may **at this point in time** be possible to have one server
returning algorithm 8 RRSIGs, and another algorithm 13, while the DS
RRSet lists both.

This "happy point time" is a result of both MTI algorithms being widely
used and long established.

There are no other such algorithm pairs, and when, for example,
algorithm 15 finally sees non-trivial adoption, it may not be possible
to split 8/15 or 13/15 across providers for close to a decade.


> (Does the signer know enough about the validator to decide which
> algorithms can be advertised but then their signatures left off,
> because another advertised algorithm is surely supported?)

See above.  Perhaps, with luck, at present, when the two algorithms are
8 and 13, but not otherwise.

> Also note that the algorithms in this example (7 and 13) are both
> "MUST implement" on the validator side, RFC 8624 Section 3.1. Some say
> that "MUST implement" is different from "MUST support".

MTI is not a time-invariant fundamental property of an algorithm, and
resolvers of various "vintages" freeze-in different notions of which
algorithms are or aren't MTI.  Therefore, MTI does not enter the
equation.  Only point-in-time knowledge of the current resolver
population might 

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Viktor Dukhovni]

On Thu, Jun 08, 2023 at 11:59:59AM +0200, Benno Overeinder wrote:

> This starts a two week Working Group Last Call process, and ends on: 
> June 22nd, 2023.

I hope my feedback is not too late.  There are a few important elements
of the draft that could use some changes.

On Tue, Jun 20, 2023 at 01:14:02PM +0200, Willem Toorop wrote:
>
> I have one nit.
> 
> In the Example in section 4.2., a request still "includes an empty ENDS0 
> report channel". The third paragraph of that same section states 
> something similar: "As support for DNS error reporting was indicated by 
> a empty EDNS0 report channel option in the request". But Section 6.1. 
> Reporting Resolver Specification states: "The EDNS0 report channel 
> option MUST NOT be included in queries."

On Tue, Jun 20, 2023 at 12:20:51PM +0100, Roy Arends wrote:
> 
> Ah, yes, I will remove that sentence completely!

So, under what conditions is the authoritative server free to include
the error reporting channel extension in its reply?

- Does the resolver have to explicitly solicit it?

The reason this is important, is that there is non-negligible population
of authoritative servers that (EDNS0 requirements notwithstanding) are
not tolerant of unrecognised EDNS0 options.  Therefore, soliciting the
error reporting channel information is (at least initially, while this
is not widely supported) more likely to lead to errors than to help to
resolver errors.  This is then not attractive to implement!

I would prefer to require resolvers to be more tolerant of unexpected 
options, and would have servers report the channel without explicit
solicitation.

On Tue, Jun 20, 2023 at 11:35:28PM +0100, Dick Franks wrote:
> > An authoritative server includes the option if configured to do so
> > AND if it has the a non-null domain name configured as the reporting
> > channel. It will then reply to each query. This is IMHO better than
> > having a resolver include the option each and every time. Note that
> > resolvers will ignore options that are unknown to them.
> 
> 6.2.  Authoritative server specification
> Contains not a shred of normative language saying any of that.
> 
> The preliminary waffle in the overview could apply to either the
> solicited or unsolicited regime.
> 
> > > I withdraw my earlier statement that the document is almost ready.
> > > Now, clearly it is not.
> >
> > I hear you. I do not agree though, and I hope you reconsider
> Not without further work

I agree this needs to be made more explicit than just deleting the
conflicting text.

On Thu, Jun 22, 2023 at 04:10:46PM -0700, Wes Hardaker wrote:
> Roy Arends  writes:
> 
> > That, IMHO is already captured by the last paragraph. I did not
> > explicitly write a recipe of how to do that, and which servers could
> > be used for that :-). Could you suggest text to improve the last
> > paragraph without naming services?
> 
> Erg.  I hate it when I have to come up with text :-P
> 
> How about replacing the last sentence of security considerations with:
> 
> This method can be abused by intentionally deploying broken zones with
> agent domains that are delegated to victims.  This is particularly
> effective when DNS requests that trigger error messages are sent through
> open resolvers [RFC8499] or widely distributed network monitoring
> systems that perform distributed queries from around the globe.
> Implementations SHOULD rate-limit outgoing error messages to a
> recipient to no more than 1 a minute.

What is a "recipient"?  Is it a monitoring agent "zone", or a monitoring
agent transport endpoint?  If we're concerned about DoS, perhaps it
should be the latter, since many zones can resolve to the same set of
underlying nameservers...

On Fri, Jun 23, 2023 at 01:27:21AM +, Ben Schwartz wrote:

> I want this draft to move forward, but upon review I noted with
> concern the security section text:
> 
>DNS error reporting is done without any authentication between the
>reporting resolver and the authoritative server of the agent domain.
>Authentication significantly increases the burden on the reporting
>resolver without any benefit to the monitoring agent, authoritative
>server or reporting resolver.
> 
> Strong authentication (e.g. to a zone identity with DNSSEC) is
> probably excessive, but the current draft appears to have no defense
> against even trivial IP spoofing.  Anyone in the world who can spoof
> IP addresses can impersonate a reputable resolver and pollute the
> error reports sent to authoritative servers.  As an authoritative
> server operator, I would place a lot more trust in reports from
> reputable resolvers than from unrecognized sources.
> 
> I think the draft should probably say something like: "To defend
> against spoofing of source IP addresses used for error reports,
> reporting resolvers MUST use DNS over TCP [RFC 7766], DNS COOKIE [RFC
> 7873], or another procedure that defeats IP address spoofing."

Requiring cookies would be great, but they have 

Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements

[Viktor Dukhovni]

On Wed, Jun 14, 2023 at 12:09:23PM -0400, Peter Thomassen wrote:

> > But the focus changes. For example, if we consider that "spoofing by
> > recursive server" is a threat, then having the recursive set bits to
> > affirm that the response is verified is not much of a protection --
> > the emphasis should move to verification by the client. I would love
> > to see this discussed.
> 
> I agree that client-side validation would be ideal. One important
> aspect here is to save on the latency caused by extra queries; my
> impression is that this extra cost is generally considered
> prohibitive.

Not sure what you mean by "generally" (is that the browser use case)?

In Postfix, a caching validating resolver is expected to be and is
typically local (127.0.0.1).  The latency cost is minimal and SMTP
is not nearly as latency sensitive as HTTP (with all the ads and
javascript the browser has to fetch in addition to the main page
content).

> Experimental protocols for this have been published. Specifically, RFC
> 7901 and RFC 9102 come to mind.

These are not always needed.  A local resolver is a good option anywhere
where last-mile middleboxes don't MiTM and break access to DNSSEC.

> I'm not aware of any implementations of these protocols -- I think
> having software support, perhaps experimental, in some of the common
> software packages would be REALLY cool.

Some folks at NLNetLabs had implementations in progress IIRC.

-- 
Viktor.

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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Viktor Dukhovni]

On Wed, Oct 19, 2022 at 03:21:27PM -0400, Tim Wicinski wrote:

> This starts a Working Group Last Call for
> draft-ietf-dnsop-dnssec-validator-requirements
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/
> 
> The Current Intended Status of this document is: Informational
> 
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak
> out with your reasons.
> 
> This starts a two week Working Group Last Call process, and ends on:  2
> November 2022

Repost of my belated comments in the thread, apologies about not doing
it right the first time...

-- 
Viktor.

>  Recommendations for DNSSEC Resolvers Operators
>draft-ietf-dnsop-dnssec-validator-requirements-04

Before I dive into some paragraph-by-paragraph details, and bury the
lede, my main high-level issue is with sections 9, primarily on
substance, but also for IMHO notably stilted and fuzzy language.

The most significant issue is that the I-D recommends at the bottom of
section 9 to cap the TTLs of all dependent RRsets by the TTLs of the DS,
KSK and ZSK records.

   >  RUNTIME:
   >
   >   *  To limit the risks of incoherent data in the cache, it is
   >  RECOMMENDED DRO enforce TTL policies of RRsets based on the TTL of
   >  the DS, KSK and ZSK.  RRsets TTL SHOULD NOT exceed the DS, KSK or
   >  ZSK initial TTL value, that TTL SHOULD trigger delegation
   >  revalidation as described in [I-D.ietf-dnsop-ns-revalidation].
   >  TTL SHOULD NOT exceed the signature validity.

This is not necessary for correctly operated authoritative zones, that
retain "inactive" ZSKs and KSKs in the DNSKEY RRset for a few TTLs after
the keys become inactive, and likewise drop hashes of inactive KSKs from
the DS RRset only after new KSKs have been published for a sufficient
time.

What we'd need instead of TTL capping is more akin to "revalidation"
where under normal/expected conditions, cached RRsets continue to
"enjoy" their natural TTL (as tweaked by any resolver limits).  That TLL
can for many RRsets be higher than e.g. the TTL of the parent zone DS
RRset.

With "revalidation", if a DS record refreshed after TTL expiration is
(as is typically the case) identical to its previous value, or in any
case continues to establish a chain of trust to the cached DNSKEY RRset,
nothing needs to happen to the caching of the descendent records.

Similarly, DNSKEY RRset refreshes that still include the ZSK originally
used to validate a cached RRset need not have any affect on the validity
of the signed data.

The above DS and ZSK continuity conditions are expected standard
practice from the signer.  So long as these hold, validated records
should be cached for their advertised TTLs as bounded by the signed
origin TTLs and resolver cache time limits.

Resolvers *MAY* take action to revalidate cached data should abrupt
changes take place in the DS RRset (no longer building a trust path to
the cached DNSKEYs) or abrupt changes in the DNSKEY RRset (no longer
validating cached RRSIGs), but should not be expected to do so.

As resolvers gain implementation experience with this revalidation
generally, and DNSSEC trust chain revalidation specifically, and are
seen to perform revalidation safely and scalably (without thundering
herd query storms), and revalidation becomes a common implementation
feature, perhaps then we might reconsider resolver cache expectations.
We're not there yet, and in the meantime crude truncation of all TTLs to
the smaller of the DNS/DNSKEY TTLs is IMHO not a good outcome.

Moreover, this recommendation would be a barrier to shorter DS TTLs,
which are necessary to reduce mean time to recovery, making enabling
DNSSEC less daunting to risk averse authoritative zone operators.

> Abstract
>
>This document clarifies the scope and responsibilities of DNSSEC
>Resolver Operators (DRO)

O.K. so far.

> as well as operational recommendations that
>DNSSEC validators operators SHOULD put in place in order to implement
>sufficient trust that makes DNSSEC validation output accurate.

There's a missing verb in this part of the sentence.  "As well as ???"

Also: s/DNSSEC validators/DNSSEC validator/

> 1.  Introduction

>The purpose of a DNSSEC Resolver Operator (DRO) is to provide DNSSEC
>validation in to their users.

Well, the purpose is to provide DNSSEC resolution.  DNSSEC validation is
a part of that, but isn't the whole.

>By validating with DNSSEC a received Resource Record Set (RRset), the
>resolver provides a high level of certainty that the information
>carried by the RRset is effectively as published by the legitimate
>owner of the RRset.

s/certainty/assurance/

> The act of DNSSEC validation [RFC4033][RFC4035]
>  

[DNSOP] Comments on draft-ietf-dnsop-dnssec-validator-requirements-04

[Viktor Dukhovni]

>  Recommendations for DNSSEC Resolvers Operators
>draft-ietf-dnsop-dnssec-validator-requirements-04

Before I dive into some paragraph-by-paragraph details, and bury the
lede, my main high-level issue is with sections 9, primarily on
substance, but also for IMHO notably stilted and fuzzy language.

The most significant issue is that the I-D recommends at the bottom of
section 9 to cap the TTLs of all dependent RRsets by the TTLs of the DS,
KSK and ZSK records.

   >  RUNTIME:
   >
   >   *  To limit the risks of incoherent data in the cache, it is
   >  RECOMMENDED DRO enforce TTL policies of RRsets based on the TTL of
   >  the DS, KSK and ZSK.  RRsets TTL SHOULD NOT exceed the DS, KSK or
   >  ZSK initial TTL value, that TTL SHOULD trigger delegation
   >  revalidation as described in [I-D.ietf-dnsop-ns-revalidation].
   >  TTL SHOULD NOT exceed the signature validity.

This is not necessary for correctly operated authoritative zones, that
retain "inactive" ZSKs and KSKs in the DNSKEY RRset for a few TTLs after
the keys become inactive, and likewise drop hashes of inactive KSKs from
the DS RRset only after new KSKs have been published for a sufficient
time.

What we'd need instead of TTL capping is more akin to "revalidation"
where under normal/expected conditions, cached RRsets continue to
"enjoy" their natural TTL (as tweaked by any resolver limits).  That TLL
can for many RRsets be higher than e.g. the TTL of the parent zone DS
RRset.

With "revalidation", if a DS record refreshed after TTL expiration is
(as is typically the case) identical to its previous value, or in any
case continues to establish a chain of trust to the cached DNSKEY RRset,
nothing needs to happen to the caching of the descendent records.

Similarly, DNSKEY RRset refreshes that still include the ZSK originally
used to validate a cached RRset need not have any affect on the validity
of the signed data.

The above DS and ZSK continuity conditions are expected standard
practice from the signer.  So long as these hold, validated records
should be cached for their advertised TTLs as bounded by the signed
origin TTLs and resolver cache time limits.

Resolvers *MAY* take action to revalidate cached data should abrupt
changes take place in the DS RRset (no longer building a trust path to
the cached DNSKEYs) or abrupt changes in the DNSKEY RRset (no longer
validating cached RRSIGs), but should not be expected to do so.

As resolvers gain implementation experience with this revalidation
generally, and DNSSEC trust chain revalidation specifically, and are
seen to perform revalidation safely and scalably (without thundering
herd query storms), and revalidation becomes a common implementation
feature, perhaps then we might reconsider resolver cache expectations.
We're not there yet, and in the meantime crude truncation of all TTLs to
the smaller of the DNS/DNSKEY TTLs is IMHO not a good outcome.

Moreover, this recommendation would be a barrier to shorter DS TTLs,
which are necessary to reduce mean time to recovery, making enabling
DNSSEC less daunting to risk averse authoritative zone operators.

> Abstract
>
>This document clarifies the scope and responsibilities of DNSSEC
>Resolver Operators (DRO)

O.K. so far.

> as well as operational recommendations that
>DNSSEC validators operators SHOULD put in place in order to implement
>sufficient trust that makes DNSSEC validation output accurate.

There's a missing verb in this part of the sentence.  "As well as ???"

Also: s/DNSSEC validators/DNSSEC validator/

> 1.  Introduction

>The purpose of a DNSSEC Resolver Operator (DRO) is to provide DNSSEC
>validation in to their users.

Well, the purpose is to provide DNSSEC resolution.  DNSSEC validation is
a part of that, but isn't the whole.

>By validating with DNSSEC a received Resource Record Set (RRset), the
>resolver provides a high level of certainty that the information
>carried by the RRset is effectively as published by the legitimate
>owner of the RRset.

s/certainty/assurance/

> The act of DNSSEC validation [RFC4033][RFC4035]
>can be broken into two part: A _Signature Validation_ which binds the
>RRset to a private key as well as _Trust_ in the owner of the private
>being the legitimate owner.

This is very clumsy. Suggested:

  The act of DNSSEC validation [RFC4033][RFC4035]
 can be broken into two parts: _Signature Validation_ which binds the
 RRset to a public key as well as establishing a _Trust Chain_
 authenticating that public key as an authorised signer for
 containing zone.

>Signature Validation consists in checking the cryptographic signature
>of a RRset and involves among other parameters a DNSKEY Resource
>Record (RR) and RRSIG RR and the RRset itself.  The signature
>validation process results in designating the owner 

[DNSOP] FYI: SVCB and HTTPS RR and DNSSEC signing/validation

[Viktor Dukhovni]

Though this is in fact implicit in RFC4035 Section 6.2, it is perhaps
worth reminding any implementors reading this post (and though absurdly
late, perhaps even adding yet another minor tweak to the document) that
the target name of a SVCB or HTTPS record, though a domain name, MUST
NOT be canonicalised to lower case when signing or validating.

These names are of course (for largely the same reasons) also not
candidates for name compression.

I've seen some evidence that this point is not always obvious to
implementors rushing support for these out the door, and actual
mixed-case targets in signed zones to test against are exceedingly
scarce.  So it is easy to ship a non-interoperable implementation that
will only exhibit problems much later when sufficiently many zone owners
do decide to use mixed case target names for some cosmetic reason.

I am not expecting miracles in terms of document changes, so no flames
please, just do the right thing whatever that might be.  On the other,
if you are implementing or have recently implement support for signing
or validating SVCB/HTTPS records, please make sure that the input to the
hash for signing/validation is not case-folded.

-- 
Viktor.

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

Re: [DNSOP] [dns-operations] Compact denial of existence (NODATA sentinel RRtype)

[Viktor Dukhovni]

> On 11 Apr 2023, at 9:57 am, Edward Lewis  wrote:
> 
> Sure, the cost of replacing NSEC and NSEC3 would be another resource record 
> type code roll
> (such as 5->8, RSA-SHA1 vs RSA-SHA1-NSEC3).  But a new on-the-fly denial of 
> existence might
> prove to be worth it in operations.

No such hefty investment is needed.  All that's required is to invert the 
sentinel
RRTYPE from signalling NXDOMAIN to signalling "NODATA", with just "RRSIG" and 
"NSEC"
in the type bit signalling NXDOMAIN.

The reason to use the sentinel RRTYPE for NODATA, is that this provides sensible
semantics for responses to:

nodata.example. IN  ?

This type can have a mandatory 0 length RDATA:

; The "" is cosmetic, no other payload is supported.
nodata.example. IN  ""
nodata.example. IN RRSIG  ...

This response is consistent with the (effectively NODATA) original response,
in that unmodified validating resolvers will find no issues with it, or
conflict with the original response.

On the other hand, promosing some sentinel RRTYPE with NXDOMAIN is problematic,
since there is no correct response to explicit query for that type.

That's all that's needed.  Resolvers that wish to remap "RRSIG NSEC" -> 
NXDOMAIN to upstream
clients that sent DO=0 can do so, or not.  Nothing breaks either way.

-- 
Viktor.

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

Re: [DNSOP] [Ext] Meaning of lame delegation

[Viktor Dukhovni]

On Mon, Apr 10, 2023 at 01:39:21PM +, Wessels, Duane wrote:

> Perhaps:
> 
> "A lame delegation is said to exist when one or more authoritative
> servers designated by the delegating NS rrset or by the apex NS rrset
> answers non-authoritatively for a zone".

This is a decent definition of the operational perspective.  Once one
can judge that the non-authoritative response (say REFUSED) is a
persistent misconfiguration rather than a transient condition (or
observed from just a deliberately shunned vantage point), then one might
call the misconfigured delegation LAME.  [ Note, the caveat above is not
an endorsement of selective prior blocking of DNS queries. ]

The nits are:

- Naturally, non-response would also need to be considered a form of
  non-authoritative response.

- A (progressive) delegation response to a query for a subdomain is not
  authoritative, and yet the parent's delegation is not LAME.

- A truncated response (with just the question and an OPT RR) might well
  have aa=0 (if say the full response would be a delegation), and yet
  the delegation is not LAME.

So non-LAME delegations will at times result in non-authoritative
responses.  Indeed particularly from .COM a large fraction of the
responses are likely non-authoritative, and yet the root zone delegation
to .COM is not LAME. :-)

Perhaps we could say that a LAME delegation is one where the response
for the zone apex SOA or NS RRset is (persistently) non-authoritative
even after any TCP retries due to an initial truncated response.

-- 
Viktor.

P.S. Resolver-generated EDEs about LAME delegation may nevertheless
 be limited to what the resolver can discern one query/response
 at a time, i.e. non-productive delegation responses.

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

Re: [DNSOP] Meaning of lame delegation

[Viktor Dukhovni]

On Thu, Apr 06, 2023 at 11:13:32PM +0200, Havard Eidnes wrote:

> > Well, one would, in fact, expect a delegation to be a non-authoritative
> > answer:
> 
> Yes, but one would presume that before any of the two above
> queries were sent, the recursive resolver already have cached the
> delegation for jshsos.ksyunv5.com.

It doesn't matter, there can be multiple layers of delegations, and a
response with aa=0, ancount=0, no SOA in the authority section and some
NS records there is definitely what a delegation looks like.  When it
is non-productive, it is LAME.

> Therefore, posting a question about a name in that zone to one of
> the name servers supposedly serving that zone

It needn't be authoritative for all names in the zone, it can issue
further delegations, and sure appears to do just that, only with a
delegation to itself.

> would be expected to elicit an authoritative response, and not a
> non-authoritative delegation response.

Only when actually authoritative for the requested name.

> >> If I'm not terribly mistaken, this sort of mis-behaviour is all too
> >> common among the CDN crowd, and I dearly wish we could stomp it out.
> >
> > Shall we?  Please lead the way!
> 
> A couple of questions: Do we have a spec of what a minimally
> conformant publishing name server needs to implement?

- Minimally, 103[345]
- EDNS(0) (at least to the extent of responding with FORMERR)
- TCP.
- Also, include SOA in the **AUTHORITY** section when returning
  NODATA or NXDOMAIN.  RFC2308 sadly tolerates NODATA/NXDOMAIN
  without SOA, but that really should stop being tolerated at some
  point.

Current garbage to NOT DO:

- DO NOT return SOA in the ANSWER section in NODATA responses.
- DO NOT return some fixed record type (A, ...) in the answer
  section regardless of the qtype.
- DO NOT put NS records sans SOA in the authority section of
  a NODATA/NXDOMAIN response

> And secondly, do we have any inkling whether all or most of these CDNs
> use a common codebase, or is it all truly "roll your own"?  And if
> there is a dominant codebase, do we have an inkling what it is?

I don't know, but there does seem to be some commonality of behaviour.

-- 
Viktor.

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

Re: [DNSOP] Meaning of lame delegation

[Viktor Dukhovni]

On Tue, Apr 04, 2023 at 10:48:11PM +0200, Havard Eidnes wrote:

> > At the time such a delegation response is being processed by a resolver,
> > it looks just fine.  Nothing to see here, move along (down the tree)...
> 
> I disagree.  If either ns1.provider.net or ns2.provider.net is not
> provisioned to provide name service for the example.com zone, that
> delegation record would be a "lame delegation", and it's the
> responsibility of the domain owner for example.com to intervene and
> fix the situation, either by contacting the DNS publication service
> provider to (re-)establish service or to contact the registrar to
> update the delegation NS RRset.

What I'm trying to suggest (resolver perspective), is that questions of
responsibility, ... are not something a resolver can or should attempt
to determine.  All one can attempt to do is classify query responses.

- It sees a delegation from a parent that is structurally valid, and is
  therefore processed.

- It then may see a non-progressive delegation response (the only kind
  of LAME a resolver can effectively divine) from the allegedly
  responsible nameservers, a can classify that as a LAME delegation
  response.

- If all the nameservers fail to provide a usable response, the final
  EDEs may include "LAME delegation" from one or more of the respective
  nameservers, and "Unreachable Authority" overall.

Any other definition of LAME is not something that a resolver can
reliably infer or report.  Some term that covers questions of correct
configuration, responsibility, authority, that lie outside the scope of
what a resolver can determine, may indeed be useful, and perhaps the
term LAME is generally defined from *that* perspective...  It is just
that I see a a clear need for a more technical term that classifies bad
delegation responses and LAME has so far worked well for that purpose.

If some day my informal use in this thread of "non-productive" gains
broader currency in the community, and begins to be "understood" without
much further explanation when used, I might stop using "LAME" in its
narrow (know it when I see it in a response) sense.

> > I can't tell you **why** they do it, but there are many that do in fact
> > respond with non-productive delegations:
> 
> Hmm, in the response to
> 
> dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. 
> 
> I think the only real problem is the absence of the "aa" flag in the
> response, especially since you get it in the response to
> 
> dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. a

Well, one would, in fact, expect a delegation to be a non-authoritative
answer:

$ dig @a.gtld-servers.net.  -t a www.google.com \
+norecur +noedns +qu +nocmd +nocl +nottl +nostats +noadd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39726
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 8

;; QUESTION SECTION:
;www.google.com.IN A

;; AUTHORITY SECTION:
google.com. NS  ns2.google.com.
google.com. NS  ns1.google.com.
google.com. NS  ns3.google.com.
google.com. NS  ns4.google.com.

So our "bpldns.com" server is doing a darn good job of simulating a
delegation response, that is non-productive, so LAME.

> This smells of a "roll your own" DNS name server implementation which
> doesn't even correctly implement the required minimum of the DNS
> standards.
>
> Clearly, the name lzd.jshsos.ksyunv5.com exists in the DNS name space
> (ref. the "a" response), and the name server being queried here should
> obviously be authoritative for the jshsos.ksyunv5.com zone, so the
> "aa" flag should be set in the reply to the "" query.  But also
> see the responses to

Definitely, but that's extrinsic knowledge that the resolver can't infer
from just the current query response.  In the heat of the moment, we all
we have is a well-formed, but non-productive delegation, which is the
only kind of LAME delegation that a resolver can unambiguously infer.

> If I'm not terribly mistaken, this sort of mis-behaviour is all too
> common among the CDN crowd, and I dearly wish we could stomp it out.

Shall we?  Please lead the way!

> Now...  Is the delegation "lame" in this case?  I'm leaning towards a
> crystal clear "maybe" :)  Perhaps the apparent "lameness" isn't the
> biggest problem in this case.

This and many others like it are indeed often more deeply broken, but
that goes beyond classifying the particular responses that are
non-productive delegations.

> I'm fully on-board with
> 
>   https://datatracker.ietf.org/doc/html/draft-sullivan-dnsop-refer-down-00

Yes, perhaps that draft is worth reviving in some form.

-- 
Viktor.

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

Re: [DNSOP] Meaning of lame delegation

[Viktor Dukhovni]

On Tue, Apr 04, 2023 at 06:40:55PM +0200, Havard Eidnes wrote:

> > ; ANSWER
> > ; AUTHORITY
> > example.com. IN NS ns1.provider.net.
> > example.com. IN NS ns2.provider.net.
> >
> > is a valid delegation response (and so not from this perspective a LAME
> > delegation), whether or not the target servers actualy serve the zone.
> 
> I agree that this is a valid delegation response.  I do however
> disagree with the latter part of this sentence; it *may* be a
> "lame delegation" depending on the response you as a recursive
> resolver get from the two delegated-to name servers when you try
> to look up a name in the example.com zone.

At the time such a delegation response is being processed by a resolver,
it looks just fine.  Nothing to see here, move along (down the tree)...

> > A LAME delegation (response) happens when "ns1" or "ns2" respond to
> > queries with yet another (e.g. self) delegation that does not move the
> > resolver closer to the target:
> >
> > ; ANSWER
> > ; AUTHORITY
> > example.com. IN NS ns1.provider.net.
> > example.com. IN NS ns2.provider.net.
> 
> I am having problems seeing under what normal-ish circumstances
> either ns1 or ns2 would provide this response.

I can't tell you **why** they do it, but there are many that do in fact
respond with non-productive delegations:

; .COM:
ksyunv5.com.172800  IN  NS  ns1.ksyuncdn.com.
ksyunv5.com.172800  IN  NS  ns2.ksyuncdn.com.
ksyunv5.com.172800  IN  NS  ns3.ksyuncdn.com.

---

; .ksyunv5.com:
jshsos.ksyunv5.com. NS  ns4.bpldns.com.
jshsos.ksyunv5.com. NS  ns3.bpldns.com.

---

; .jshsos.ksyunv5.com:
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12951
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;lzd.jshsos.ksyunv5.com.IN 

;; AUTHORITY SECTION:
jshsos.ksyunv5.com. NS  ns4.bpldns.com.
jshsos.ksyunv5.com. NS  ns3.bpldns.com.

Another example, a more "normal" upward referral:

; .CO.UK:
healthwize.co.uk.   172800  IN  NS  ns.mainnameserver.com.
healthwize.co.uk.   172800  IN  NS  ns2.mainnameserver.com.

---

; healthwize.co.uk:
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42663
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;healthwize.co.uk.  IN A

;; AUTHORITY SECTION:
.   NS  a.root-servers.net.
.   NS  b.root-servers.net.
.   NS  c.root-servers.net.
.   NS  d.root-servers.net.
.   NS  e.root-servers.net.
.   NS  f.root-servers.net.
.   NS  g.root-servers.net.
.   NS  h.root-servers.net.
.   NS  i.root-servers.net.
.   NS  j.root-servers.net.
.   NS  k.root-servers.net.
.   NS  l.root-servers.net.
.   NS  m.root-servers.net.

Non-productive (LAME) delegation responses are sadly all too common.

-- 
Viktor.

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

Re: [DNSOP] Meaning of lame delegation

[Viktor Dukhovni]

On Mon, Apr 03, 2023 at 05:44:04PM -0400, Viktor Dukhovni wrote:

> I believe that the most natural perspective is from the view point of a
> resolver attempting to classify a (non?)response to a query sent to an
> authoritative server.

Another way of thinking about this perspective is that, e.g., a
delegation response from a.gtld-servers.net (.COM nameserver) that
returns some set of nameservers for "example.com.":

; ANSWER
; AUTHORITY
example.com. IN NS ns1.provider.net.
example.com. IN NS ns2.provider.net.

is a valid delegation response (and so not from this perspective a LAME
delegation), whether or not the target servers actualy serve the zone.
A LAME delegation (response) happens when "ns1" or "ns2" respond to
queries with yet another (e.g. self) delegation that does not move the
resolver closer to the target:

; ANSWER
; AUTHORITY
example.com. IN NS ns1.provider.net.
example.com. IN NS ns2.provider.net.

A resolver would then report a LAME delegation EDE (once defined)
accordingly, based on non-progress.

If there's a failure at the ".COM" layer, it falls outside the DNS
protocol, and veers into questions of intent and operator competence,
questions of authority and responsibility to keep data up date, ...

Any protocol failure is with ns1/ns2 whether or not it is
administratively their operator's *fault*.

-- 
Viktor.

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

Re: [DNSOP] Meaning of lame delegation

[Viktor Dukhovni]

On Mon, Apr 03, 2023 at 08:02:16PM +, Wessels, Duane wrote:

> I am participating in an SSAC work party where we are writing about
> DNS delegations where a delegated name server might be available for
> registration, allowing an attacker to participate in the resolution
> for the domain.  During report drafting we considered using the term
> "lame delegation" to describe this and a broader class of delegation
> problems.
>
> [...]
>
> (1) NS.EXAMPLE.ORG resolves to an IP address.  Queries to the IP
> address result in a REFUSED, SERVFAIL, upward referral, or some other
> indication the name server is not configured to serve the zone.
> 
> (2) NS.EXAMPLE.ORG resolves to an IP address.  Queries to the IP
> address do not elicit a response (e.g., timeout).
> 
> (3) NS.EXAMPLE.ORG does not resolve to an IP address, so there is
> nowhere to send a query.
> 
> We welcome the working group's thoughts whether "lame delegation"
> encompasses these three possibilities.

I believe that the most natural perspective is from the view point of a
resolver attempting to classify a (non?)response to a query sent to an
authoritative server.  The following cases then arise:

- A server that returns a non-productive delegation:

* NOERROR + 0 answer count
* NO covering SOA in the authority section
* At least one NS record in the authority section
* BUT: the owner names of the NS records are not *closer*
  to the qname than the queried zone (known to the resolver,
  but not explicit in the query).

  The delegation may be "upward" (see:

  
https://datatracker.ietf.org/doc/html/draft-sullivan-dnsop-refer-down-00#section-2

  ), or to the queried zone or "sideways", but regardless it is not
  closer to the qname and so is LAME.  This is the *core* example of
  a LAME delegation (response).

- Somewhat more ambiguous is a REFUSED response.  In light of the
  words of wisdom in the above I-D:


https://datatracker.ietf.org/doc/html/draft-sullivan-dnsop-refer-down-00#section-2.4.4

https://datatracker.ietf.org/doc/html/draft-sullivan-dnsop-refer-down-00#section-2.4.5

  a "REFUSED" answer is often a symptom of what might have otherwise
  been an upward referral LAME delegation, but the signal is no
  longer unambiguous, and so this just a nameserver that is refusing
  service for some reason (the domain is often retired, and there
  are no working nameservers at all, a "dangling" or "orphan"
  delegation might be a better term).  So a resolver does not
  classify this case as LAME.

- Non-responding server.  This could be an outage, a rate limit,
  a deliberate policy blocking the resolver, ...  So calling it
  a LAME delegation is not a viable option even if the reason for
  the non-response is a misconfiguration that results in the wrong
  server being present in the NS (glue or authoritative) RRSet.

Bottom line, the definition that has a clear meaning (resolver
perspective) that a LAME delegation is a "non-productive" delegation
response.  Everything else is somewhat arbitrary.


On Mon, Apr 03, 2023 at 10:18:42PM +0200, Havard Eidnes wrote:

> > (1) NS.EXAMPLE.ORG resolves to an IP address.  Queries to the IP
> > address result in a REFUSED, SERVFAIL, upward referral, or
> > some other indication the name server is not configured to
> > serve the zone.
> >
> > (2) NS.EXAMPLE.ORG resolves to an IP address.  Queries to the IP
> > address do not elicit a response (e.g., timeout).
> >
> > (3) NS.EXAMPLE.ORG does not resolve to an IP address, so there is
> > nowhere to send a query.
> >
> > We welcome the working group's thoughts whether "lame delegation"
> > encompasses these three possibilities.
> 
> To my mind, both #1 and #2 are instances of a "lame delegation" --
> in both instances will a recursor fail to get the expected response
> within reasonable time when resolving a query for a name in the zone
> in question.

Thus I only concur on upward, sideways or self-referrals in case (1),
and none of the rest.

On Mon, Apr 03, 2023 at 01:36:56PM -0700, Wes Hardaker wrote:

> FYI, when working on the EDE draft [RFC8914] we discussed lame
> delegations some and actually did not document a particular error code
> related to it, as the meaning both uses improperly precise terminology
> ("lame" is not really a useful adjective in this situation) and because
> of the multiple reasons why an authoritative server may not be
> responding, as you indicated.

This is unfortunate, because the EDE implementation I'm working on
consequently can only classify these as "Other" with LAME in the
extra_text.  I'll be asking for that code point at some point once
the dust settles.

On Mon, Apr 03, 2023 at 08:31:28PM +, Mark Delany wrote:

> (5) Same thing as above excepting with in-domain name servers. If NET. says 
> the name
> server for EXAMPLE.NET is 

Re: [DNSOP] Updated: Compact Denial of Existence

[Viktor Dukhovni]

[ Multi-response to four upthread messages. ]

---

On Fri, Mar 03, 2023 at 06:23:11PM -0500, Shumon Huque wrote:

> Thanks for your comments. We've posted an updated draft (-01):
> 
>   https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01

[ Copied from today's dns-operations post on the same general topic. ]

A possibly inconvenient question, just to make sure we're not ignoring
the obvious sceptical position:

* How compelling is compact DoE?

The reason to ask is that both the original and now modified protocols
involve non-trivial complexity, and would likely require resolvers to
respond differently to queries with the DO bit set (pass them the NODATA
"truth" along with the NXNAME signal) vs. queries that don't request
validated answers (pass them the inferred NXDOMAIN).

The savings vs. actual by-the-book NSEC responses appear to be a 2x
reduction in the number of signatures to compute (the SOA RRSIG is  

  
presumably easily cached) and a 1.5x reduction in the number of
signatures to transmit (SOA + 1 NSEC, vs. SOA + 2 NSEC).

Do the CPU and packet size reductions justify the additional protocol
complexity?

* There is perhaps another way to ask the question: what is the
  motivation for compact DoE?  Perhaps CPU and packet sizes are a
  side show and this is all about avoiding zone walking?

In that case, might not NSEC3 "1 0 0 -" be good enough?  Sure a
sufficiently motivated offline dictionary brute-force attacker may be
able to discover some names faster with fewer online queries, but is
this **really** a concern.  How secret do you expect your DNS data to
be?  A big chunk of many zones ends up for free in certificate
transparency logs, or available from various (sometimes paywalled)
sources.  I am personally not impressed by arguments that DNS names
require confidentiality protection stronger than sufficient to deter
"casual" zone walking ala plain NSEC.

> But the main change is to move from the ENT distinguisher RR type
> to an explicit one for NXDOMAIN (with mnemonic NXNAME).

The draft fails to explain how queries for the proposed new RRtype are
to be handled by authoritative servers and resolvers.

---

On Wed, Mar 15, 2023 at 02:29:56PM +, Johan Stenstam wrote:

> Our original idea was to propose a different type of DNSKEY, i.e. a
> new flag bit in the DNSKEY that would signal “this key is only allowed
> to sign negative responses”. We were, however, talked out of that idea
> based on the strong wish to get DNSSEC out the door ASAP and therefore
> under no circumstances open up the Pandoras Box of further tweaks to
> the existing protocol.

This runs into a critical problem.  A security-critical function of
DNSSEC at the public suffix layer (TLDs, ...) is to not be vulnerable to
forged denial of existence of DS records for securely delegated domains.

**This**, and not avoiding opportunistic DANE TLSA downgrade attacks
(also good to have) is the reason that DNSSEC MUST have secure denial
of existence.

Therefore, signing keys for denial of existence are no less sensitive
(at least for zones that sign secure delegations) than signing keys
for positive response, and so the various TLD and ccTLD operators
need to be just as concerned about handing out negative signing keys.

[ And no, I am not about to suggest/endorse NSEC5. ]


> And yet, here we are, seventeen years later, still discussing this.

So I don't believe that idea can pan out.


On Sun, Mar 05, 2023 at 06:20:34PM +0100, Peter Thomassen wrote:


> 1.) Maybe it's worth pointing out that zones using compact denial
> SHOULD (MUST?) use NSEC, not NSEC3.

As others pointed out, "NSEC3 1 0 0 -" could be used, but there's no
point.  So indeed best to not define a needlessly elaborate variant.

> 2.) As for the "NXNAME" rrtype, I'd like to propose using rrtype 0.

This *could* be worth exploring, and has some appeal, but may be too
difficult to know to be safe against as yet unseen resolvers that would
later come out of the woodwork.  Someone would have to be willing to run
the experiment at scale.

> 3.) Section 2:
> 
>   An alternative way to distinguish NXDOMAIN from ENT is to define the
>   synthetic Resource Record type for ENTs instead, as specified in
>   [ENT-SENTINEL], and this has already been deployed in the field. This
>   typically imposes less work on the server since NXDOMAIN responses
>   are a lot more common than ENTs.

Or both.  In other words, use two sentinel RRtypes, one to unambiguously
signal an ENT, and another to signal NXDOMAIN.  This disambiguates the
protocol from current practice, though perhaps the ambiguity would not
last long if the current operators migrate to the new protocol quickly.

>   A signed zone at an authoritative server implementing Compact Answers
>   will never return a 

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:

> > These “rare” cases where the domain is not resolvable when a glue is not
> > present are the ones this draft is done for. So did you look how rare
> > they were in your dataset? Being able to resolve instead of not resolving
> > IMHO has value even if the number is not big.
> >
> > We all know that a lot of data in the DNS is garbage, that should not
> > stop us from using the good data.
> 
> The cyclic dependency based sibling glue (Section 2.3) is arguably
> a bit of a corner case, and in past discussions some folks have expressed
> the view that we shouldn't make accommodations to support it. I
> think I can agree with that, but there were opposing views that we also
> shouldn't break configurations that currently work. So it was left in.

Can we at least state that domains with cyclic dependencies are a bad
idea, and may not be supported by all resolvers.  In other words, that
the domain owner can't **rely** on the sibling glue recommended to be
sent in this draft to save the day.

My strong preference is still to delete all reference in the draft to
cyclic dependencies (i.e. not enshrine bad practice).  Which leaves
sibling glue primarily as a performance optimisation, and secondarily
as a last resort when the nameserver IP addresses are wrong or gone
from the authoritative zone (another bad practice).

What should really happen is that broken sibling glue should be
regularly purged from public suffix registries (probably requires
gaining support for this in the RRR community more than IETF), and only
then does the remaining valid sibling glue become more of a help than a
hindrance.

- Please, if at all possible, drop the cyclic dependency anti-pattern from the 
draft.

- The "right" justification for sibling glue (in the minority of cases
  that is is valid, by domain cardinality, though admittedly perhaps not
  a minority by query volume) is then lower latency/cost to reach a
  usable server.

-- 
Viktor.

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

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Fri, Feb 17, 2023 at 01:55:40PM +0900, Masataka Ohta wrote:

> Viktor Dukhovni wrote:
> 
>  > The draft states that in rare cases sibling glue could be useful, as a
>  > result of cyclic dependency loops.
> 
> Interesting. Such dependency existed between two TLDs (IIRC
> "edu" and "org") 20 or 30 years ago and I thought and still
> think there are redundancy issues.
> 
> That is, the example in the draft is insufficient and, at least, the
> following should be an additional example:
> 
> bar.test.  86400   IN NS  ns1.foo.test.
> bar.test.  86400   IN NS  ns2.foo.test.
> 
> foo.test.  86400   IN NS  ns1.foo.test.
> foo.test.  86400   IN NS  ns1.bar.test.
> foo.test.  86400   IN NS  ns2.bar.test.
> 
> in which case, without sibling glue, if ns1.foo.test goes down, name
> resolutions of both zones become impossible, which should not satisfy
> minimum required redundancy of DNS.

This is a very weak argument, because the two domains need not be in the
same TLD, and then sibling glue never happens.  The sibling glue IMHO
accomodates corner cases that are marginal to careless.

> >  In late 2021 the authors analyzed zone file data available from
> >  ICANN's Centralized Zone Data Service [CZDS] and found 222 out of
> >  approximately 209,000,000 total delegations that had only sibling
> >  domain NS RRs in a cyclic dependency as above.
> 
> "only sibling domain NS RRs"?
> 
> If my examples above are considered, there should be more cases.

And yet, because it is particularly badly maintained, the overall
effect is IMHO negative.

On Wed, Mar 01, 2023 at 04:27:31PM -0500, Shumon Huque wrote:

> The cyclic dependency based sibling glue (Section 2.3) is arguably a
> bit of a corner case, and in past discussions some folks have
> expressed the view that we shouldn't make accommodations to support
> it. I think I can agree with that, but there were opposing views that
> we also shouldn't break configurations that currently work. So it was
> left in.

Sure, a parent domain *may* serve sibling glue if it so chooses, but I
would not lump it in with a "glue is not optional" RFC.  This gives
sibling glue too much "weight", and sets expectations that it SHOULD
be used when provided, but I'd be inclined to downplay its importance,
and any expectation that it will save the day when all else fails.

> The case of normal (non-circular) sibling glue, described in Section
> 2.2 is in my opinion useful though, and also extremely common - where
> it isn't necessarily required for resolution but allows resolvers to
> obviate additional follow-on queries (to the same servers) to obtain
> the sibling glue.  Previous lengthy discussions on this topic indicate
> a consensus to retain them, but not mandate their inclusion (or set
> TC=1 if message size limits are exceeded).

Can we leave its availability and treatment as *unspecified*?  I don't
have a rock solid case for never sending it, but I do think we'd be
better of if as little as possible of it were in fact provided and as
few as possible relied on it.

> Note that this document does not place any requirements on DNS
> resolvers, so if a resolver implementer chooses to, they can ignore
> sibling glue in referral responses, and/or explicitly fetch them.

And so my take is that it is in fact "optional".

-- 
Viktor.

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

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Tue, Feb 21, 2023 at 11:49:40AM +0100, Ralf Weber wrote:

> > This leaves 6,466 cases to examine more closely:
> >
> >1. 3,773 are in complete agreement with the authoritative A/
> >   records.
> >
> >2. 1,447 have authoritative A/ records completely distinct
> >   from the sibling glue.
> >
> >3. 1,414 return NXDOMAIN from the auth zone!
> >
> >4. 74 return NODATA from the auth zone for both A and !
> >
> >5. 213 return SERFAIL from the auth zone A and  lookups.
> >
> > Of the above, case "1" could perhaps reduce latency, but is otherwise
> > redundant (modulo exceedingly rare cyclic depedendencies).
> 
> These “rare” cases where the domain is not resolvable when a glue is not
> present are the ones this draft is done for. So did you look how rare
> they were in your dataset? Being able to resolve instead of not resolving
> IMHO has value even if the number is not big.

Sure, there is *almost* one loop:

tsort: -: input contains a loop:
tsort: frogsoft.org.
tsort: frogid-server.org.

In the form of:

frogsoft.org. IN NS frogid-server.org.
frogid-server.org. IN NS frogsoft.org.
frogid-server.org. IN NS atelier-frogsoft.org.
atelier-frogsoft.org. IN NS frogid-server.org.
atelier-frogsoft.org. IN NS ns344725.ip-37-187-251.eu.
;
frogsoft.org. IN A 37.187.251.101
frogid-server.org. IN A 213.186.33.5
atelier-frogsoft.org. IN A  5.39.70.108

but the loop is not fully closed, because the ".eu" NS host is live
and returns:

atelier-frogsoft.org. IN A 37.187.251.101

The remaining glue IPs are either timing out or returning REFUSED, so
again, on the whole, the glue is worse than nothing.

> We all know that a lot of data in the DNS is garbage, that should not
> stop us from using the good data.

Sure, if the garbage were harmless, but, more frequently than not, the
sibling glue is worse than ignoring it and resolving the nameserver
addresses explicitly.  The basic problem is that largely nobody is
minding the sibling glue, it just rots away, while "child-centric"
resolvers may do well by discarding it.

The case for resolving loops is particularly weak, perhaps someone
wants to instead motivate this based on the occasional success for
the otherwise non-resolving names?  (I am still not convinced...)

Let the domain owners fix the garbage.  We don't need to bend over
backwards serving muck just because some users are lazy.  That only
delays the inevitable breakage, nobody is minding the farm.

-- 
Viktor.

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

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Thu, Feb 16, 2023 at 09:15:35PM -0500, Viktor Dukhovni wrote:

> There are many more.  We see a steady stream of sibling-glue-related
> lookup failures, that are only resolved after going to the authoritative
> source for the actual IP addresses of the nameservers in question.

I undertook a more comprehensive look, with the .ORG TLD as a case in
point.  There I find:

   1. 349,332 unique host objects with one or more A or  records.

   2. 80,427 are in-bailiwick nameservers of their domain.

   3. 6,466 are not nameservers of an ancestor .org name so only
  useful as "sibling glue".

   4. The remaining 262,575 appear to be garbage, detached from any .org
  delegation's nameserver name!  Why these are still in the zone is
  rather a mystery.

This leaves 6,466 cases to examine more closely:

   1. 3,773 are in complete agreement with the authoritative A/
  records.

   2. 1,447 have authoritative A/ records completely distinct
  from the sibling glue.

   3. 1,414 return NXDOMAIN from the auth zone!

   4. 74 return NODATA from the auth zone for both A and !

   5. 213 return SERFAIL from the auth zone A and  lookups.

Of the above, case "1" could perhaps reduce latency, but is otherwise
redundant (modulo exceedingly rare cyclic depedendencies).

So the question is whether in "2" the authoritative or sibling glue IPs
are in practice correct, and whether the auth A/ resolution failures
from "3", "4" and "5" are better served by the sibling glue.

To that end, I took a random sample of 20 sibling NS names.  These had
25 auth addresses and 21 sibling glue addresses.

Querying a domain each host is supposed to serve yields the below stats:

  AUTH | GLUE
+--|-
   LIVE | 8| 2
   LAME | 4| 0
TIMEOUT | 13   | 19

Of the 2 working sibling glue cases, one was also handled by the
corresponding auth IP.

So in this random sample, the sibling glue was only "better" 1 in 20
times, with 7 worse and the rest no difference (mostly timeouts).  So
far, this does not look like a compelling argument for serving sibling
glue...

For cases "3", "4" and "5" I took 20 random nameservers of each type,
for a total of 62 associated sibling glue IPs.  Querying each for
a name it is expected to serve the stats are:

NOERROR:  6
TIMEOUT: 44
REFUSED: 10
   SERVFAIL:  2

Again, the sibling glue is mostly no better than nothing, but ~10% of
the sampled cases worked out.

Overall, I think the world would be better served without the sibling
glue, the incentives to keep it accurate are poorly aligned.  As
suspected, where it differs from the authoritative data, it is almost
entirely junk.

-- 
Viktor.

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

Re: [DNSOP] draft-ietf-dnsop-glue-is-not-optional-07 vs. sibling glue

[Viktor Dukhovni]

On Thu, Feb 16, 2023 at 09:15:35PM -0500, Viktor Dukhovni wrote:

> Perhaps we'll find that we can't distinguish sibling glue from still
> required "orphan glue" (mention of which I see got removed from
> draft-02), and need the sibling glue as a last resort when the forward
> lookup of the out-of-bailiwick name fails.  That would I guess be
> unforunate, because I'd much rather see all "unnatural" glue disappear
> from DNS delegation zones.

Actually, orphan glue is of course not a problem and not needed as
sibling glue, since as part of the parent domain's authoritative data it
is in fact easily resolved via an explicit query.

-- 
Viktor.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bcp-05.txt

[Viktor Dukhovni]

On Mon, Oct 10, 2022 at 07:57:45AM -0700, internet-dra...@ietf.org wrote:

> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
> Filename: draft-ietf-dnsop-dnssec-bcp-05.txt
> [...]
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-bcp-05

I support the latest tweak to first paragram of Section 2, which now
reads:

   What we refer to as "DNSSEC" is the third iteration of the DNSSEC
   specification; [RFC2065] was the first, and [RFC2535] was the second.
   Earlier iterations have not been deployed on a significant scale.
   Throughout this document, "DNSSEC" means the protocol initially
   defined in [RFC4033], [RFC4034], and [RFC4035].

That said, when reading it through, it was not quite clear what "earlier
iterations" meant.  Are these some hypothetical iterations that precede
the "first" and "second", or just the "first" and "second" (as
intended), or all three?

To that end, perhaps a small clarification:

s/Earlier iterations have/The first two iterations had/

(The change from "have" to "had" aims to suggest that at this time and
hence any such deployments are strictly in the past).

This is of course not a critical edit, adopt or ignore at your
discretion.

-- 
Viktor.

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

Re: [DNSOP] [Last-Call] [Ext] Opsdir last call review of draft-ietf-dnsop-dnssec-bcp-03

[Viktor Dukhovni]

On Sun, Sep 25, 2022 at 08:27:19PM +, Paul Hoffman wrote:

> > In:
> > 
> >3.  Additional Cryptographic Algorithms and DNSSEC
> > 
> >   [...]
> >   The GOST signing algorithm [RFC5933] was also adopted, but has seen
> >   very limited use, likely because it is a national algorithm specific
> >   to a very small number of countries.
> > 
> > GOST is more than merely unpopular, the underlying revision of the GOST
> > algorithms have been deprecated and replaced, and RFC 8624 lists GOST as 
> > "MUST NOT"
> > for signing.
> 
> That is being rectified in the DNSOP WG, albeit too slowly to be
> reflected in this document.

Note that my point was not about the status of GOST viz DNSSEC, but
rather that the Russian Federation has deprecated and superseded the
version of GOST (GOST R 34.10-2001) that is the basis of algorithm 12.

Therefore, its use even inside .RU/.рф is no longer appropriate. The
algorithm is pining for fjords ().

> > I take issue with the next paragraph:
> > 
> >   Implementation developers who want to know which algorithms to
> >   implement in DNSSEC software should refer to [RFC8624].  Note that
> >   this specification is only about what algorithms should and should
> >   not be included in implementations: it is not advice for which
> >   algorithms that zone operators should and should not sign with, nor
> >   which algorithms recursive resolver operators should or should not
> >   validate.
> > 
> > Sure, the opening sentence of Section 3.1 reads:
> > 
> >   The following table lists the implementation recommendations for
> >   DNSKEY algorithms.
> > 
> > but an attentive operator should and will indeed take this advice into
> > consideration.  Many have already, and adoption of the deprecated 
> > algorithms 5
> > and 7 have declined by ~95% from their peak values.
> 
> This document is not the place to re-litigate the scope of RFC 8624,
> not is it a good place to say what "an attentive operators should" do
> other than to read the listed RFCs.

Well, in that case it should also not make a strong disclaimer to the
effect that 8624 is not advice to operators.  It plainly is used as
such.  Perhaps silence on that topic would be best.

-- 
Viktor.

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

Re: [DNSOP] [Last-Call] Opsdir last call review of draft-ietf-dnsop-dnssec-bcp-03

[Viktor Dukhovni]

On Sun, Sep 25, 2022 at 11:11:44AM -0700, Gyan Mishra via Datatracker wrote:

> The document reads well and is ready for publication.  
> 
> I do not see any issues with the draft.

I largely concur, but do have a few comments:

In the final two sentences of:

1.  Introduction

   [...]It also points to the relevant
   IANA registries that relate to DNSSEC.  It does not, however, point
   to standards that rely on zones needing to be signed by DNSSEC.

it is not completely obvious to me (and perhaps more so to the uninitiated) what
the final sentence is about.  Is this about DANE and the like?  An example could
make this clear.

It may be worth mentioning in:

1.1.  DNSSEC as a Best Current Practice

   Some observers note that, more than 15 years after the DNSSEC
   specification was published, it is still not widely deployed.  Recent
   estimates are that fewer than 10% of the domain names used for web
   sites are signed, and only around a third of queries to recursive
   resolvers are validated.  However, this low level of implementation
   does not affect whether DNSSEC is a best current practice; it just
   indicates that the value of deploying DNSSEC is often considered
   lower than the cost.  Nonetheless, the significant deployment of
   DNSSEC beneath some top-level domains (TLDs), and the near-universal
   deployment of DNSSEC for the TLDs in the DNS root zone, demonstrate
   that DNSSEC is suitable for implementation by both ordinary and
   highly sophisticated domain owners.

that part of the reluctance to deploy has been immaturity of tools, and lack of
skilled technical staff.  At least the tooling has undergone significant
improvement recently, and further automation is in active development.

In:

2.  DNSSEC Core Documents

   *  [RFC3110] defines how to use the RSA signature algorithm (although
  refers to other documents for the details).  RSA is still the most
  popular signing algorithm for DNSSEC.

it may be worth mentioning that ECDSA P256 adoption is now almost as widely
deployed for zone signing as RSA (by count of signed zones).

In:

3.  Additional Cryptographic Algorithms and DNSSEC

   [...]
   The GOST signing algorithm [RFC5933] was also adopted, but has seen
   very limited use, likely because it is a national algorithm specific
   to a very small number of countries.

GOST is more than merely unpopular, the underlying revision of the GOST
algorithms have been deprecated and replaced, and
 lists GOST as "MUST NOT"
for signing.

I take issue with the next paragraph:

   Implementation developers who want to know which algorithms to
   implement in DNSSEC software should refer to [RFC8624].  Note that
   this specification is only about what algorithms should and should
   not be included in implementations: it is not advice for which
   algorithms that zone operators should and should not sign with, nor
   which algorithms recursive resolver operators should or should not
   validate.

Sure, the opening sentence of Section 3.1 reads:

   The following table lists the implementation recommendations for
   DNSKEY algorithms.

but an attentive operator should and will indeed take this advice into
consideration.  Many have already, and adoption of the deprecated algorithms 5
and 7 have declined by ~95% from their peak values.

-- 
Viktor.

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

Re: [DNSOP] Representing DNS Messages in JSON (RFC 8427): ugly EDNS

[Viktor Dukhovni]

On Wed, Sep 14, 2022 at 10:42:26AM +0200, libor.peltan wrote:

> Dne 13. 09. 22 v 18:21 Viktor Dukhovni napsal(a):
> > The "OPT-RR" is message metadata, and so should not be confused with
> > other sorts of additional records.  (TSIG would also fall into that
> > bucket).
> 
> Thank you for this point. So we should invent a way how to convert OPT 
> record into properties of the JSON-represented message structure.

That could be useful.  Someone would have to invest the energy to push
this forward.  Do you have the cycles?

> > I should also note that in terms of presentation forms, the SVCB record
> > is particularly challenging, since it also sports extensible options of
> > arbitrary types, and requires both a generic presentation form (for not
> > known options) and a type-specific form for known options.
> 
> It seems that SVCB will be standardized soon, which makes me think that 
> we may inspire ourselves.

Well, there is presently no specification of a JSON representation of
SVCB records.  The wire forms in combination with the presentation names
of the options generally suggest somewhat natural encodings, but the
larger picture is IMHO somewhat murky.  The RRtype in question has
elements of an "open" type (new field schemata can be added as we
go along).  We specify wire forms and (zone file) presentation forms,
but neither is sufficient for an interoperable and natural JSON form.

Just capturing the presentation form is unappealing, since it represents
lists and other structured elements poorly.

> It might be possible to invent a presentation format for EDNS (despite 
> it does not appear in zonefiles, it should be still useful for other 
> purposes), which would use the same tricks as SVCB presentation format. 
> What do you think?

Sure, but is there enough "energy" (enthusiasm) to do this?

-- 
Viktor.

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

Re: [DNSOP] Representing DNS Messages in JSON (RFC 8427): ugly EDNS

[Viktor Dukhovni]

On Tue, Sep 13, 2022 at 10:33:44AM +0200, libor.peltan wrote:

> while implementing RFC 8427 in Knot DNS, we found that this RFC does not 
> say anything about EDNS option.

One might the case that the EDNS(0) OPT-RR is a "pseudo-RR", and so does
not follow general RR presentation format.  Indeed, for example, "dig"
does not display its content as an "additional" record.  So it is not
surprising that treating it as a general RR yields poor results.

> Do you think we should improve this, making the JSON representation of 
> OPT anyhow more useful?

The "OPT-RR" is message metadata, and so should not be confused with
other sorts of additional records.  (TSIG would also fall into that
bucket).

> If so, how do you think we should proceed? Writing a new RFC draft 
> updating this?

Standardising presentation forms of EDNS(0) data and options would IMHO
be useful, but are I think a somewhat separate concern from other RR
types.  OPT RRs should for example never be seen in zone files, or in
(additional) data returned to applications by a stub resolver.

On Tue, Sep 13, 2022 at 12:33:37PM +0200, Petr Špaček wrote:

> I think this is a sign of a more generic problem: EDNS options sometimes 
> do not have standardized and well described "presentation" format.
> 
> If we were to fix that I think we should have one catch-all RFC to 
> define missing presentation forma(s) for all known EDNS options [11] 
> (it's not that many) and then require new RFCs to specify it.

I am in favour.

I should also note that in terms of presentation forms, the SVCB record
is particularly challenging, since it also sports extensible options of
arbitrary types, and requires both a generic presentation form (for not
known options) and a type-specific form for known options.

What makes SVCB even more "interesting", is that some of the options are
compound types (lists, structures, ...) and their JSON presentation
forms really should go beyond the string presentation form encodings, to
a proper structural decomposition of each option.

We don't currently even have a way to define such grammars in DNS RFCs,
all we know how to do is specify wire forms and zone file syntax.

-- 
Viktor.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Thu, Sep 08, 2022 at 03:06:45PM +, Paul Hoffman wrote:

> > If no AliasMode record was processed, then $QNAME would be the
> > origin name PLUS the prefix(es) of type attrleaf ( underscore
> > thingies). Those won't be legitimate A/ owner names (and
> > shouldn't exist), and if a client did that it would be harmful (to
> > the client), at least a little bit harmful (trying something that
> > won't work.)
> 
> If this proposed change is only for something that is a bit harmful to
> the client (trying something that won't work), then I don't think this
> reaches the bar for making a change after IETF and IESG evaluation.
> The amount of process work that is necessary to make this technical
> change far outweighs the advantage to clients who are unaware of the
> problem that this thread has exposed.

This is a bug fix, the proposed behaviour makes no sense when $QNAME
is the unaltered (attrleaf prefixed) starting point.  The current
meaning was not intended.  If the edit can be made without any
major process, just a note to the RFC editor, it'll save errata,
and possible confusion later.

The document is on hold anyway, the fix is elementary and obvious.  I am
not a process wonk, I'm happy to let those who are go at it.  With the
suggested change made, I'm done.

-- 
Viktor.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Thu, Sep 08, 2022 at 02:08:27PM +1000, Martin Thomson wrote:

> On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote:
> > If no AliasMode record was processed, then $QNAME would be the origin 
> > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those 
> > won't be legitimate A/ owner names (and shouldn't exist), and if a 
> > client did that it would be harmful (to the client), at least a little 
> > bit harmful (trying something that won't work.)
> 
> (FWIW, I had trouble parsing this last bit.)
> 
> Can the AliasMode record reference a name that includes attrleaf
> labels, such that this could be as non-functional as using the
> attrleaf-laden original $QNAME?

It can, but that would be a bad idea in general, unless one was
absolutely sure that there's a ServiceMode record at the target,
and that's all that the AliasMode record is for.  And if A/
records for the qname fail to be discovered should a fallback
be attempted, all's well, since none were expected.

This touches on the RFC1123 question, which I think the WG did not want
to tackle (as too late for a substantive change) at this time.

But in any case, wheh there were no AliasMode records, and we're
using SVCB attrleaf prefixes for the original $QNAME, there really
was no intention to try that $QNAME as a fallback, as confirmed by
Ben (IIRC upthread at some point).

-- 
Viktor.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

> Yes, and catching COVID on Friday didn't help.  Will attempt to send a
> pull request for just the $QNAME fix shortly.

Making a pull request does not preclude also Cc'ing the list.  Which
is what I'm doing now and was planning to do in any case:

https://github.com/MikeBishop/dns-alt-svc/pull/399/files

--- a/draft-ietf-dnsop-svcb-https.md
+++ b/draft-ietf-dnsop-svcb-https.md
@@ -532,12 +532,13 @@ noted in {{client-failures}} and {{ech-client-behavior}}).

 SVCB-optional clients SHOULD issue in parallel any other DNS queries that might
 be needed for connection establishment if the SVCB record is absent, in order 
to minimize delay
 in that case and enable the optimizations discussed in {{optimizations}}.

 Once SVCB resolution has concluded, whether successful or not,
+if at least one AliasMode record was processed,
 SVCB-optional clients SHALL append to the priority list an
 endpoint consisting of the final value of $QNAME, the authority
 endpoint's port number, and no SvcParams.  (This endpoint will be
 attempted before falling back to non-SVCB connection modes.  This ensures that
 SVCB-optional clients will make use of an AliasMode record whose TargetName has
 A and/or  records but no SVCB records.)

-- 
VIktor.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Wed, Sep 07, 2022 at 03:36:16PM -0700, Warren Kumari wrote:

> I chatted with Viktor Dukhovni late last week, and he promised us a
> sentence to solve all that ails us… or, at least, a simple, clear, concise
> sentence which only clarifies what appears to have been intended.
> 
> I suspect that US Labor day vacation got in the way, but I hope to
> have it soon.  If not, I think we just stick with the original - 'tis
> not perfect, but all can be fixed in a -bis[0].

Yes, and catching COVID on Friday didn't help.  Will attempt to send a
pull request for just the $QNAME fix shortly.

-- 
Viktor.

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

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Wed, Aug 31, 2022 at 01:39:32AM -0700, Brian Dickson wrote:

> Here are some proposed text changes, per Warren's invitation to send text:
> 
> In section 1.2, change:
> 
> 2.  TargetName: The domain name of either the alias target (for
>AliasMode) or the alternative endpoint (for ServiceMode).
> 
> to:
> 
> 2.  TargetName: Either the domain name of the alias target (for
> AliasMode) or the host name of the alternative endpoint (for ServiceMode).

This looks correct.  The alternative target name needs to be a valid
hostname.

> In section 2.4.2, change:
> 
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records alongside this
>SVCB record, [... unchanged ...]
> 
> to:
> 
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records at the service name,
>[... unchanged ...]

This is correct, because in the presence of one or more AliasMode
records the ServiceMode record is no longer "alongside" the A/
records.

> In section 2.4.3, change:
> 
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters.
> 
> to:
> 
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters. The TargetName MUST be a host name
>(as defined in [DNSTerm].)

This is basic conformance with RFC 1123 section 2, avoids
interoperability issues with proxies, and various software that
validates hostnames in applications and DNS resolvers.  Otherwise, this
document may need to update RFC 1123, relaxing the syntax rules for
hostnames.

> In section 3, the following changes are proposed; they introduce a new term
> LASTNAME to be used to disambiguate the $QNAME reference so as to remove
> ATTRLEAF prefixes from the appended target:
> 
> 
>1.  Let $QNAME be the service name plus appropriate prefixes for the
>scheme (see Section 2.3).
> 
> becomes:
> 
>1.  Let $QNAME be the service name plus appropriate prefixes for the
>scheme (see Section 2.3). Let $LASTNAME be the service name without
>any prefixes.
> 
> 
>3.  If an AliasMode SVCB record is returned for $QNAME (after
>following CNAMEs as normal), set $QNAME to its TargetName
>(without additional prefixes) and loop back to step 2, subject
>to chain length limits and loop detection heuristics (see
>Section 3.1).
> 
> becomes:
> 
>3.  If an AliasMode SVCB record is returned for $QNAME (after
>following CNAMEs as normal), set $QNAME to its TargetName
>(without additional prefixes), set $LASTNAME to this new $QNAME
>and loop back to step 2, subject to chain length limits and
>loop detection heuristics (see Section 3.1).
> 
> 
>Once SVCB resolution has concluded, whether successful or not, SVCB-
>optional clients SHALL append to the priority list an endpoint
>consisting of the final value of $QNAME, the authority endpoint's
>port number, and no SvcParams.  (This endpoint will be attempted
>before falling back to non-SVCB connection modes.  This ensures that
>SVCB-optional clients will make use of an AliasMode record whose
>TargetName has A and/or  records but no SVCB records.)
> 
> becomes:
> 
>Once SVCB resolution has concluded, whether successful or not, SVCB-
>optional clients SHALL append to the priority list an endpoint
>consisting of the final value of $LASTNAME, the authority endpoint's
>port number, and no SvcParams.  (This endpoint will be attempted
>before falling back to non-SVCB connection modes.  This ensures that
>SVCB-optional clients will make use of an AliasMode record whose
>TargetName has A and/or  records but no SVCB records.)
> 

This scary-looking long edit is an attempted bug correction.  But Ben
tells me that the actual intent is to only add $QNAME to the search list
if there's a non-zero number of AliasMode records encountered.
Otherwise, there is no need to append any $QNAME to the list, since it
is the same as the legacy fallback (non-SVCB connection modes below).

A simpler fix should be possible.

>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
> 
> becomes:
> 
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
> 
>the authority endpoint's port number, and no SvcParams.

And then this change likely becomes redundant.

> One additional suggested addition to the end of section 3.1 is:
> 
>If DNS responses are cryptographically protected, and 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Mon, Aug 29, 2022 at 09:32:24PM +, Warren Kumari wrote:

> > * For the rfc1123 section 2 topic, it may make sense to clarify the text
> >  to say "domain name" rather than "hostname":
> >> An "alternative endpoint" is a hostname, port number, and other
> >> associated instructions to the client on how to reach an instance
> >> of service.
> >   Everywhere else in the normative sections such as 1.2 and 2.1 we
> >   say that the TargetName is a "domain name" (aligned with the
> > clarification in rfc8499
> >   on the difference between host and domain names).
> 
> I think that the current is clear enough. I agree that it would probably
> have been better as 'domain name' if we had caught that at WGLC / IETF LC,
> but I think it would be gratuitous / not rise to the level of 'futzing
> after approval'...

I still suspect that the document's multiple explicit suggestions that
IP addresses can be reliably associated with _leaf labels is a mistake.
As pointed out, these will run into various barriers, and changing the
text to make this clear is IMHO warranted.

* The initial $QNAME (with _leaf prefixes) should not be used as a
  potential "hostname" to connect to (this is an inadvertent error,
  the intent was to only use $QNAME after one or more AliasMode
  records).

* If the final AliasMode target is an _leaf name, then it is likely not
  a viable TCP endpoint, and can only be used for further chained SVCB
  lookups.

* The target names in non AliasMode records must be valid hostnames.

I don't correcting the above issues change the intent of the draft,
though they could be material enough to bring it back for a quick fix of
at least this issue.

Whether any clarifications of failover (without material changes) are
also warranted is not on my list of essential todos.  I'd have chosen
less fuzzy semantics, but clearly that's not the consensus, which is
just fine.  Thanks all for a very productive exploration of these
late to surface topics.

-- 
Viktor.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Mon, Aug 29, 2022 at 12:33:55PM -0400, Erik Nygren wrote:

> On paths forward on the draft as it stands to clarify without making
> significant technical changes (which I don't think are necessary):
> 
> * Are there particular clarifications we can/should add to help make
> the current behavior more clear to readers?  For example, would having
> some examples of the failure cases (without changing the semantics)
> help?  Note that since the fallback behavior is a SHOULD not a MUST
> for clients, it can't necessarily be relied upon.


Likely so, especially to illustrate:

* SVCB/HTTPS lookup failure in the initial SVCB query (i.e. not 
NOERROR/NODATA
  or NXDOMAIN).

* SVCB/HTTPS lookup failure after some non-zero number of AliasMode records
  that result in a new target $QNAME.

* A/ lookup failure of the "final" target name (does this lookup still
  happen if SVCB/HTTPS lookup fails after a non-zero number of
  AliasMode records are processed?)

* Connection failure to some or all of the targets/ports resolved via 
SVCB/HTTPS
  records (should/may happy eyeballs probe the resolved SVCB/HTTPS
  targets in parallel with the fallback original name or $QNAME
  fallback?)

Clarify which $QNAME is appended to the target list as a fallback.


> * This might be too much of a technical change at this point,
>   but would it make sense to change the SHOULD to a MAY on client
>   fallback behavior?  Clients implementations may choose to ignore the
>   SHOULD so this doesn't change the contract.

Given the stated permissive stance (to quote Paul Vixie from another
forum/thread: browsers gonna browse), perhaps "MAY" is more appropriate.

> * For the rfc1123 section 2 topic, it may make sense to clarify the text
>  to say "domain name" rather than "hostname":
>
>> An "alternative endpoint" is a hostname, port number, and other
>> associated instructions to the client on how to reach an instance
>> of service.
>
>   Everywhere else in the normative sections such as 1.2 and 2.1 we say
>   that the TargetName is a "domain name" (aligned with the
>   clarification in rfc8499 on the difference between host and domain
>   names).
>
> On the rfc1123s2 front. a corner-case that might be encountered is
> that Proxies might be confused by "When connecting using a SVCB
> record, clients MUST provide the final TargetName and port to the
> proxy" in the case where proxies don't expect a domain name (eg, with
> an underscore prefix).  I don't know if there is any warning we should
> provide about this corner-case, or cover that in the future if it
> turns out to be a problem?

Just saying that it is a domain name does not fundamentally address the
issue, since the draft (almost RFC) in multiple places suggests that
even domain names adorned with attrleaf prefixes are potential owner
names of A/ records, which runs into conflict with 1123 (and as
you note potential issues with proxies, or other software that expects
"hostnames" as valid names for A/ records).

> For the future, there are subsequent drafts that could be introduced:
> 
> * We could add an optional "nofallback" SvcParam to AliasMode as Brian
> suggests, but in a future draft. (This would be the first SvcParam on
> AliasMode, but they are allowed and introducing them might help
> prevent ossification of this extension point.)

Sounds reasonable.

> * Introducing an optional "Alt-Used" equivalent (eg, "Service-Used")
>   that provides information about the SVCB/HTTPS RR path followed
>   would be very useful to service operators.  We got stuck on not
>   finding the right content vs privacy balance here, and experience
>   with Alt-Used is that not all clients will implement it regardless.
>   But if we had this and got enough clients to implement then it could
>   help address some of Brian's concerns about getting better
>   visibility in the fallback case.  (eg, "Service-Used: type=fallback"
>   as an HTTP header)

An interesting idea.  Certainly such signals can be helpful to operators
to detect problems and/or guage when infrastructure changes become
viable.

-- 
Viktor.

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

Re: [DNSOP] [Editorial Errata Reported] RFC9276 (7104)

[Viktor Dukhovni]

On Thu, Aug 25, 2022 at 09:01:39PM -0700, RFC Errata System wrote:

> The following errata report has been submitted for RFC9276,
> "Guidance for NSEC3 Parameter Settings".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7104
> 
> --
> Type: Editorial
> Reported by: Stefan Ubbink 
> 
> Section: 2.2
> 
> Original Text
> -
> Smaller zones, or large
> but relatively static zones, are encouraged to not use the opt-opt
> flag and to take advantage of DNSSEC's authenticated denial of
> existence.
> 
> 
> Corrected Text
> --
> Smaller zones, or large
> but relatively static zones, are encouraged to not use the opt-out
> flag and to take advantage of DNSSEC's authenticated denial of
> existence.
> 
> 
> Notes
> -
> There is a typo, "opt-opt" should be "opt-out".


Thanks, this correction is valid.  Indeed it should have been "opt-out".

-- 
Viktor.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Fri, Aug 26, 2022 at 07:29:06AM -0400, Ben Schwartz wrote:

> > I also noted an issue around the initial $QNAME having prefix labels (in
> > the case of SVCB rather than HTTPS), and so this is likely not the name
> > you want appended as a fallback to the target list.
> >
> 
> Indeed, I think this is a clarity/precision problem that we should
> correct.  Specifically, this "final value of $QNAME" endpoint is only used
> if it is not the initial value of $QNAME (i.e. if an AliasMode record was
> found).

Yes, and I think this was mostly an editorial omission, I seems unlikely
that this edge case was intentional.  This will I hope be corrected.

> > Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
> > preclude publishing A/ records there, making some of the example
> > configurations in the draft impractical.
> 
> I don't agree with this reading of RFC 1123.  There is no requirement that
> address records only be placed on hostnames, and there is no requirement
> that TargetName be a hostname.  If I were making an argument here, it might
> be about compatibility with RFC 8553 (Attrleaf), but hopefully this is
> mostly moot per the above.

Well, the maintainers of BIND don't seem to take this more liberal
interpretation:


https://bind9.readthedocs.io/en/v9_18_6/reference.html#glossary-of-terms-used


check-names

Grammar zone (hint, mirror, primary, secondary, stub):

check-names ( fail | warn | ignore );

Grammar options, view:

check-names ( primary | master | secondary | slave | response )
( fail | warn | ignore ); // may occur multiple times

Blocks: options, view, zone (hint, mirror, primary, secondary,
stub)

Tags: server, query

Restricts the character set and syntax of certain domain names
in primary files and/or DNS responses received from the network.

This option is used to restrict the character set and syntax of
certain domain names in primary files and/or DNS responses
received from the network. The default varies according to usage
area. For type primary zones the default is fail. For type
secondary zones the default is warn. For answers received from
the network (response), the default is ignore.

The rules for legal hostnames and mail domains are derived from
RFC 952 and RFC 821 as modified by RFC 1123.

  -->   check-names applies to the owner names of A, , and MX
  -->   records. It also applies to the domain names in the RDATA of NS,
  -->   SOA, MX, and SRV records. It further applies to the RDATA of PTR
  -->   records where the owner name indicates that it is a reverse
  -->   lookup of a hostname (the owner name ends in IN-ADDR.ARPA,
  -->   IP6.ARPA, or IP6.INT).

-- 
Viktor.

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

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:

> Relatedly, the results presented by EKR [1] at the most recent DNSOP
> meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
> records through their local resolver.  To me, this implies that functional
> origin endpoints are likely to be required even if client software gains
> SVCB/HTTPS support.

This is why my suggested client behaviour was cognisant of this impediment.

- If the client's *initial* SVCB lookup succeeds, *then* fallback is
  no longer an option.

- If initial SVCB resolution fails (SERVFAIL, timeout, ...)
  then the client behaves as though the SVCB record does not exist.

This results in more predictable behaviour, without optimising for
failure.  If the origin zone directs the service elsewhere, and there
are no last-mile DNS lookup roadblocks, then the protocol becomes
"reliable" (optimises for success and predictability, over fallback
recovery leading to potentially/eventually undesirable outcomes).


> I believe this balance could be revisited in several years' time, if "HTTPS
> Record" support becomes sufficiently universal.

Indeed it is a possible position to say that the Internet is not yet
ready for semantically distinct services seen by SVCB-aware and legacy
clients.  But I think that latching on success of the initial lookup
largely addresses the present impediments to reliance on SVCB.

> Viktor notes with concern that AliasMode is a "non-deterministic
> redirect".  Instead, the draft attempts to model the client behavior as a
> preference ordered stack of endpoints:
> 

I also noted an issue around the initial $QNAME having prefix labels (in
the case of SVCB rather than HTTPS), and so this is likely not the name
you want appended as a fallback to the target list.

Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
preclude publishing A/ records there, making some of the example
configurations in the draft impractical.

-- 
Viktor.

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

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Wed, Aug 24, 2022 at 07:11:16PM -0400, Eric Orth wrote:

> > Regarless, once AliasMode records are found, these MUST be used and
> > partial lookup failure along a non-empty (so far) alias chain needs
> > to be fatal.
> 
> This would be a big non-editorial change from the current draft, and I
> don't see any need for such a rule rising to the "exceptional
> circumstances" bar at this stage.  Why would such behavior be necessary
> beyond a vague desire to be more consistent with the behavior of CNAMEs?

Because otherwise, even SVCB-aware client behaviour is subject to random
rolls of the dice.  Sometimes they follow the alias, and sometimes
randomly, when a DNS query times out, they go some place unexpected.

Your zone serving the AliasMode record is working, but the target zone
has a glitch, should your legacy service now see a spike in unexpected
traffic from AliasMode aware clients to the wrong destination?  Is it a
good idea to require it to also serve all the clients that SHOULD
normally use the SVCB location.

> As a client implementor, I think the draft already has the correct behavior
> here, and I do not support making changes at this time.  I don't like when
> implementing new specs makes my client more susceptible to errors in cases
> where a non-implememnting client would have kept working fine (except for
> cases of obvious domain misconfiguration or where breaking is important for
> security).

Well, except that resolving the SVCB chain to its conclusion (actual
ServiceMode RRset, NODATA or NXDOMAIN) is NOT an error.  That's the
configured service location.  Yes some legacy clients might for now make
do with a legacy location, but I rather think that SVCB-aware clients
SHOULD NOT be rolling the dice except when SVCB queries are completely
unavailable (the initial SVCB query runs into "lookup failure").

> If a client receives non-aliased A and  records that a
> non-HTTPS-implementing client would have been able to use
> successfully, why should an HTTPS-aware client be forced to ignore
> them and refuse to load a website? This is not at all the same
> situation as a CNAME records where it isn't generally possible to also
> receive non-aliased A and  records.

Because predictable behaviour is I think the better option, and once the
initial SVCB lookup succeeds, there is good reason to expect the rest to
work.

Yes, a shrinking minority of clients will use the legacy location, but
we should I believe not optimise for these.

As it stands, AliasMode is a non-deterministic redirect even for
SVCB-aware clients, that makes me uneasy.  I could of course find that
Brian and I are the only ones that share this view, but I hope that's
not the case.

-- 
Viktor.

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

Re: [DNSOP] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Tue, Aug 23, 2022 at 02:51:33PM -0700, Brian Dickson wrote:

>- The problem is whether/when/how the DNS queries are considered
>failures, and whether/when/how some sort of fall-back procedure is followed
>in those cases.

Indeed "failure" may not be consistently defined.

  - On the one hand we have "lookup failure" to locate the SVCB (or HTTPS)
records: SERVFAIL, timeout, loop, "bogus" (if doing in application
DNSSEC validation), ...

  - On the other we have "lookup success" that establishes the
non-existence of the desired  SVCB (or HTTPS) record, i.e.
NODATA or NXDOMAIN.

In Section 3, "failure" appears to subsume both cases:

   Once SVCB resolution has concluded, whether successful or not, SVCB-
   optional clients SHALL append to the priority list an endpoint
   consisting of the final value of $QNAME, the authority endpoint's
   port number, and no SvcParams.  (This endpoint will be attempted
   before falling back to non-SVCB connection modes.  This ensures that
   SVCB-optional clients will make use of an AliasMode record whose
   TargetName has A and/or  records but no SVCB records.)

But then in 3.1:

   If DNS responses are cryptographically protected (e.g. using DNSSEC
   or TLS [DoT][DoH]), and SVCB resolution fails due to an
   authentication error, SERVFAIL response, transport error, or timeout,
   the client SHOULD abandon its attempt to reach the service, even if
   the client is SVCB-optional.  Otherwise, an active attacker could
   mount a downgrade attack by denying the user access to the SvcParams.

One immediate difficulty is that while a client can request
DNSSEC-validated answers (by setting the DO bit in outgoing queries, or
trusting the "AD" bit from a *loopback* validating recursive resolver),
it is not possible to know whether the response is not "crytographically
protected" when the query times out, or the response is SERVFAIL, ...

So the intent in 3.1 is somewhat unclear.  Perhaps the idea is that the
client could have prior knowledge that it ought to have access to
DNSSEC-validated answers (no last-mile issues)?  Some clarification may
be appropriate.

Secondly, given that $QNAME (in the case of SVCB rather than HTTPS)
starts out "prefixed" with attrleaf labels, there may be issues
associating A/ records with such labels, in that these violate RFC
1123 Section 2.1:

https://www.rfc-editor.org/rfc/rfc1123#section-2

2.1  Host Names and Numbers

  The syntax of a legal Internet host name was specified in RFC-952
  [DNS:4].  One aspect of host name syntax is hereby changed: the
  restriction on the first character is relaxed to allow either a
  letter or a digit.  Host software MUST support this more liberal
  syntax.

  ...

zone file validators may flag attrleaf names with address records as
errors.  This is not an issue for HTTPS records that don't use prefix
labels, but it is an issue for SVCB.  Since the intent is to be sure
to at least follow AliasMode indirection, even if no SVCB records are
ultimately found, the appended name should be *unprefixed* when no
AliasMode records were followed.

It might also be noted that when the final AliasMode target name has
_label prefixes, the zone owner implicitly expects SVCB records at that
target, since such names again should not have A/ records (or is
2.1 of RFC1123 now largely outdated).


>- The ONLY concern is whether an AliasMode record (particularly at the
>zone apex) is treated EXACTLY the same as a constrained CNAME (i.e.
>unconditional QNAME rewrite if the RRTYPE is appropriate).

This question of course only makes sense if the client has managed to
obtain at least one AliasMode SVCB or HTTPS record, thus establishing
that the ambient network environment was not hostile to SVCB/HTTPS
resolution at the time of that query.

In that situation I'd be inclined to make a *stronger* statement:

* When the initial SVCB (also HTTPS, ...) query returns an AliasMode
  result, lookup failures in all subsequent SVCB/HTTPS queries are "fatal"
  even for SVCB-optional clients.

This more closely approximates predictable client behaviour that doesn't
randomly ignore redirection records on unexpected transient "lookup
failures" (see above vs. "lookup success").

Of course if even the initial lookup fails, the client may well be using
unsecured UDP behind a broken CPE (that mangles queries for unfamiliar
record types), and may have no ability to resolve any SVCB or HTTPS
records, and have no access to DoH or DoT.  In that case it seems
somewhat reasonable for SVCB-optional to fall back to status quo ante.

>   - Unconditional would imply that an HTTPS-aware (or SVCB-aware, if
>   you prefer) client never backtracks to the origin name to look up A/
>   records for use, or more precisely, if the client does look up the 
> A/
>   records speculatively, if it gets an AliasMode record, it does not use
>   those 

Re: [DNSOP] [Ext] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

[Viktor Dukhovni]

On Thu, Aug 18, 2022 at 09:12:33AM +1000, Mark Andrews wrote:

> Well anyone using RedHat Enterprise Linux 9 / Oracle Linux 9 already
> has RSASHA1 / NSEC3RSASHA1 disabled.
> 
> BIND will automatically disable these algorithms as of the September
> releases if they are not supported by the crypto provider.  So it will
> no longer require named.conf changes. 

I forgot about this, indeed with support for:

{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 
sha1-with-rsa-signature(5)}

effectively removed from at least one mainstream crypto library,
algorithms 5 and 7 are becoming "insecure", whether we say so or not, so
we may as well say so.

Perhaps the new draft is one way to get the message out to the operators
of the holdout zones.

-- 
Viktor.

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

Re: [DNSOP] [Ext] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

[Viktor Dukhovni]

On Tue, Aug 16, 2022 at 02:55:35PM +, Paul Hoffman wrote:

> Another way to look at this is not from all signed delegations
> anywhere, but for web sites that are most popular. Using the Tranco
> list, choosing from the top 100,000 names, 6,389 are signed; of those,
> 349 sign with algorithm 5 or 7. Thus, for the popular sites, the
> percentage is closer to 5%, not 1%.

While I'm not impressed by the significance of the last ~900k of the
Tranco list, indeed there is some concentration of deprecated DNSSEC
algorithms closer to the top of the list, among the top 10k we see
the domains below my sig.

How realistic is it to prod these to migrate?  The DHS folks had
recently put out an RFP for managed DNS service, not only for the .GOV
registry, but also for operation of the delegated domains, and
presumably at some point many of the .GOV slowpokes might move to a
managed service with more modern keys, ...  This will likely take
a couple of years (if not delayed or cancelled).

As for the rest, not clear what would cause them to switch, and how hard
we should try.  There hasn't been much downward momentum in algorithm 5
and 7 use after the initial 93% decline at major hosting providers.

[ Even transip.nl, who've migrated all their customers, haven't yet
migrated their own domain.  Cobbler's children and all that... ]

-- 
Viktor.

paypal.com 77
comcast.net 145
cdc.gov 179
ietf.org 473
yandex.com 548
paloaltonetworks.com 633
xfinity.com 646
va.gov 650
nist.gov 664
service-now.com 842
comcast.com 901
cmu.edu 939
uchicago.edu 991
ed.gov 999
uk.com 1065
census.gov 1108
sec.gov 1148
senate.gov 1176
icann.org 1333
accenture.com 1369
centralnic.net 1433
archives.gov 1489
tamu.edu 1542
uspto.gov 1565
treasury.gov 1584
fcc.gov 1638
us.com 1671
paypal.me 1918
pitt.edu 1998
eu.com 2648
hud.gov 2668
defense.gov 2806
mass.gov 2923
eia.gov 2946
federalregister.gov 2996
cms.gov 3030
filezilla-project.org 3168
lsu.edu 3204
nsf.gov 3292
imperial.ac.uk 3434
maryland.gov 3537
tn.gov 3667
transip.nl 3962
supremecourt.gov 4113
us.org 4305
ky.gov 4382
gao.gov 4583
lbl.gov 4598
medicare.gov 4633
handle.net 4699
ustc.edu.cn 4706
paypalobjects.com 5051
d-net.pro 5119
healthcare.gov 5123
consumerfinance.gov 5458
tznic.or.tz 6065
ru.com 6243
planalto.gov.br 6366
kh.edu.tw 6652
ga.gov 6658
uib.no 6738
umbc.edu 6869
hrsa.gov 7076
k8.com.br 7217
paypalinc.com 7314
nrel.gov 7599
uniregistry.info 7608
llnl.gov 7663
export.gov 7833
ic.ac.uk 7890
treas.gov 8072
upf.edu 8217
concordia.ca 8258
nga.gov 8366
in.net 8431
nau.edu 8480
ulisboa.pt 8650
comcastbusiness.net 8769
bea.gov 9250
uscg.mil 9579
szu.edu.cn 9745
nsa.gov 9862
uniregistry.net 9974

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

Re: [DNSOP] draft-hardaker-dnsop-must-not-sha1

[Viktor Dukhovni]

On Sat, Aug 13, 2022 at 10:48:59PM +1000, Mark Andrews wrote:

> So you are ready to replace SHA1 in NSEC3 and do a second algorithm
> renumber which is what is required to actually get rid of SHA1 or do
> you mean retire RSA-SHA1. 

No.  Please let's NOT deprecate SHA-1 in NSEC3.  The use of SHA-1 in
NSEC3 is not as part of a cryptographic signature, it is basically light
obfuscation to resist zone walking.

Generating SHA-1 collisions in the node names of the NSEC3 chain is
rather non-trivial.  Only enough collision resistance is required to
avoid practical collisions on short inputs (typically single-label
prefixes of a common parent).  Public eTLDs rarely allow registration of
multi-label child zones (.name is an exception), and even then the
labels are subject to syntax rules (LDH) that make collision attacks
difficult.

The known chosen-prefix extension attacks require at least 1024 bits
(128 bytes or two SHA-1 compression blocks) of data, and the colliding
inputs are binary data that would not be valid for registration under
a public suffix.

Effective attacks use more blocks, e.g. ~10 in:

https://www.usenix.org/system/files/sec20-leurent.pdf

which at 640 bytes is well beyond the maximum DNS name size of 255
bytes.  SHA-1 collisions can manifest in the RDATA of DNS records, but
these don't affect the NSEC3 chain.

-- 
Viktor.

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

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

[Viktor Dukhovni]

On Mon, Aug 15, 2022 at 09:29:28AM -0400, Paul Wouters wrote:

> I think our decision should be based on the deplyment statistics of SHA1
> based zones and keys. I'd love to see the trending statistics from
> Viktor to guide us here. Last time we looked it was still in the order
> of 40% or so ?
> 
> We need to be in the tail-end before we change validation recommendations
> for SHA1 from MUST to SHOULD or MAY or MUST NOT.

Amongst TLDs there are still a few that use algorithm 5 or 7, and aren't
already in the middle of an algorithm rollover to 8, 10, 13 or 14:

 alg | TLD
-+---
   7 | am
   7 | apple
   7 | beats
   7 | case
   7 | int
   7 | la
   7 | monster
   7 | samsung
   7 | storage
   7 | xn--cg4bki
   7 | xn--mgbai9azgqp6j
   7 | xn--q7ce6a
   7 | xn--y9a3aq
   5 | audio
   5 | auto
   5 | car
   5 | cars
   5 | christmas
   5 | diet
   5 | flowers
   5 | game
   5 | guitars
   5 | hosting
   5 | kg
   5 | lk
   5 | lol
   5 | mom
   5 | na
   5 | pics
   5 | xn--l1acc

Mostly smallish gTLDs, for which the total and signed delegation
counts, respectively, are:

 TLD total signed
 --- - --
 monster 88660 240
 lol 32123 473
pics 16895 142
 mom  8219 315
   audio  5171 290
game  4180 78
 hosting  2899 153
   christmas  1400 63
diet  1299 36
 flowers  1135 53
 guitars   772 15
 storage   560 15
auto   470 5
 car   320 6
cars   296 5
   apple31 1
 samsung 4 0
   beats 2 1
  xn--cg4bki 2 0
case 1 1

I don't have authoritative counts for the ccTLDs above, but these will
also be low.

-- 
Viktor.

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

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

[Viktor Dukhovni]

On Mon, Aug 15, 2022 at 09:29:28AM -0400, Paul Wouters wrote:

> I think our decision should be based on the deplyment statistics of SHA1
> based zones and keys. I'd love to see the trending statistics from
> Viktor to guide us here. Last time we looked it was still in the order
> of 40% or so ?

The stats show a substantialy decline in both algorithms 5 and 7 by
apprxoimately 93% each from their peak zone counts, but the last 7%
have been fairly static for months, with very slow to negligible
downward trends.

Presently, out of 18,975,098 working signed delegations:

* 136,295 zones use RSASHA1-NSEC3-SHA1 (7).
*  21,254 zones use RSASHA1 (5).

So the number of eTLD+1 zones that rely on SHA-1 RRSIGs is a fairly
stable ~0.8%, and a stronger nudge would be needed for the remaining
holdouts to perform algorithm rollovers.

The holdouts include, for example:

- ietf.org
- irtf.org
- icann.org
- nsa.gov
- comcast.net

In private conversation with at least one guilty party, I encountered
significant pushback to the suggestion that it is time to move on.

Concerns about operational stability, coupled with a perception of low
risk (for zones where untrusted outsiders aren't positioned to propose
hostile RRsets exploiting chosen-prefix collisions) mean that the
suggestion to take action may be seen as meddlesome intrusion.

So that final 0.8% may be a tough crowd to convince...

-- 
Viktor.

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

Re: [DNSOP] [ADD] Last Call: (Service Binding Mapping for DNS Servers) to Proposed Standard

[Viktor Dukhovni]

On Fri, Jun 24, 2022 at 05:31:28PM +, Eric Vyncke (evyncke) wrote:

> Dear DNSOP,
> 
> As this ADD WG document relies on draft-ietf-dnsop-svcb-https from the
> DNSOP WG, as the responsible AD for the ADD WG, I will appreciate your
> review of this short IETF draft.
> 
> Abstract
> 
>The SVCB DNS resource record type expresses a bound collection
>of endpoint metadata, for use when establishing a connection to
>a named service.  DNS itself can be such a service, when the
>server is identified by a domain name.  This document provides
>the SVCB mapping for named DNS servers, allowing them to
>indicate support for encrypted transport protocols.

I have read the draft.  It aims to be agnostic as to whether the
DNS server that is the subject of the SVCB record is a recursive
resolver or an authoritative nameserver for some zone (typically
delegated by its parent).

It also aims to facilitate the establishment of an authenticated
transport.  It should be noted that with authoritative delegations from
a parent zone, the "service name" for each delegated to nameserver is
always obtained from the unsigned parent-side NS RRset.

Consequently unless the transport to the parent zone nameserver is
authenticated, there is an unavoidable MiTM exposure even when the zone
with the SVCB qname is DNSSEC-signed, because an on-path attacker can
tamper with the returned NS records.

And of course if the transport to the parent nameserver is not
encrypted, the name of the desired child zone is leaked in the clear,
defeating some or most of the privacy gains from subsequent use of an
encrypted transport with the child zone nameservers.

So perhaps the document should note using SVCB to signal transport
security for nameservers derived from NS records is predicated on a
suitably secure connection to the parent zone.

The use of SVCB RRs for authoritative nameservers introduces the
possibility that the SVCB target name is different from the "service
name" in the NS record.  Such additional indirection is perhaps
surprising or even undesirable.

Also, likely DoH would not be a supported transport for authoritative
servers, with DoT or DoQ being the available options.

If this draft is to be adopted for use with authoritative nameservers
these topics would warrant some further discussion, and perhaps some
minimal text is warranted to say as much.

-- 
Viktor.

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

[DNSOP] RFC6781 Cooperating DNS provider signed zone migration

[Viktor Dukhovni]

Is anyone aware of better descriptions of cooperating DNS operator DNS
provider migrations than are found in RFC 6781 section 4.3.5.1

https://datatracker.ietf.org/doc/html/rfc6781#section-4.3.5.1

and Appendix D:

https://datatracker.ietf.org/doc/html/rfc6781#appendix-D

Both descriptions could use more detailed prose (especially appendix D
that has none), and there are some mistakes in the diagrams.

Also which of the two processes do actual hosting operators support?
(To my mind, Appendix D is the more realistic model, but it is much more
sketchy than 4.3.5.1).

Would it make sense to write a BCP that updates 6781 in light of
operational best practices in the last decade?

-- 
Viktor.

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

Re: [DNSOP] AD Review of: draft-ietf-dnsop-nsec3-guidance

[Viktor Dukhovni]

On Wed, Apr 13, 2022 at 09:37:35AM -0700, Warren Kumari wrote:

> 
> Abstract:
> "NSEC3 is a DNSSEC mechanism providing proof of non-existence by promising
> there are no names that exist between two domainnames within a zone."
> 
> The "promising" in this feels a little odd to me — RFC4033 Sec 12 says that
> "NSEC RRs **assert** which names do not exist..". RFC5155 talks about
> "showing" that names don't exist — perhaps "by asserting that there are…"
> would be better?
> 
> I'm (of course) happy to be told that "promising" was chosen for a reason
> and that it's the right term.

Thanks, I think "asserting" is better.

> Nits:
> --
> Global:
> The document uses the term 'domainname' - RFC8499 uses 'domain name'.
> Looking through published RFCs, there are ~6200 instances of 'domain name',
> ~400 of 'domain-name' and <50 domainname (and many are in things like
> ABNF). I'd suggest s/domainname/domain name/g.

Thanks.  No objections.

> Section 1 - Introduction
> Use of the opt-out feature allow large registries to only sign as many NSEC3
> [O] allow
> [P] allows

Yep.

> records as there are signed DS or other RRsets in the zone - with opt-out,
> unsigned delegations don't require additional NSEC3 records.
> 
> [O] zone - with
> [P] zone; with
> [R] readability/grammar

Yep.

> Section 2.4 - Salt
> This is true both when resigning the entire zone at once, or when
> incrementally signing it in the background where the  new salt is only
> activated once every name in the chain has been completed.
> [O]: or
> [P]: and
> [C]: When using 'both' as a conjunction, it is 'both … and', not 'both …
> or'; if this doesn't work, perhaps 'either … or'.

Yep.

> Thank you again; I know that making edits to address nits can be annoying,
> but we are expecting many people to read and review the document, and so
> having it polished is important and polite (also, once people start
> commenting on nits, they seem to continue :-) )

Much appreciated.

-- 
Viktor.

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

Re: [DNSOP] Is DNSSEC a Best Current Practice?

[Viktor Dukhovni]

On Thu, Mar 10, 2022 at 06:54:07PM +, Paul Hoffman wrote:

> Greetings again. My motivation here is kinda trivial, but I've heard
> it is a common complaint. When writing a about DNSSEC, I need to
> reference the RFC. But it's three RFCs (4033, 4034, and 4035), and
> possibly another (6840). It would be awfully nice to refer to "DNSSEC"
> with a single reference like "BCP 250".

I'm on board for a DNSSEC BCP document.  I've effectively been working
on this for some time.  Hence e.g. the NSEC3 iteration draft and an
upcoming APNIC guest post on ZSK best-practice.

Would be nice to publish more accessible text on the correct handling of
ENTs and wildcards (as e.g. malpracticed by NameCheap).

At least TLSA non-response has mostly gone away as an issue, NSEC3
iterations have come down quite significantly.  Also algorithms 5 and 7
have each lost ~93% of their peak deployment levels.

So communicating (and repeatedly nagging) best-practice does appear to
translate to operational changes, even if the time scale is ~2 years in
some cases.

-- 
Viktor.

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

Re: [DNSOP] New Version Notification for draft-ietf-dnsop-nsec3-guidance-03.txt

[Viktor Dukhovni]

On Mon, Feb 28, 2022 at 03:43:59PM +0100, Petr Špaček wrote:

> Keep this:
>  >>> 3.2.  Recommendation for validating resolvers
>  >>> Note that a validating resolver MUST still validate the signature
>  >>> over the NSEC3 record to ensure the iteration count was not altered
>  >>> since record publication (see [RFC5155] section 10.3).
> 
> And here add this as continuation of the previous sentence?
> 
> ... because the invalid signature might have additional implications. 
> E.g. EDE code, or insecure validation status if an implementation chose 
> to treat certain range of NSEC3 iteration values as DNSSEC-insecure etc.
> 
> (modulo grammar fixes etc., of course)
> 
> I think this makes the reason clear to everyone and also makes it 
> somewhat legal to ignore signature validation it IF "visible outcome" 
> does not change by doing so.
> 
> What do you think?

I don't understand this comment, the reason for the signature check is
that otherwise we get trivial downgrade attacks.  NSEC3 replies from
a signed zone with an invalid signature MUST be treated as "bogus".

What did you have in mind?  What does "visible outcome" mean?

-- 
Viktor.

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

Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

[Viktor Dukhovni]

On Wed, Dec 22, 2021 at 03:52:22PM -0500, Ben Schwartz wrote:

[ Sorry about the delayed response, on the road since Dec 24th... ]

> I don't want this draft to become an omnibus update to RFC 7671.  My goal
> is to produce a short draft that is basically parallel to RFC 7673.
> 
> If you want to pursue a broader revamp of DANE, I think that could be
> valuable, but I don't think it needs to be connected to this.

Understood, but at least now you're aware of the outstanding "loose
ends".  To the extent that they're relevant to your draft, it may be
appropriate to make any necessary adjustments.

> > So this is different from the situation with MX (and IIRC SRV) records,
> > so perhaps CNAMEs will be much more common in this context?
> 
> I think it's too early to predict the popular deployment strategies here.
> Also, SVCB + TLSA is "green field" territory, so it's up to us what we want
> to allow.

OK, so do you think that following CNAMEs to find TLSA RRs at the
expanded target name is a good idea in this context?  If not, I think
it would be reasonable to diverge from 7671 on this detail.

> > It is very much *NOT* an optimisation.  Rather it is an essential
> > element of robustness of the protocol in the face of the reality
> > of the DNS ecosystem:
> >
> > - For DANE to be useful it must not be trivially subject to
> >   downgrade by not responding to TLSA records, returning REFUSED,
> >   NOTIMP, SERFVAIL or bogus replies.
> >
> > - However, many unsigned zones are served by functionally limited
> >   to mostly-broken load-balancers that just know how to return
> >   A/ records and not much else.
> >
> > - When you send a TLSA query to such a nameserver, you often end
> >   up with a lookup failure, rather than a valid "insecure" denial
> >   of existence (proof of an insecure delegation at some parent
> >   node + insecure NODATA or NXDOMAIN).
> >
> > - For DANE to avoid downgrades, TLSA query SERVFAIL needs to lead
> >   to connection failure.
> >
> > This is why the "optimisation" in question is in fact an essential
> > element of 7671.
> >
> 
> If it's an essential element of 7671, maybe it should be mentioned in 7671!

If this is only discussed in 7672, mea culpa...

> I think this is an interesting workaround, but I'm not sure it will be
> necessary here.  SVCB is to a large extent a "green field" territory, which
> may exclude a lot of buggy legacy systems.  Also, SVCB specifically renders
> this kind of misbehavior into a hard-fail condition already [1], and
> large-scale experiments have confirmed that this does not result in a
> significant error rate.
> 
> [1]
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-08#section-3.1

The largest known (to me) cluster of poor beviour with TLSA lookups is
*.mail.protection.outlook.com, where TLSA queries return NOTIMP.
Perhaps no similar issue is present in the targets of interest here.

Things are indeed simpler if the workaround is not needed.

> > No, I am talking about a situation where AD=0 despite the fact that the
> > original name is in a signed zone, because the target of the CNAME
> > lookup is not in a signed zone:
> >
> > ; signed zone
> > www.secure.example. IN CNAME www.insecure.example.
> > www.secure.example. IN RRSIG CNAME 13 3 ...
> > _443._tcp.www.secure.example. IN TLSA 2 1 1 ...
> > _443._tcp.www.secure.example. IN RRSIG TLSA 13 5 ...
> >
> > ; unsigned zone
> > www.insecure.example. IN A 192.0.2.1
> >
> > An "A" record query for "www.secure.example" via recursive resolver will
> > return an insecure answer" with AD=0:
> >
> > www.secure.example. IN CNAME www.insecure.example.
> > www.insecure.example. IN A 192.0.2.1
> >
> > but there are in fact signed TLSA records for the qname.
> 
> Yes, so the client issues a query for TLSA at
> _443._tcp.www.secure.example.  This seems like the standard RFC 7671 CNAME
> handling.  There is no need for the client to issue a query with
> QTYPE="CNAME".

Once the work-around is not needed, then indeed the "QTYPE=CNAME" query
is also not needed to determine whether the unexpanded zone is signed.

If the workaround is needed, then the CNAME query comes into play.

-- 
Viktor.

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

Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

[Viktor Dukhovni]

On Mon, Dec 13, 2021 at 10:04:55AM -0500, Ben Schwartz wrote:

> >
> > 1.  While DANE certificate validation as described in RFCs 7671,7672 and 
> > 7673
> > is fine in SMTP, IMAP, XMPP, ... for HTTP (and perhaps some other 
> > applications)
> > skipping validation of the target name with DANE-EE(3) records 
> > introduces a "UKS"
> > (i.e. "Unknown Key Share") issue, that would definitely be a concern 
> > for "h3".
> >
> > https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00
> >
> > Thus, unless "UKS" is known to not be a concern, applications should 
> > also
> > validate the target name against the server certificate even with 
> > DANE-EE(3).
> >
> 
> This is interesting, but I think it's orthogonal.  That vulnerability
> analysis applies equally before and after this draft.

Correct, but since draft post-dates the UKS I-D, it is worth keepin the
latter in mind.  And an update to 767[123] may be warranted (based on
the "UKS" I-D).

> I'd be happy to add a reference to draft-barnes-dane-uks to the text, but
> since that draft expired several years ago, I think we would need a new or
> updated draft first.

Likely so, or it can be incorporated into a separate update document, if
that's deemed more efficient.  With DANE working group no longer around,
would "dnsop" be an appropriate home for such work?

> 2.  In 7671 CNAME chasing for the target zone is more detailed than in this
> > draft.
> 
> Yes, the intent is to incorporate that behavior by reference without
> restating it.  I've proposed an adjustment to this text for improved
> clarity: https://github.com/bemasc/svcb-dane/pull/3/files.

I'll take a look soon.

> More generally, the goal is to be able to treat each connection attempt
> with exactly the same logic, whether or not SVCB is used.  SVCB produces a
> TargetName, which (if securely resolved) can then be passed into the RFC
> 7671 machine exactly as if it were the original name.

I think that mechanism alignment makes sense, the key question is
whether this is an opportunity to reconsider some of the RFC7671
choices.  In particular, CNAME chasing may have been too much
effort for too little gain.

> 3.  Are the targets of SVCB/HTTPS records allowed to be CNAME aliases?
> 
> Yes: Section 3 of draft-ietf-dnsop-svcb-https-08 says "the TargetName MAY
> be the owner of a CNAME record".

So this is different from the situation with MX (and IIRC SRV) records,
so perhaps CNAMEs will be much more common in this context?  But if so,
one can always publish parallel CNAMEs:

example.org. IN HTTPS 0 www.example.org.
www.example.org. IN CNAME example-org.cdn.example.
_443._tcp.www.example.org. IN CNAME 
_443._tcp.example-org.cdn.example.

The downside is that some CDN customers would need to more explicitly
opt-in to DANE, it would no longer be sufficient for the TLSA records to
be present on the provider side of the CNAME chain.

> > So perhaps adding CNAME-expansion into 7672/7671 was a mistake.
> > There's an opportunity here to not repeat it if that's the case.
> 
> I can see the appeal of the CNAME-expansion behavior, but it also strikes
> me as an awkward compromise.
> 
> Diverging from RFC 7671 here seems a bit unfortunate.  I would prefer to
> Update RFC 7671 to deprecate the complex CNAME behavior, but I'm not sure
> whether that's really possible now.

For SMTP it turns out that such CNAME chain TLSA records are not
especially common, but perhaps with SVCB/HTTPS they'd prove more
useful?  This is worth a second look, I don't have a strongly held
view either way at this point.

I think it is definitely possible, and 6 years later (8 from the time
that work on 7671 started) is a reasonable time to revisit the
decisions.  The protocol is pretty much only used in SMTP, and it
would not be too difficult to deprecate CNAME chasing.  Just a few
MTAs to update (Postfix, Exim, Halon, PowerMTA, Cisco ESA, and a few
more).

> There are also some nontrivial privacy implications due to the effect
> on SNI.

Can you be more explicit about this?  Which is the better privacy
outcome, using the initial or expanded name in SNI?  The SNI name is
IIRC encrypted in TLS 1.3, so perhaps this is not a long-term issue?

> > 4.  If there are opportunistic applications in scope for this draft, they 
> > may
> > want to follow the advice of 7672 to only check for TLSA records if the
> > target zone is determined to be signed after first performing the IP 
> > (v4/v6)
> > address lookup.
> 
> This doesn't seem like a very good optimization.  For optimal latency, the
> client would issue any queries as soon as it can.

It is very much *NOT* an optimisation.  Rather it is an essential
element of robustness of the protocol in the face of the reality
of the DNS ecosystem:

- For DANE to be useful it must not be trivially subject to
  downgrade by not responding to TLSA records, returning REFUSED,
  NOTIMP, SERFVAIL or bogus 

Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

[Viktor Dukhovni]

On Sun, Dec 12, 2021 at 09:49:57AM +0100, Philip Homburg wrote:

> >> There is something I don't understand about this draft.
> >
> >The main thing to understand is that complex applications like browsers
> >allow data retrieved from one endpoint to script interaction with a
> >*different* endpoint, and possibly see the retrieved content, subject to
> >various CORS (Cross-origin resource sharing) controls.
> 
> Indeed this is subject to CORS. Nothing new here. Any browser needs to get
> this right.

Perhaps I failed to explain the issue, but that does not mean that there
is no issue.

The browser may be communicating with a victim server believing its name
to be the same as the attacker's server, and therefore allowing attacker
served scripts (from a prior connection) to script the interaction with
the victim server.  The victim server may believe it has a secure
connection with the client (based perhaps a client-certificate-signed
handshake) and may allow it retrieve sensitive data.

Cookie-based authentication does not appear to be vulnerable here, since
the browser would presumably not send victim site cookies to a site
it believes to be the attacker.

If the victim site uses https, but authenticates clients by internal IP
alone, again there could be an issue.

I don't know how to explain this better, you could ask on a cryptography
or TLS-related forum, this is DNSOP, where the expertise tends to be of
a different nature.

-- 
Viktor.

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

Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

[Viktor Dukhovni]

On Sat, Dec 11, 2021 at 12:24:13PM +0100, Philip Homburg wrote:

> > https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00
> > 
> > Thus, unless "UKS" is known to not be a concern, applications
> > should also validate the target name against the server
> > certificate even with DANE-EE(3).
> 
> There is something I don't understand about this draft.

The main thing to understand is that complex applications like browsers
allow data retrieved from one endpoint to script interaction with a
*different* endpoint, and possibly see the retrieved content, subject to
various CORS (Cross-origin resource sharing) controls.

If the client uses the same (client) certificate to identify itself to
both the attacker and victim servers, then if it believes that the
victim server is the same origin as the attacker's server, it may allow
cross-origin requests between them.

> Suppose an attacker creates attack[1-3].example.com with 3 different setups:
>
> 1) attack1.example.com has a regular PKI cert and the attacker runs a 
>reverse proxy there that relays traffic to victim.example.com

This does not achieve client cert authentication to victim server.

> 2) attack2.example.com has a self signed cert and DANE with both
>attack2.example.com and victim.example.com in the DNS names of the cert.
>Again the attacker has a reverse proxy and relays to victim.example.com

This does not achieve client cert authentication to victim server.

> 3) attack3.example.com has a DANE record that refers to the cert of
>victim.example.com. There the attacker directly relays traffic to 
>victim.example.com.

This does would achieve client cert authentication to victim server, if
the client does not perform certificate name checks.

> In my experience, a hard part of PKI certs is to make sure that every name
> that can be used to reach the cert is infact listed in the certificate.
> It would be way better if for DANE, no name checks are done at all.

For applications other than browsers, sure.  Browsers go out of their to
run code served by the remote server, and then try to make that somehow
safe.  It's a miracle they sometimes succeed.

-- 
Viktor.

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

Re: [DNSOP] New Version Notification for draft-rebs-dnsop-svcb-dane-00.txt

[Viktor Dukhovni]

> On 9 Dec 2021, at 5:32 pm, Ben Schwartz  wrote:
> 
> This is a very small draft explaining how to do DANE with SVCB, mostly 
> following the pattern of DANE-SRV.  It also updates DANE for use with QUIC.
> 
> Please review.

Initial observations:

1.  While DANE certificate validation as described in RFCs 7671,7672 and 7673
is fine in SMTP, IMAP, XMPP, ... for HTTP (and perhaps some other 
applications)
skipping validation of the target name with DANE-EE(3) records introduces a 
"UKS"
(i.e. "Unknown Key Share") issue, that would definitely be a concern for 
"h3".

https://datatracker.ietf.org/doc/html/draft-barnes-dane-uks-00

Thus, unless "UKS" is known to not be a concern, applications should also
validate the target name against the server certificate even with 
DANE-EE(3).

2.  In 7671 CNAME chasing for the target zone is more detailed than in this 
draft.

* Either every record in a chain of CNAMEs leading to an unaliased 
target
  is "secure" (DNSSEC-signed and validated), and there's an associated
  TLSA record for the end of the chain.  In which case that's used.

* Or else, the TLSA record lookup is performed at the initial unaliased
  target.

There are no "middle of chain" TLSA lookups, or TLSA lookups at the end of a
chain that is not end-to-end secure.

3.  Are the targets of SVCB/HTTPS records allowed to be CNAME aliases?  
Experience
since 7672 was written shows that TLSA records at CNAME-expanded targets are
rare, and supporting these correctly is complex.  Also the original target
owners can, if they wish explicitly redirect their TLSA records to point at
the TLSA records expected at the expanded name.

So perhaps adding CNAME-expansion into 7672/7671 was a mistake.  There's
an opportunity here to not repeat it if that's the case.  Mind you aliased
MX exchange names are a violation of RFC5321 (one that's tolerated by many
MTAs, some obliviously, because they just look up IP addresses without 
taking
steps to exclude possible CNAME expansion along the way).

4.  If there are opportunistic applications in scope for this draft, they may
want to follow the advice of 7672 to only check for TLSA records if the
target zone is determined to be signed after first performing the IP (v4/v6)
address lookup.  Here a related CNAME detail comes into scope, the target
zone may be signed, but the CNAME expanded zone with the IPs might not.

Therefore, if HTTPS/SVCB targets are allowed to be aliased, the client
would have to issue an explicit "CNAME query" in the address lookup
comes back as an "insecure" answer via CNAME/DNAME expansion.  This
assumes that the client is delegating DNSSEC-validation to a local recursive
resolver and trusting its "AD" bit.  If the client is doing its own DNSSEC
validation, its DNS library will know whether the origin of the CNAME chain
is secure or not, and this information may be available to the client 
without
a follow-up explicit type "CNAME" lookup (to suppress CNAME expansion).

-- 
Viktor.

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

Re: [DNSOP] How Slack didn't turn on DNSSEC

[Viktor Dukhovni]

> On 1 Dec 2021, at 4:19 pm, Paul Vixie  wrote:
> 
> ... but if you're Slack or similar (cloud provider, ISP, MSSP, social network,
> xAAS provider), no automation will ever be good enough by itself (wizards will
> be needed.)

With that qualification, I think we're much less far apart.  Yes,
the operations team in a complex environment needs to be more
highly skilled, and not just in DNSSEC.

However, I do think that the skill level required need not always
be or remain "wizard".  They had some bad luck running into a not
fully baked stack on the provider end.

Unless of course the complexity of what's being attempted will
always rise to near or just past the skill level of the team,
boldly going to where no team has gone before.

In that case, even wizards will at times out-wizard themselves,
and this is then no longer about DNSSEC really.  Just that as
tools get better we're never content to keep solving the old
problems more reliably, we start to feel cocky about tackling
new bigger problems...

-- 
-- 
Viktor.

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

Re: [DNSOP] How Slack didn't turn on DNSSEC

[Viktor Dukhovni]

> On 1 Dec 2021, at 2:37 pm, Jim Reid  wrote:
> 
>> Wouldn't that create a vicious circle in which the only way to start 
>> operating DNSSEC is already to have operated DNSSEC?
> 
> I think we’ve been in that vicious circle (or downward spiral) for several 
> years now.

The graph at: https://stats.dnssec-tools.org/images/totalds.svg
does not look like a downward spiral to me.

But I also don't agree with Paul that one needs to be an expert to play
the game.  Tools are improving, and spinning up working DNSSEC with Knot,
BIND 9.16+, ... is increasingly easier.

Where things get more complex is in API integration with cloud providers,
bugs in the provider implementation that's recent and not fully baked, ...

These too will likely improved, but there will occasionally be issues when
some new managed service is introduced and users struggle to consume it,
and have complex unanticipated requirements.

-- 
Viktor.

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

Re: [DNSOP] How Slack didn't turn on DNSSEC

[Viktor Dukhovni]

> On 30 Nov 2021, at 1:38 pm, John Levine  wrote:
> 
> Can or should we offer advice on how to do this better, sort of like
> RFC 8901 but one level of DNS expertise down?

The main advice that comes to mind is to use a DNS hosting provider
with a proven (multi-year) record of doing DNSSEC reliably.

If the DNS hosting provider where Cloudflare, Google, OVH, one.com,
TransIP, ... the implementation would have been correct.

Clearly Route 53 wasn't quite ready for prime time.  It is not clear
how we can help customers know which providers have solid implementations.
I don't know of any mainstream certification programs that would do the
job.

-- 
Viktor.

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

Re: [DNSOP] nsec3-parameters opinions gathered

[Viktor Dukhovni]

> On 29 Nov 2021, at 7:55 am, Michael Bauland  wrote:
> 
>> The iteration count distribution for the TLDs is presently:
>>  # TLDs NSEC3 iterations
>>  -- 
>> 147 0
>> 458 1
>>   1 2
>>  14 3
>> 112 5
>>   4 8
>> 545 10
>>  29 12
>>   1 13
>>   1 15
>>   1 17
>>   6 20
>>   2 25
>> The outliers above 10 are:
>> ccTLDs: bn de dk pl sg ua xn--clchc0ea0b2g2a9gcd xn--yfro4i67o
>> gTLDs: alstom barcelona bauhaus bcn cat erni eurovision eus firmdale gal 
>> gdn
>>gmx ifm lacaixa madrid man mango nrw quebec radio ruhr sap scot 
>> seat
>>sport swiss whoswho xn--55qw42g xn--80asehdb xn--80aswg 
>> xn--mgbab2bd
>>xn--zfr164b
> 
> We see your argument and have now adjusted our configurations accordingly. 
> All TLDs run by CORE Association and Knipp (i.e., almost all from the gTLDs 
> list above) have now reduced their NSEC3 iteration count to 0.

Nice!  Thanks.  Indeed I see now only 12 TLDs with more than 10 iterations:

  ccTLDs: bn de dk pl sg ua xn--clchc0ea0b2g2a9gcd xn--yfro4i67o
  gTLDs:  firmdale gdn xn--55qw42g xn--zfr164b

The new distribution is:

175 0
396 1
  1 2
 14 3
113 5
  3 8
607 10
  1 12
  1 13
  1 15
  1 17
  6 20
  2 25

Which seems to also suggest that 62 TLDs got moved from 1 to 10. :-(
Perhaps a change of platform...  Having whoever manages the 607 to
switch to 0 would be a good next milestone...

-- 
Viktor.

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

Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

[Viktor Dukhovni]

On Fri, Nov 26, 2021 at 12:32:19PM +0100, Petr Špaček wrote:

> Also, when we are theorizing, we can also consider that resalting 
> thwarts simple correlation: After a resalt attacker cannot tell if a set 
> of names has changed or not. With a constant salt attacker can detect 
> new and removed names by their hash. (I'm not sure it is useful 
> information without cracking the hashes.)

Actually, no.  If one has previously been mostly successful at cracking
extant names in a zone, rehashing of a small set (much smaller than the
full dictionary one use) of known names is rather quick.  So old names
can be quickly identified even after a salt change.  Leaving just the
hashes of new names.

Mind you, for cracking the new names, one would still rehash the entire
dictionary when the salt changes, the number of new names to check is
not a scaling factor in the cost.  Just a table join.

So periodic resalting does raise the cost of ongoing tracking of a
zone's content, if that's the sort of thing one cares enough about.
Rarely worth it, but mostly harmless if the salt is not too long and
rotated say on each ZSK rollover.

-- 
Viktor.

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

Re: [DNSOP] nsec3-parameters opinions gathered

[Viktor Dukhovni]

> On 9 Nov 2021, at 4:11 am, Petr Špaček  wrote:
> 
> I don't see need to specify _a_ value here. I think better approach is 
> acknowledge current state of things. What about something like this?
> 
> ---
> As for November 2021, the limit of 150 iterations for treating answer as 
> insecure is interoperable without significant problems, but at the same time 
> it makes DoS attacks based on exhausting CPU resources three times cheaper 
> when compared to 0 iterations.
> 
> For this reason software vendors are expected to evaluate NSEC3 iteration 
> counts seen in wild and lower their limits over time.
> ---
> 
> What do you think about this approach?

I have no objections to setting the limits to essentially zero, but would 
suggest:

  - Authoritative servers employing NSEC3 SHOULD set the (additional)
iteration count to 0.  Higher values may run into interoperability
problems with validating resolvers and secondary servers.

  - Validating resolvers MAY over time reduce the maximum NSEC3
(additional) iteration count they support to as low as 1.
NSEC3 iteration counts of 0 and 1 MUST continue to be supported.

The reason I'd prefer that validators allow 1 as well as zero, is that:

* We're then probably looking at just ~1% performance impact
  (extrapolated from the posted perf numbers)

* It is I think not obvious to naive operators that 0 iterations really
  means 0 *additional* iterations, and the initial hashing step is still
  performed.  Thus 1 is a fairly popular setting, and I'm inclined to
  require that it be tolerated in validators, even if we're telling
  auth zone operators to use 0.

All that said, after the RFC is done, we'll need to do another round
of outreach to TLD zone aand customer domain hosting operators as well
as independent self-hosting auth zone operators, this time to ask for
a reduction to 0 (as opposed to 100 or less).  I hope that won't be
principally (or alone) up to me.

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

Re: [DNSOP] nsec3-parameters opinions gathered

[Viktor Dukhovni]

> On 8 Nov 2021, at 12:55 pm, A. Schulze  wrote:
> 
> sorry for maybe asking an already answered question,
> but why is NSEC3 considered to have no benefit at all?

My take is that NSEC3 provides little benefit beyond the initial
(0th) iteration.

> I'm still on "NSEC allow zone-walks while NSEC3 don't"
> At least not without additional effort.

But, of course that initial iteration provides only limited protection
against zone walking, it deters *casual* attacks, by those who are not
sufficiently motivated to expend CPU on dictionary attacks (that would
likely recover a decent fraction of the names for most zones).

There are a few possible paths forward:

* Accept that sufficiently determined adversaries will mount a dictionary
  attack, but there won't be many of them.  Make do with NSEC3 and zero
  iterations.

* Accept that your zone data is not secret, publish vanilla NSEC records
  and let the zone walkers go at it.  For some TLDs, spin up a public
  AXFR service, or make zone data available via HTTPS, call it "Open Data".

* Use NSEC in combination with online signing (with ECDSA P256(13)), using
  minimal covering NSEC RRS.  These *actually* preclude offline dictionary
  attacks at the cost of online signing of negative answers.  If not leaking
  zone data is important enough, this is the actually secure way to get there.

NSEC3 is neither fish nor fowl.  Regardless of any practically realistic
iteration count, it is still vulnerable to dictionary attacks.  Its main
tangible benefit (at some non-trivial security cost) is opt-out, which is
increasingly a bad idea for most zones.

Thus we find .COM and others using "NSEC3 1 1 0 -" (just opt-out).  But
most zones, if they use NSEC3 at all, should have "NSEC3 1 0 0 -", or
just NSEC, possibly with minimal covering replies via online signing.

-- 
Viktor.

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

Re: [DNSOP] nsec3-parameters opinions gathered

[Viktor Dukhovni]

> On 8 Nov 2021, at 6:07 am, Petr Špaček  wrote:
> 
> TL;DR
> I say we should go for 0 and acknowledge in the text we are not there yet.

This means reaching out to the TLD operators again...  They were quite
cooperative ~6 months back, but I wouldn't want to take them for granted
and keep asking for multiple further rounds of changes.  So whatever target
ends up in the final document should be something they'd be willing to adopt
as a final "issue closed" update.

The iteration count distribution for the TLDs is presently:

 # TLDs NSEC3 iterations
 -- 
147 0
458 1
  1 2
 14 3
112 5
  4 8
545 10
 29 12
  1 13
  1 15
  1 17
  6 20
  2 25

The outliers above 10 are:

ccTLDs: bn de dk pl sg ua xn--clchc0ea0b2g2a9gcd xn--yfro4i67o

gTLDs: alstom barcelona bauhaus bcn cat erni eurovision eus firmdale gal gdn
   gmx ifm lacaixa madrid man mango nrw quebec radio ruhr sap scot seat
   sport swiss whoswho xn--55qw42g xn--80asehdb xn--80aswg xn--mgbab2bd
   xn--zfr164b

The largest by count of signed delegations are .PL (12 iterations), .DK (17) and
.DE (15).

The bulge at 10 iterations has the following top 21 SOA rnames:

186 hostmaster@donuts.email.
176 n...@afilias-nst.info.
 87 hostmas...@nominet.org.uk.
 11 hostmas...@coccaregistry.org.
  6 hostmas...@registro.br.
  5 gtldsupp...@aeda.ae.
  4 sys...@cnnic.cn.
  4 supp...@ryce-rsp.com.
  4 supp...@registry.net.za.
  4 s...@twnic.net.tw.
  3 r...@cnnic.cn.
  3 regis...@thains.co.th.
  3 hostmas...@lemarit.com.
  2 regis...@nic.mr.
  2 i...@yesnic.com.
  2 hostmas...@hkirc.net.hk.
  2 hmaster-i...@ics.forth.gr.
  2 domain-mana...@nic.or.kr.
  2 dnsmas...@channelisles.net.
  2 d...@amnic.net.
  2 dns-t...@flexireg.net.

The rest are 33 "singleton" rnames present in just 1 TLD each:

  ad ar bg cr gl gw gy hn hr it kw lat lv ly ma mc md mil mx nc
  nf pe pt ro sb tt ug uy uz ws xn--mgbai9azgqp6j xn--wgbh1c za

-- 
Viktor.

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

Re: [DNSOP] nsec3-parameters opinions gathered

[Viktor Dukhovni]

> On 5 Nov 2021, at 3:19 pm, Olafur Gudmundsson  wrote:
> 
> Publishing iteration count higher than 10 is reckless as that affects the 
> performance of recursive resolvers in particular the ones that run on small 
> CPE equipment.
> 
> The document should strongly discourage any use of NSEC3  
> For the  that want to keep using it the limit should be real low of 
> what resolvers accept. 
> Any value between 0 and 10 is fine with me 

I hope to see some hint of consensus at the meeting, but would
like to mention, that a realistic *aggressive* target would 20
rather than 10.  There are >0.5M zones with 20 iterations, and
it is likely too much work for insufficient gain to get them to
reduce this to 10 or less.

If the WG consensus it to go *aggressive*, then the limit should
I suggest be 20.  Other plausible values that non-trivially reduce
impact are 40, 50 and 100.

The multiple-choice question for the recommended resolver limits
(highest accepted, not lowest rejected) is then:

A. 20
B. 40
C. 50
D. 100
E. 150

And as for SERVFAIL, note that wildcard responses are often NSEC3
authenticated, so they'd stop working in zones over the SERVFAIL
limit.  Therefore, I think the choices here are more limited, unless
we're planning to hold off resolver implementation until many more
zones make changes post publication of the RFC.  In the short run,
the realistic upper bounds before SERVFAIL are:

A. 150  (More stringent current de facto limit)
B. 500  (Raytheon special)
C. Never(Carrot sans stick)

If some zones don't care that they're now insecure, we can report
their DoE and wildcards as insecure, and hope they'll eventually
care.

Meanwhile, their positive answers still validate, but can be freely
replaced with an insecure NODATA (zone apex) or any insecure answer
(positive, NODATA or NXDOMAIN) at any qname properly below the zone
apex.

-- 
Viktor.

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

Re: [DNSOP] draft-ietf-dnsop-nsec3-guidance: fresh iteration count stats

[Viktor Dukhovni]

If there's appetite to go even lower than 50, the relevant counts are:

   8898 21
  6 22
 19 23
 87 24
 13 25
  1 27
  1 29
 14 30
  4 31
 39 32
   1112 33
 33 35
  1 39
  43384 40
 35 42
  12281 50

Since the zone count for 20 in mid October was 531,146, that seems to be
the lowest realistic limit we can impose, if we're willing to apply enough
pressure to also get the ~66k zones between 21 and 50 to make changes.

> On 4 Nov 2021, at 4:46 pm, Viktor Dukhovni  wrote:
> 
> Just in case further reductions occurred since mid-October, I did a quick
> rescan of zones which had >= 51 iterations, and the absolute frequencies
> are below.  Still mostly negligible, except for 100, 150, and a small
> Raytheon bump at 500.  So the question boils down to whether we want to
> nudge the 150s and perhaps also the 100s down to either 100 or 50, setting
> the recommended resolver limit there (and of course still strongly recommend
> the auth zone signers to use 0).
> 
>  1 51
> 19 52
>  1 53
>  1 54
>  1 55
>  2 56
>  1 60
>  1 61
> 12 64
>  1 67
>  2 69
> 75 75
>  1 80
>  8 81
>  5 84
> 33 85
> 20 90
>  1 96
> 11 99
>  20038 100

-- 
Viktor.

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

Re: [DNSOP] draft-ietf-dnsop-nsec3-guidance: fresh iteration count stats

[Viktor Dukhovni]

> On 18 Oct 2021, at 12:43 am, Viktor Dukhovni  wrote:
> 
> We were waiting for TransIP to complete the migration of their managed
> DNS domains from 100 iterations to 0, before collecting fresh NSEC3
> iteration count deployment statistics.
> 
> That has now been done, and the results are below:
> 
>  Zones successfully probed: 16,302,535
>  Zones using NSEC3: 12,460,057   76.4% (of signed zones)
>  Zones using opt-out:1,162,8699.3% (of NSEC3 zones)
> 
> Percentile cumulative distribution:
> 
>iterationscumulative%
> 0  7.934956%
> 5 71.117973%
>10 92.455026%
>15 94.808563%
>20 99.183358%
>25 99.256617%
>30 99.256745%
>35 99.266753%
>40 99.676831%
>50 99.783324%
>55 99.783508%
>60 99.783532%
>75 99.784263%
>80 99.784295%
>85 99.784664%
>90 99.784913%
>99 99.785017%
>   100 99.946999%
>   120 99.947151%
>   150 99.998403%
>   160 99.998411%
>   200 99.998571%
>   250 99.998628%
>   300 99.998652%
>   330 99.998756%
>   400 99.998828%
>   500 99.999655%
>  1600 99.60%
>  2000 99.76%
>  2500100.00%

Just in case further reductions occurred since mid-October, I did a quick
rescan of zones which had >= 51 iterations, and the absolute frequencies
are below.  Still mostly negligible, except for 100, 150, and a small
Raytheon bump at 500.  So the question boils down to whether we want to
nudge the 150s and perhaps also the 100s down to either 100 or 50, setting
the recommended resolver limit there (and of course still strongly recommend
the auth zone signers to use 0).

  1 51
 19 52
  1 53
  1 54
  1 55
  2 56
  1 60
  1 61
 12 64
  1 67
  2 69
 75 75
  1 80
  8 81
  5 84
 33 85
 20 90
  1 96
 11 99
  20038 100
  1 101
 17 107
  1 120
  6 128
  1 132
  1 139
 27 149
   6304 150
  1 160
 17 177
  3 200
  1 234
  6 250
  1 256
  2 300
 13 330
  8 400
  1 423
  1 487
101 500
  2 1024
  1 1337
 35 1600
  2 2000
  3 2500

-- 
Viktor.

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

Re: [DNSOP] How does NSEC record(s) prove the Name Error?

[Viktor Dukhovni]

On Wed, Oct 27, 2021 at 04:09:01PM -0700, Joey Deng wrote:

> Thanks for the detailed response. I think the 'closest encloser’ proof
> is what I am missing here. It is weird that none of the DNSSEC RFCs
> talk about the closest encloser of NSEC (or maybe I am not aware about
> it).

Perhaps it was supposed to be "more obvious", given that none of the
names are hashed.

> > The closest encloser is then the longest domain equal to or
> > containing both endpoints of the NSEC pair.
> 
> There are two names in the NSEC record:
> 1. Current owner name
> 2. Next owner name
> 
> By saying “longest domain equal to or containing”, do you mean:
> The longest common name of the current owner name and the next owner name.

I forgot to consider that one or the other end the pair may prove
existence of an ancestor of the qname that lies below their *common*
ancestor.  This is then instead the closest encloser.  I was thinking
of a tree that looked like the below, with "L" the left end of the
NSEC pair, "R" the right end, "Q" the qname and "C" the closest
encloser:

C
   /|\
  / | *
 *  |  \
/   *   \
   /|R
  L |
Q

but instead we can have either of:

   xx
  / \  / \
 /   */   C
C \  *   / \
   / \ \/   /   \
  /   * R  /   * R
 L \  L   / 
QQ


> ;subdomain.data.wildcard.dnssec.qdeng.io. IN MX
> 
> ;; AUTHORITY SECTION:
> qdeng.io. 3601IN  SOA pdns1.registrar-servers.com. 
> hostmaster.registrar-servers.com. 1635297699 43200 3600 604800 3601
> *.wildcard.dnssec.qdeng.io. 3601 IN   NSECa.wildcard.dnssec.qdeng.io. 
>  RRSIG NSEC
> a.wildcard.dnssec.qdeng.io. 3601 IN   NSECdnssed.qdeng.io.  RRSIG NSEC

Here we see that "wildcard.dnssec.qdeng.io" exists, because its "a"
subdomain exists, so this is the closest encloser.  Sorry for the
error in my previous post.

-- 
Viktor.

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

Re: [DNSOP] How does NSEC record(s) prove the Name Error?

[Viktor Dukhovni]

On Tue, Oct 26, 2021 at 10:21:29PM -0700, Joey Deng wrote:

> If the question name appears in-between the current owner name and the
> next owner name of the NSEC record, which means that there is no exact
> name matching: We should prove that no possible wildcard RRset exists
> that could have been used to generate a positive response.

This is accomplished via a 'closest encloser' proof, in the case of NSEC
this takes up to two records:

1. An NSEC record that excludes the shortest non-existent ancestor
   of the qname.  The closest encloser is then the longest domain
   equal to or containing both endpoints of the NSEC pair.

2. An NSEC record showing non-existence of a wildcard below that
   closest encloser (which may be the same as (1) in some cases.

> What are possible wildcard RRsets for a given name?

The label count of the wildcard response must then match the number of
labels in the closest encloser.  That is, the "*" domain would have to
have been an immediate child of the closest encloser (1).

> My understanding about possible wildcard RRsets for a given name are
> all the possible sources of synthesis.  For example, the possible
> wildcard RRsets that can be used to answer question .ietf.org
>  are:
>
> *.ietf.org

That would be the only one, because 'ietf.org' is known to exist.
[ There's presently no "*.ietf.org" wildcard domain. ]

> *.org

No, this lies above the closest encloser.

> * (but I think root can never be a wildcard, so this is impossible)

No, this lies above the closest encloser.  A "*" node in the root zone
is technically possible, but none is likely to ever be published.  If it
were to exist it would become the source of truth for all invalid and
typoed TLDs, which would be rather suboptimal.

> Is my understanding correct?

No.

> For example, if I send a DNS query for .ietf.org with DO/CD bit
> set, there will be two NSEC records returned:
> 
> ```
> $ dig ".ietf.org"  +dnssec +cdflag +tcp @1.1.1.1
> 
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34013
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

This is an NXDOMAIN answer, not a NODATA or wildcard sythesised answer.

> wwwtest.ietf.org. 1800IN  NSECxml2rfc.ietf.org. CNAME RRSIG 
> NSEC

This record proves the non-existence of the qname, and also "ietf.org"
as the closest encloser.

> ietf.org. 1800IN  NSEC_dmarc.ietf.org. A NS SOA MX 
> TXT  RRSIG NSEC DNSKEY SPF

This record proves that "*.ietf.org" does not exist, and we're done.

> wwwtest.ietf.org. -> xml2rfc.ietf.org. tells us that the exact name
> match for .ietf.org does not exist, since it appears in-between
> the two names.

Correct.

> Therefore, the remaining ietf.org. -> _dmarc.ietf.org. NSEC should be
> used to prove that “no possible wildcard RRset exists that could have
> been used to generate a positive response” for the name .ietf.org.

Which it does, since the only potential wildcard is '*.ietf.org', given
"ietf.org" as the closest encloser. "*.ietf.org" would be between these
if it existed.

> How can ietf.org. -> _dmarc.ietf.org NSEC be used to prove that there
> is no wildcard record for the name .ietf.org?

By virtue of the fact that wildcards never apply at or below sibling
names that exist.  If foo.example.com exists, then wildcards at
"*.example.com", "*.com", or "*" can never apply to any query at or
below "foo.bar.example.com".  The "*.example.com" wildcard can only
apply to names ending in a non-existent sibling of the wildcard
label (.example.com).

> Do we need to prove that all the possible sources of synthesis for
> .ietf.org appear in-between ietf.org. and _dmarc.ietf.org?

There is only ever one such possible source.  The "*" label under
the closest encloser.

> Or do we only need to prove that *.ietf.org appears in-between
> ietf.org. and _dmarc.ietf.org?

Since there's only one possible source, this is the one to
disprove.

> If so why do we choose *.ietf.org instead of *.org or *?

See above.

-- 
VIktor.

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

Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance

[Viktor Dukhovni]

> On 22 Oct 2021, at 4:48 am, Vladimír Čunát  wrote:
> 
> Example micro-benchmark doing just the NSEC3 hashing shows that even quite 
> long 32B salt has little effect but 255B adds a noticeable multiplicative 
> factor.  Therefore I'd suggest that NSEC3 records with salt > 32B may be 
> ignored or something similar; I don't expect they really exist in practice 
> and we still shave some factor from attacks.  That's all assuming we can't 
> afford pushing the validator limits very close to zero iterations.

The observed salt lengths from my NSEC3 scan were, so there's a large cluster
of ~291k zones with 40 byte salts.  It looks like the recent burst of signing
by hostpoint.ch used that salt length.  We could suggest they reconsider that
choice.

The small cluster of 125 zones with 64 byte salts looks dominated by
(but not exclusive to) kilobajt.sk.

The 3 outliers at 255 were: matejgroma.com, saren.sa and saren.org.sa.

0 167477
1 2010575
2 237576
3 15971
4 965075
5 1164236
6 11130
7 1224
8 7465501
9 909
10 1821
11 928
12 17848
13 884
14 982
15 158
16 87950
17 25
18 59
19 136
20 7221
21 216
22 193
23 220
24 9192
25 125
26 123
27 96
28 51
29 44
30 38
31 33
32 584
33 11
34 10
35 5
36 3
37 1
39 1
40 291294
44 1
64 125
120 1
128 1
255 3

-- 
Viktor.

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

Re: [DNSOP] wrapping up draft-ietf-dnsop-nsec3-guidance

[Viktor Dukhovni]

On Wed, Oct 20, 2021 at 11:24:47AM -0700, Wes Hardaker wrote:

> But, as Viktor indicated in his posts, we could move even lower (100
> being the next obvious step, but even lower is possible to still retain
> a reasonable percentage).  But there is of course a risk of we'll never
> get to a definitive value, and may operators by constantly lowering it
> and they have to keep changing values.
> 
> So, the question: what's the right FINAL value to put in the draft
> before LC?

Some observations to help the decision process:

   1. A validating resolver that prefers to SERVFAIL on all responses
  with excessive iterations, avoiding downgrades to "insecure",
  can simply ignore such NSEC3 records, and if no appropriate NSEC
  or NSEC3 records remain can then treat the reply as bogus.

   2. The downside of insecure downgrade is that any affected zones are
  subject to forgery of all names strictly below the zone apex, via
  fake insecure delegations (the denial of existence of DS records
  will be accepted), and also NODATA forgery for all qtypes at the
  zone apex (except NSEC3 and RRSIG).

   3. The downside of SERVFAIL for excess iterations is that if the
  target zone handles names of SMTP hosts without DANE TLSA records,
  then TLSA denial of existence failure with render these mail
  servers unavailable to DANE-enabled SMTP clients.

  Also any wildcard replies that are based of non-existence proofs
  of the qname, ... will be bogus, thus e.g. wildcard A/ answers
  are likely to SERVFAIL.

   4. The cost of P256 signature verification is (on a now somewhat dated
  Xeon Skylake system) ~300 times that of a SHA1 hash.  Thus south
  of 150 iterations, further reductions in the iteration count offer
  only a modest benefit to validating resolvers that are also
  validating the signature.

   5. However, no signature verification applies on the authoritative
  server (perhaps a secondary that did not specifically "volunteer"
  to serve zones with a high iteration count).

  Also when doing aggressive negative caching via previously
  received NSEC3 records, once again only SHA1 hashing is involve,
  the signature verification happened when the records were cached.

Therefore, while a softfail to insecure makes it possible to avoid
immediate pain, the SERVFAIL alternative is simpler to implement
correctly, but may require setting the bar somewhat higher.

Ideally, all zone operators would get the message, apply a realistic
threat model, and set the iteration counts to 0.

Much progress has been made in a comparatively short time, but pockets
of "resistance" remain, with a large majority of domains in the [1-20]
range, and low but perhaps non-negligible zone counts (out of 12.46M
zones) for:

50 iterations: ~13k
100 iterations: ~20k (7.9k netcup.de, 2.2k nlhosting.net, 2.1k 
core-networks.de)
150 iterations: ~6k  (5.8k mijnhostingpartner.nl)
500 iterations: 101  (85 raytheon.com)

With a bit more nagging we could probably convince the small number of
operators that dominate the counts in question to make adjustments.

Otherwise, we can declare victory at either 100 or 150, and recommend
SERVFAIL above 500, but MAY SERVFAIL at the lower cutoff.

I'd like to see more responses with specific numbers, and thoughts on
whether a range in which downgrade to insecure happens is a good or
bad idea.

That is, is it always either AD=1 or SERVFAIL, or is there merit in
AD=0 for a range of values above a soft cutoff before a higher hard
cutoff is reached.

At this point, my inclination is to hardfail at 150 and avoid softfail.
Raytheon may be briefly incovenienced, but otherwise this feels the most
robust option, unless rough consensus is to try to set the bar lower and
softfail from there to some suitable upper bound in the 150 to 500
range.

On Thu, Oct 21, 2021 at 01:22:25PM +0200, Peter van Dijk wrote:

> I don't know what the -right- value is, but I know what I want: 0
> iterations, empty salt, otherwise the NSEC3 gets ignored, presumably
> leading to SERVFAIL. This removes the 'insecure' window completely.
> 
> So, I'll support any push to lower the numbers.

Please be specific, even if you feel you'll land in the rough.

> Editorial nit, already hinted at above: the text currently has
> "Validating resolvers MAY return SERVFAIL when processing NSEC3
> records with iterations larger than 500." - I suggest changing this to
> "validating resolvers MAY ignore NSEC3 records with iterations larger
> than 500". That way, zones in the middle of a transition from 1000 to
> 0 iterations do not get punished. Zones at 1000, not in a transition,
> will still get SERVFAIL by virtue of the NSEC3 proof missing (because
> it is ignored).

Thanks, I think I agree. Ignore records with counts that would SERVFAIL
if best-available, sounds sensible.

On Thu, Oct 21, 2021 at 02:52:47PM +0200, Matthijs Mekking wrote:

> And I 

Re: [DNSOP] draft-ietf-dnsop-nsec3-guidance: fresh iteration count stats

[Viktor Dukhovni]

On Mon, Oct 18, 2021 at 12:43:51AM -0400, Viktor Dukhovni wrote:

> On Fri, Oct 15, 2021 at 04:30:37PM -0700, internet-dra...@ietf.org wrote:
> 
> > Filename: draft-ietf-dnsop-nsec3-guidance-01.txt
> > 
> > Abstract:
> >NSEC3 is a DNSSEC mechanism providing proof of non-existence by
> >promising there are no names that exist between two domainnames
> >within a zone.  Unlike its counterpart NSEC, NSEC3 avoids directly
> >disclosing the bounding domainname pairs.  This document provides
> >guidance on setting NSEC3 parameters based on recent operational
> >deployment experience.
> 
> We were waiting for TransIP to complete the migration of their managed
> DNS domains from 100 iterations to 0, before collecting fresh NSEC3
> iteration count deployment statistics.
> 
> That has now been done, and the results are below:
> 
>   Zones successfully probed: 16,302,535
>   Zones using NSEC3: 12,460,057   76.4% (of signed zones)
>   Zones using opt-out:1,162,8699.3% (of NSEC3 zones)

Based on the stats it looks plausibly realistic to set the bar as low as
50 iterations, if there's a desire to urge the community to make a final
round of downward adjustments.  Or, else we could declare victory, the
recent encouragement to use 150 or less shows very good "compliance".
A middle ground might be to set the bar at 100.

The number of zones in the 21 to 50 range is 74,756 and there are
531,146 zones at 20.  So a maximally aggressive goal could be 20
or less, but would take more time and effort.

Bikeshed away!

There's a fairly small number of operators to persuade to reduce
iterations to 50 or less.  A comparatively small number of operators
revising their settings to 50 or less would reduce an already rather low
rate of domains with 51 or more iterations to essentially insignificant
levels:


  #zones  #iters SOA mname
  
7979 100 root-dns.netcup.net
2289 100 ns.nlhosting.net
2162 100 ns1.core-networks.de
1790 100 ns0-auth.businessconnect.nl
 748 100 ns0.transip.net
 689 100 ns1.nextpertise.nl
 575 100 ns1.acmeweb.nl
 459 100 nsa.perf1.fr
 449 100 a.dns-i.net
 434 100 ns10.kibernet.hu
 406 100 ns1.absolight.net
 256 100 ns1.isaac.nl
 202 100 ns1.codeforce.nl
 181 100 ns1.worldstream.nl
 124 100 ns1.metaname.net
  99 100 ns1.vshosting.cz
  
   18842 100 out of 20,183 in all

  #zones  #iters SOA mname
  
5810 150 ns1.mijnhostingpartner.nl
 234 150 ns1.inmoves.nl
 102 150 ns1-eu.123ns.eu
  
6146 150 out of 6351

  #zones  #iters SOA mname
  
  85 500 dfw-infma1.ext.ray.com
  
  85 500 out of 101

-- 
Viktor.

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

[DNSOP] draft-ietf-dnsop-nsec3-guidance: fresh iteration count stats

[Viktor Dukhovni]

On Fri, Oct 15, 2021 at 04:30:37PM -0700, internet-dra...@ietf.org wrote:

>   Filename: draft-ietf-dnsop-nsec3-guidance-01.txt
> 
> Abstract:
>NSEC3 is a DNSSEC mechanism providing proof of non-existence by
>promising there are no names that exist between two domainnames
>within a zone.  Unlike its counterpart NSEC, NSEC3 avoids directly
>disclosing the bounding domainname pairs.  This document provides
>guidance on setting NSEC3 parameters based on recent operational
>deployment experience.

We were waiting for TransIP to complete the migration of their managed
DNS domains from 100 iterations to 0, before collecting fresh NSEC3
iteration count deployment statistics.

That has now been done, and the results are below:

  Zones successfully probed: 16,302,535
  Zones using NSEC3: 12,460,057   76.4% (of signed zones)
  Zones using opt-out:1,162,8699.3% (of NSEC3 zones)

Percentile cumulative distribution:

iterationscumulative%
 0  7.934956%
 5 71.117973%
10 92.455026%
15 94.808563%
20 99.183358%
25 99.256617%
30 99.256745%
35 99.266753%
40 99.676831%
50 99.783324%
55 99.783508%
60 99.783532%
75 99.784263%
80 99.784295%
85 99.784664%
90 99.784913%
99 99.785017%
   100 99.946999%
   120 99.947151%
   150 99.998403%
   160 99.998411%
   200 99.998571%
   250 99.998628%
   300 99.998652%
   330 99.998756%
   400 99.998828%
   500 99.999655%
  1600 99.60%
  2000 99.76%
  2500100.00%

Absolute zone number per iteration count:

iterationszone count
 0 988700
 1 640
 2 3875
 3 31803
 4 188
 5 1381224
 6 95
 7 30601
 8 1461259
 9 80
10 1166574
11 123
12 288651
13 81
14 8
15 4389
16 13934
17 8
18 9
19 5
20 531146
21 9002
22 6
23 19
24 88
25 13
27 1
29 1
30 14
31 4
32 79
33 1131
35 33
40 51096
42 35
50 13234
51 1
52 19
53 1
54 1
55 1
56 2
60 1
64 13
67 1
69 2
75 75
77 2
80 2
81 8
84 5
85 33
90 31
93 1
96 1
99 11
   100 20183
   101 1
   107 17
   120 1
   128 6
   132 1
   139 1
   149 27
   150 6351
   160 1
   177 17
   200 3
   234 1
   250 6
   256 1
   300 2
   330 13
   333 1
   400 8
   423 1
   487 1
   500 101
  1024 2
  1337 1
  1600 35
  2000 2
  2500 3

-- 
Viktor.

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

Re: [DNSOP] Question on interpretation of DO and CD

[Viktor Dukhovni]

On Sat, Oct 09, 2021 at 07:18:58AM +1100, Mark Andrews wrote:

> Yes it will be unfiltered but the point of DNSSEC is to filter out bad
> answers (that is what the ignore bogus responses achieves) and if you
> are behind a recursive server you need it to do the filtering of the
> answers it gets as you aren’t in a position to wait for the good
> answer as they won’t come to you nor are you in the position to ask
> the authoritatives directly.  It can wait for good answers by just
> rejecting the spoofed answers and continuing to listen for the real
> answer. 

IIRC the forwarder may have a (logically) separate cache with bogus
answers, which it would normally censor by returning SERVFAIL, but will
disgorge when the "CD" bit is set.  Or absent such a cache, it may ask
again, and upon receiving fresh answers that fail validation,
nevertheless forward these on.

Either way, when the stub resolver has trust anchors not known to the
forwarder, that render the response valid, the "CD" bit could help mask
the difference.

For example, though the domain cirroscope.com has no DNSKEYs matching
its DS RRs:

https://dnsviz.net/d/cirroscope.com/YWXRbg/dnssec/

setting the CD bit will make its DNSKEY RRset visible even via a
validating forwarder, and if the stub happens to have a trust-anchor
set for either the algorithm 8 or algorithm 5 KSK, then the stub
may well be able to validate the zone, the signatures are all valid,
we just don't have a SEP from .com to cirroscope.com:

cirroscope.com. 20468 IN DNSKEY 257 3 5 (
AwEAAarIbZcs5FXsMySPAeIo51z7EB7CX61KTRFSqCpo
ciNlU7OJsX2BSz1UeBIqJnuIn+GNAsf1yTE3i5cKujzg
SUWOQF8PKjTQ24nYguWXYaSykzGFK8Bp/6Bm+TGVYMmh
8Ab8j3hwRZuaBb3JuPQJvEaWnJgdYgxfYoxaOci8hG5U
lYJH8GiFhnQLZISmemIk/S5qizYyPAG+dbnTpZvmGsB+
0uCrlVMsFcN2YQVCezeOTKmMmjYrW+rzVhv9NFeRHD9+
c6D1a7aZO6qj3H7MkhOQCU44x9c446pCUN8w9Gamlrij
Xlt7PH8OzgBdBB6d+ZaIVCZpAl16GmZHX/M1t50=
) ; KSK; alg = RSASHA1 ; key id = 44602
cirroscope.com. 20468 IN DNSKEY 257 3 8 (
AwEAAaLcgz5gnyxbosRvZnyyCFVk5crNSOfOWvbHrVLX
+pMaQYoWhPJzk6Vj2TCOUhZaCZKikQ19lk95o3TMI9xH
CV8AH7KJwC6U2Lg4gcUtbRXN6zc322eJ99xqUElMAO+2
0TQETz0Qngxla9gK/Oxpp+VsUSl83uWgmOcEqU/jLRON
c4HyfoH5lx7b9QKGYxoZvzYu7IFT1ET6/81nIsK48w38
mnnFjRCyJEqy7Wtq27rwx47BHCVr0LDe61dTB9HUY94v
5NSpGgN+W2s9cazTjPCupkNg4U9GUHGxDeT2lM0+O9zH
6oY0WvnXonbZQFp+6mxkVZt3i1TZ2yjVnEDgYus=
) ; KSK; alg = RSASHA256 ; key id = 37636
cirroscope.com. 20468 IN DNSKEY 256 3 5 (
AwEAAbNDmSwB7ns19bqqXtttgrgexDCuJngapNpV8Akk
M3+YCR9saIvC4RXEteDLV10RlidNnym8Vg2dZWisutc9
61VNkQXEKdo4eTfJJRP3/ifCyVAyLfZm6/Thh0grLFHj
TjjKQprUk5exWfQtHPLqRCZ/40aE7Ev1Gz8hBgb10oxf
) ; ZSK; alg = RSASHA1 ; key id = 33267
cirroscope.com. 20468 IN DNSKEY 256 3 8 (
AwEAAeMfFqRTMJB2qiJj+A2Th570cOOe5nT9K2gd/rmA
vbib9jV4P1V5DmdHEZfrgtgoAFCzqWu8kU4uFUZfVXFQ
tel/IVpYWzzH+3rofiQHMwRHEgjv9vWKEMlEdg/SxyDS
WTH6qZIIvfgKEZ32y+jCD11vpZPpuj6ItuRm+EU++OP9
55ZBUBKbfTJtPtQh67c5aMJOHx6eBuhZYeBhgByQ+RVJ
yJgkhjgghluVYiXqDNv2ZCPNnhVu8KZ8Im+xs1AnLlwb
zHafuuidQJRQrAa53sSNvBb1uliP35qDn6wicHLbtjXY
roMFCsCVXmsx/Gg1qv5oZLPAgyfIse1slLqATNk=
) ; ZSK; alg = RSASHA256 ; key id = 3093
cirroscope.com. 20468 IN RRSIG DNSKEY 5 2 86400 (
20211108205913 20211009205913 33267 
cirroscope.com.
N4rtGV5iyM0HRxvK34j2FKtb7WiqQvHMRGuo4OjB07/s
06BEMix6OCyDwcVpei7kp8rKXZ4DAHqT1DxDdk8d8K3E
v1b3GehN7blLNDf52uUnoXjgIs3MEWmAE/69xmIwUExa
/CRP7QQVj96Kp7g4iR35xqAbmfjCcQrrk7Vll6U= )
cirroscope.com. 20468 IN RRSIG DNSKEY 5 2 86400 (
20211108205913 20211009205913 44602 
cirroscope.com.
Yps3RHKwb3Q1z/dQTkWB9S5M8+dwXgEad9yyiJiGo8pm
  

Re: [DNSOP] SHA-1 DS algo in arpa. :)

[Viktor Dukhovni]

On Thu, Sep 09, 2021 at 11:28:04AM -0400, Paul Wouters wrote:

> Looks like for arpa., the DS records are:
> 
> arpa. 27247   IN  DS  42581 8 1 
> 778606D9623F843F156E7D11ACBF815EB67AB516
> arpa. 27247   IN  DS  42581 8 2 
> F28391C1ED4DC0F151EDD251A3103DCE0B9A5A251ACF6E24073771D7 1F3C40F9
> 
> Per our own recommendations, we should probanly ask for the SHA-1 record to 
> be removed :)

Speaking of dogfood consumption, a year ago (Sep 2020) Wes and I reached
out to AMSL, suggesting algorithm rollovers to avoid use of deprecated
code points by ietf.org:

https://stats.dnssec-tools.org/explore/?ietf.org

The discussion also included Robert Sparks, Russ Housley and Jay Daley.

This ultimately stalled around questions of providing detailed guidance
to AMSL on the rollover logistics, and IIRC Wes suggested that perhaps
the right risk/reward tradeoff is for ietf.org to temporarily (a few
days) go unsigned and then deploy new keys with algorithm 13 or 8.

This too should probably be addressed, between AMSL and the relevant
interested parties...

-- 
Viktor.

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

Re: [DNSOP] NSEC3 Guidance - zone size impact of opt-out

[Viktor Dukhovni]

On Fri, Sep 03, 2021 at 09:48:56AM +0200, Vladimír Čunát wrote:

> On 03/09/2021 09.32, Paul Wouters wrote:
> > I guess with aggressive nsec, you might even gain some CPU cycles back
> > for that extra memory used, and receive less queries too? Saving you
> > some money? 
> 
> I think these savings won't be significant in delegation-centric zones 
> that are huge enough to consider opt-out.  (But from TLDs I'd perhaps 
> only consider .com to be huge enough.)

This is my take as well, essentially only .COM (>150M delegations) is so
large that presently there's still a compelling case for opt-out.

The next batch of large TLDs (.DE, .NET, .ORG, ..., with >10M
delegations) are ~10x smaller, and at these scales already the benefit
of opt-out is much lower.  Indeed prior to COVID-19, IIRC .ORG was
slated to switch to NSEC, but that got postponed.

Even .COM may before long reach a signed delegation rate where opt-out
starts to become less compelling (presently just 2.63%, but already
much higher recent levels):

https://stats.dnssec-tools.org/tld-graphs/com.png

The .CH TLD has recently introduced DNSSEC incentives, and the signed
delegations are rising dramatically, soon to a level where opt-out will
make little difference:

https://stats.dnssec-tools.org/tld-graphs/ch.png

The .SK TLD has recently issued a press release about reaching 50%
signed delegations in record time:

https://sk-nic.sk/we-are-one-of-the-best-in-dnssec-domain-security/

Joining the ranks of the .NO, .CZ, .NL and .SE ccTLDs, which all have
more than 50% of their delegations signed.  (The .bank and .insurance
TLDs which have a 100% signing mandate are at least two orders of
magnitude smaller).

-- 
Viktor.

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

Re: [DNSOP] Éric Vyncke's Discuss on draft-ietf-dnsop-rfc7816bis-10: (with DISCUSS)

[Viktor Dukhovni]

On Tue, Aug 24, 2021 at 05:23:31AM -0700, Éric Vyncke via Datatracker wrote:

> -- Section 2.1 --
> I support Erik Kline's COMMENT on this and am raising it to a blocking 
> DISCUSS.
> 
> A/ in all the discussion in the last §, a  would have the same benefit 
> when
> compared to a NS QTYPE. Or what did I miss ?

Actually, it might not be quite as effective in practice.  The reason is
that "" records are absent more often than "A" records, and when "A"
records are present, but "" records are not, "" queries elicit a
"denial of existence" response.

Unfortunately, broken denial of existence, though rare, is not as
infrequent as I'd like.  I see a non-negligible set of names where "A"
queries return answers, but "" queries SERVFAIL.

I am not aware of any advantage to using "" for the qname
minimisation queries, so "A" appears to me to be the better choice.

Examples:


https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/mail.ajsuarez.com.html
https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/mail.puz.de.html
https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/gloria.sntech.de.html

https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/mx1.espresso-gridpoint.net.html

https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/exchange.hctec.net.html

https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/qmin.d/fallback.hctec.net.html

-- 
Viktor.

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

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

[Viktor Dukhovni]

> On 13 Jul 2021, at 11:13 pm, Brian Dickson  
> wrote:
> 
> For example, in evaluating the break-points when partitioning the labels to 
> limit the total number of queries, the sequence COULD treat any contiguous 
> sequence of underscore labels as if it were a single label, and then do its 
> partitioning of labels using the same relative logic.

FWIW, my take is that treating consecutive special-use labels as a single label
only to resume minimisation at some subsequent non-special-use label sounds too
complex to me.  Intermediate special-use labels are just as likely to be ENTs
and to not be privacy-relevant zone cuts even when some labels below are not
special-use.

So whether it is MAY or SHOULD, my sense is that if an implementation chooses
to implement the proposed strategy it should just make the final query at
that point.

-- 
Viktor.

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

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

[Viktor Dukhovni]

> On 13 Jul 2021, at 6:22 am, Petr Špaček  wrote:
> 
> As Viktor pointed out in 
> https://mailarchive.ietf.org/arch/msg/dnsop/w7JBD4czpGKr46v-DlycGbOv9zs/ , it 
> seems that this problem plagues roughly tens out of 150k domains he surveyed. 
> I think this makes further discussion about _necessity_ of the workaround 
> kind of moot.

Full disclosure, I only tested TLSA records.  I can't speak to what
one might expect with SRV or other record types.  Yes, failures are
not that common, for what is worth another example:

https://dnsviz.net/d/_tcp.mail.ncsc.de/YO3DpQ/dnssec/
https://dnsviz.net/d/_25._tcp.mail.ncsc.de/YO3Bsw/dnssec/

Here the "A" query for the ENT was unexpectedly "REFUSED". :-(

If implementations at least seriously consider the advice to treat
special-use labels *specially*, I'll declare victory...

-- 
Viktor.

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

Re: [DNSOP] [Ext] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

[Viktor Dukhovni]

[ Resending complete message, previous draft was incomplete... ]

> On 12 Jul 2021, at 11:18 am, Paul Hoffman  wrote:
> 
> The current text is sufficient to tell resolver developers, and resolver 
> operators, why they should even think about underscore labels when they 
> create a QNAME minimisation strategy. Elevating such a strategy to a SHOULD 
> as a work-around for broken middleboxes that might (hopefully!) be fixed in 
> the future seems like a very wrong direction for the WG. 

If this were just a work-around for breakage, I'd be more inclined
to agree, but it is also a solid opportunity to improve performance,
because privacy-relevant changes of administrative control across
special-use labels should be very rare to non-existent.

So short-circuiting qname minimisation when a special-use label is
encountered seems like a win-win.

Measuring qname minimisation for TLSA RRs I see that today breakage
of qname minimisation is rare.  An example is:

https://dnsviz.net/d/_tcp.u24.altospam.com/YOx4nQ/dnssec/
https://dnsviz.net/d/_25._tcp.u24.altospam.com/YOx4IA/dnssec/

In which many (but not all) of the nameservers return NXDOMAIN for the
ENT.  Out of 150k RRsets, O(10) have ENT-related issues.

So one might reasonably neglect the breakage, but it is not clear that
we need to go looking for it, just to "punish" the operators in question.
There's an opportunity here to make qname minimisation more performant for
SRV, TLSA, ... lookups, speeding up Domain Control and LDAP server lookups,
email delivery, ...

Of course if the WG cannot come to consensus on "SHOULD"/"RECOMMENDED", I'll
gratefully settle for the current "MAY" (thanks for the document update)...

-- 
Viktor.

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

Re: [DNSOP] [Ext] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

[Viktor Dukhovni]

> On 12 Jul 2021, at 11:18 am, Paul Hoffman  wrote:
> 
> The current text is sufficient to tell resolver developers, and resolver 
> operators, why they should even think about underscore labels when they 
> create a QNAME minimisation strategy. Elevating such a strategy to a SHOULD 
> as a work-around for broken middleboxes that might (hopefully!) be fixed in 
> the future seems like a very wrong direction for the WG. 

If this were just a work-around for breakage, I'd be more inclined
to agree, but it is also a solid opportunity to improve performance,
because privacy-relevant changes of administrative control across
special-use labels should be very rare to non-existent.

So short-circuiting qname minimisation when a special-use label is
encountered seems like a win-win.

Measuring qname 

-- 
Viktor.

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

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

[Viktor Dukhovni]

> On 8 Jul 2021, at 10:28 am, Petr Špaček  wrote:
> 
> With my implementer hat on, I say "no", I don't see a compelling reason to 
> "mandate" it. Keep it at MAY/optional level and leave it to implementers to 
> decide what's best for their implementation and use-cases.

Just wanted to check what you mean by *mandate*, I don't quite see
RECOMMENDED as a mandate, my understanding is that SHOULD/RECOMMENDED
means "do this unless you have good reason to do otherwise".  So there
is certainly enough rope to ignore the advice.

How would you strongly suggest that stopping qname minimisation at the
first special-use label is probably a good idea, more strongly than just
mentioning as a possible optional optimisation?

-- 
Viktor.

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

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

[Viktor Dukhovni]

On Wed, Jul 07, 2021 at 08:46:17PM +0200, Peter Thomassen wrote:

> Especially because of the last reason above, I tend towards MAY.
> 
> However, I would endorse SHOULD / RECOMMENDED if the wording is
> changed such that "skipping a split" is done "up to the lowest-level"
> underscore label. In other words, jumping from example.com to
> _25._tcp.example.com would be RECOMMENDED, but jumping from
> example.com to foobar._openpgpkey.example.com would not, because
> "foobar" is no an underscore label. Generally, if there are N
> consecutive underscore labels, minimization SHOULD be skipped for the
> N-1 of them which are closest to the root.

I appreciate the caution, but resuming qname minimisation after skipping
a few labels does look rather complex, it also defeats the main goal of
avoiding known issues with likely ENTs at a name that is rarely a zone
cut, and even if a zone cut, likely not privacy relevant.

There are upcoming drafts on DANE client auth where the leaf label will
not be an "_" special-use label, but its parent is.

For the same reason that asking for "_tcp.smtp.example.com IN A" is
likely to run into trouble or at least impose excessive latency when the
leaf label is "_25", I'd like to *recommend* that qname minimisation
will do more harm than good even if the leaf label is "some-client-id".

I'd like to the see the tradeoff lean heavily towards "practical"
privacy enhancement.

-- 
Viktor.


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

Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

[Viktor Dukhovni]

On Wed, Jul 07, 2021 at 01:54:37PM -0400, Warren Kumari wrote:

> Viktor is suggesting that QNAME Minimization should be stopped when
> you run into an underscore ("_") label, instead of this being worded
> as a potential, optional mechanism.
> 
> Obviously there is a tradeoff here -- privacy vs deployment.
> 1: while it's **possible** that there is a delegation point at the
> underscore label, (IMO) it is unlikely. If there is no delegation, you
> will simply be coming back to the same server again and again, and so
> you are not leaking privacy sensitive information.
> 
> 2: some recursives are less likely to enable QNAME minimization
> because of the non-zero ENT and slight performance issues.
> 
> What does the WG think? Does the privacy win of getting this deployed
> and enabled sooner outweigh the potential small leak if there *is* a
> delegation inside the _ territory of the name?
> 
> Should the advice above be strengthened to SHOULD / RECOMMENDED?

Thanks, Indeed I'm arguing for RECOMMENDED (synonymous with SHOULD IIRC,
but sounds less intrasigent).

-- 
Viktor.

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

Re: [DNSOP] [Last-Call] Opsdir last call review of draft-ietf-dnsop-rfc7816bis-09

[Viktor Dukhovni]

On Fri, May 28, 2021 at 08:55:16PM -0700, Qin Wu via Datatracker wrote:

> Reviewer: Qin Wu
> Review result: Ready
> 
> This draft defines DNS Query Name Minimisation mechanism, it is motivated by
> QNAME minimisation implementation lesson and experience and well documented. I
> believe it is ready for publication.

In a post to the dnsop list on 2020-10-28:

https://mailarchive.ietf.org/arch/msg/dnsop/_H4aM5AquCSRlz0Pz3ncwl7Plpk/

I suggested that qname minimisation should not be applied to "special-use"
labels (those that start with "_").  I did not see any further
discussion of this point on the list, and the draft does not discuss
these.

Multiple consecutive special use labels occur in e.g. SRV and TLSA queries:

_ldap._tcp.ad.example.com. IN SRV ?
_25._tcp.smtp.example.com. IN TLSA ?

The topmost special-use label (_tcp in the above examples) is often an
empty-non-terminal (ENT), and it is sadly somewhat too common for some
name servers to mishandle (should be NODATA) the denial of existence of
ENTs.

Zone cuts at special-use labels are quite rare, and even when present
are unlikely to cross privacy-relevant administrative boundaries.

Because of the substantially increased risk of ENT lookup failure, and
lack of plausible privacy benefits in querying for "_tcp" prior to
querying for "_ldap._tcp", I'd like to see a recommendation in the draft
to avoid splitting the qname after the first special-use label.

-- 
Viktor.

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

Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation

[Viktor Dukhovni]

On Mon, Mar 15, 2021 at 05:38:40PM +, Jim Reid wrote:

> > However, operators of DNS servers SHOULD measure their path MTU to
> > well-known locations on the Internet, such as [a-m].root-servers.net
> > or [a-m].gtld-servers.net at setting up the servers.
> 
> I think it would be better to replace this with “Operators of DNS
> servers MAY measure their path MTU.”.

Sadly, we don't have a keyword that's midway between MAY and SHOULD, I
used to think that RECOMMENDED was it, but I was disabused of that
mistake some time back.  I think that the suggestion to measure the
path MTU is good advice.

The key thing to note is that in the resolver case this is only
applicable to full-service resolvers that directly query public
authoritative servers, and in the authoritative server case this
applies to servers serving public-Internet facing zones.

> Measuring the MTU to well-known locations on the Internet won’t be
> appropriate for some use cases. For instance inside private nets that
> aren’t connected to the Internet or for forwarding-only servers that
> never query an authoritatve server.

Right, the forwarding-mostly (or only) servers should just measure the
PMTU to the relevant upstream(s).

> IMO it’s a bad idea to recommend specific servers that could be the
> target for those PMTU probes. [Suppose those names change one day -
> unlikely for the above but you never know.] That could become a vector
> of (D)DoS attacks - probably not on the above name servers themselves
> but on the access routers in front of them that might well be
> rate-limiting ICMP packets.

I don't see the DDoS, such measurements should be rather infrequent, in
particular, I don't see why these would be much more frequent than root
zone priming queries, which full service resolvers do routinely at
startup.

> This could get nasty with icky CPE
> firmware: imagine every home router in (say) Comcast’s net doing PMTU
> to the same root server.

These would generally not all boot up at the same time, and would be
expected to be configured in forward-only mode to the relevant Comcast
iterators.

> Besides, is the PMTU to a root or .com server, going to be the same as
> that for the example.whatever name servers?

But the proposal remains sound, because that server also measures its
PMTU to the root, and assuming PMTU reduction happens mostly at the
respective edges of the network, and not in the core, the lower of
the two PMTUs to some suitable core nodes would typically also be
the PMTU end-to-end between them.

Thus if a full-service iterator bases its EDNS UDP size on its PMTU
to the core, and the authoritative server replies with a size that
is at most its respective PMTU, you'll most often end up with a
workable lower-bound.

> If PMTU is to be used, maybe it needs to be applied to all
> authoritative name servers a resolver queries?

Not needed, on the assumption that the path from each to the
core is as "wide" as the path from either a common core node.

-- 
Viktor.

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