[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Sun, Sep 19, 2021 at 2:42 PM
Subject: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dnsop-ds-hack-02.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-ds-hack
Revision:   02
Title:  DS Algorithms for Securing NS and Glue
Document date:  2021-09-19
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-02.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-ds-hack/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-ds-hack
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-ds-hack-02

Abstract:
   This Internet Draft proposes a mechanism to encode relevant data for
   NS records on the parental side of a zone cut by encoding them in DS
   records based on a new DNSKEY algorithm.

   Since DS records are signed by the parent, this creates a method for
   validation of the otherwise unsigned delegation records.

   Notably, support for updating DS records in a parent zone is already
   present (by necessity) in the Registry-Registrar-Registrant (RRR)
   provisioning system, EPP.  Thus, no changes to the EPP protocol are
   needed, and no changes to registry database or publication systems
   upstream of the DNS zones published by top level domains (TLDs).

   This NS validation mechanism is beneficial if the name server _names_
   need to be validated prior to use.




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

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-glueless-02.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Wed, Sep 22, 2021 at 12:50 AM
Subject: New Version Notification for draft-dickson-dnsop-glueless-02.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dnsop-glueless-02.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-glueless
Revision:   02
Title:  Operating a Glueless DNS Authority Server
Document date:  2021-09-22
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-02.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-glueless/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-glueless
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-glueless-02

Abstract:
   This Internet Draft proposes a method for protecting authority
   servers against MITM and poisoning attacks, using a domain naming
   strategy to not require glue A/ records and use of DNSSEC.

   This technique assumes the use of validating resolvers.

   MITM and poisoning attacks should only be effective/possible against
   unsigned domains.

   However, until all domains are signed, this guidance is relevant, in
   that it can limit the attack surface of unsigned domains.

   This guidance should be combined with [I-D.dickson-dnsop-ds-hack]




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

[DNSOP] Fwd: New Version Notification for draft-dickson-dprive-dnst-00.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Sun, Oct 24, 2021 at 9:13 PM
Subject: New Version Notification for draft-dickson-dprive-dnst-00.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dprive-dnst-00.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dprive-dnst
Revision:   00
Title:  Resource Record for Signaling Transport for DNS to
Authority Servers
Document date:  2021-10-24
Group:  Individual Submission
Pages:  5
URL:
https://www.ietf.org/archive/id/draft-dickson-dprive-dnst-00.txt
Status: https://datatracker.ietf.org/doc/draft-dickson-dprive-dnst/
Html:
https://www.ietf.org/archive/id/draft-dickson-dprive-dnst-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dprive-dnst


Abstract:
   This Internet Draft proposes an RRTYPE to signal explicit support for
   transport types for DNS service.  This new RRTYPE is "DNST".  The
   available transports to signal are TCP and UDP on port 53 (DNS), and
   DoT (DNS over TLS) transport using TCP port 853.




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

[DNSOP] Fwd: New Version Notification for draft-dickson-dprive-adot-auth-06.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Tue, Nov 9, 2021 at 6:11 PM
Subject: New Version Notification for draft-dickson-dprive-adot-auth-06.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dprive-adot-auth-06.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dprive-adot-auth
Revision:   06
Title:  Authenticated DNS over TLS to Authoritative Servers
Document date:  2021-11-09
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-06.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/
Html:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-06.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dprive-adot-auth
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dprive-adot-auth-06

Abstract:
   This Internet Draft proposes a mechanism for DNS resolvers to
   discover support for TLS transport to authoritative DNS servers, to
   validate this indication of support, and to authenticate the TLS
   certificates involved.

   This requires that the name server _names_ are in a DNSSEC signed
   zone.

   This also requires that the delegation of the zone served is
   protected by [I-D.dickson-dnsop-ds-hack], since the NS names are the
   keys used for discovery of TLS transport support.

   Additional recommendations relate to use of various techniques for
   efficiency and scalability, and new EDNS options to minimize round
   trips and for signaling between clients and resolvers.




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

[DNSOP] Status of draft-ietf-dnsop-dns-error-reporting

[Roy Arends]

Dear WG, 

After the October 26, IETF DNSOP interim WG on DNS Error Reporting, the 
document editors have made the following changes to reflect the discussion:

Change 1) Due to qname minimisation, the reporting agent may not know that the 
reported string has been shortened. There were a few options suggested, such as 
adding a label counter. However, the most straightforward option seemed to be 
to start the reporting query with an _er label as well.

Change 2) There was an observation by developers that some authoritative 
servers do not parse (unknown) EDNS0 options correctly, leading to an 
additional roundtrip by the resolver. It was suggested that authoritative 
servers could return the new EDNS0 option “unsolicited”. This is already the 
case for Extended DNS errors. We have adopted this suggestion. It was also 
pointed out that this kind of unsolicited behaviour can be surveyed. We believe 
that one such effort is underway.

Change 3) There as a lot of descriptive text what implementations should and 
shouldn’t do, and what configurations should and shouldn’t do. This was found 
to be overly descriptive and pedantic, and has now been removed.

There was a request to put the markdown version of the document in GitHub. This 
has now been placed here: 
https://github.com/RoyArends/draft-ietf-dnsop-dns-error-reporting 


New version: 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-01.txt
 

Diffs: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-01 


Warm regards,

Roy Arends

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

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

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : DNS Error Reporting
Authors : Roy Arends
  Matt Larson
Filename: draft-ietf-dnsop-dns-error-reporting-01.txt
Pages   : 10
Date: 2021-11-09

Abstract:
   DNS Error Reporting is a lightweight error reporting mechanism that
   provides the operator of an authoritative server with reports on DNS
   resource records that fail to resolve or validate, that a Domain
   Owner or DNS Hosting organization can use to improve domain hosting.
   The reports are based on Extended DNS Errors [RFC8914].

   When a domain name fails to resolve or validate due to a
   misconfiguration or an attack, the operator of the authoritative
   server may be unaware of this.  To mitigate this lack of feedback,
   this document describes a method for a validating recursive resolver
   to automatically signal an error to an agent specified by the
   authoritative server.  DNS Error Reporting uses the DNS to report
   errors.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [DNSOP] [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Paul Wouters]

On Tue, 9 Nov 2021, Peter Thomassen wrote:


On 11/9/21 3:56 PM, Paul Wouters wrote:

 Now let's consider bootstrapping for dedyn.io *itself* (not one of its
 children!).  The location of the bootstrapping records for this domain
 would be dedyn.io._boot.ns1.desec.io, which is the same as the name of
 the *zone* which constains bootstrapping records for domains *under*
 dedyn.io, such as at example.dedyn.io._boot.ns1.desec.io.


 Aren't you saying here that you want to be able to boostrap dedyn.io,
 meaning it is currently unsigned, while also having a problem with
 containing its "children", eg it is already used for boostrapping
 other domains, while it it unsigned yet itself ?


In such a situation, a domain like dedyn.io (which has other subzones
on the same nameserver) is not necessarily already being used for
bootstrapping.

Example: Imagine a DNS operator which supports both DNSSEC and
bootstrapping.  They have a customer with the zone example.com and
a subzone foo.example.com, but DNSSEC is currently off.

Suppose the customer turns on DNSSEC in the operator's service portal.
What will happen now is that the _boot zones under the operator's
nameserver hostnames will be populated with bootstrapping records for
these domains, with prefixes example.com._boot and
foo.example.com._boot.


I think in this case, you cannot start foo.example.com._boot. because
its parental agent (which happens to be you too but should still follow
the RFC) detects that the parent zone example.com is not signed and
thus cannot perform a bootstrap of foo.example.com. Doing them at once
would be a race condition. You'd really want to do these one after the
other.


Remember, the bootstrapping records are of type CDS/CDNSKEY, and they
will now show up both at the level of "foo.example.com._boot" and one
level up, at the level of "example.com._boot".


But can't you still publish all of these? like:

in dedyn.io zone (or ns1.dedyn.io zone or _boot.ns1.dedyn.io zoe):

example.._boot.ns1.dedyn.io IN CDNSKEY [...]
foo.._boot.ns1.dedyn.io IN CDNSKEY [...]

in your example.com zone:

example.com. IN CDNSKEY [...]

In your foo.example.com zone:

foo.example.com. IN CDNSKEY [...]


As a result, the DNS operator is no longer free to make a delegation
at "example.com._boot", because that would change the meaning of the
bootstrapping records.  (CDS/CDNSKEY records have a conflicting meaning
when they occur at an apex.)


I still don't see the APEX problem?


However, there's nothing wrong with enabling bootstrapping records
for both these domains at once.


I think there is. You can't boostrap a domain whose parent is not
already fully DNSSEC enabled. As those parents are not valid candidates
to take in CDS records.


 There's no reason why DS records for
foo.example.com should not be put into example.com while
bootstrapping for example.com is running in parallel.


There is because the parent is unsigned and so whatever it is publishing
about its children is lacking trust.


 (It's not
even necessary for example.com to ever be securely delegated, if there
is another trust root for it, e.g. in an enterprise setting.)


There is. nothing under example.com will ever DNSSEC validate. It cannot
make claims abouts its sub delegations via DS records as those DS
records would be bogus.


DS bootstrapping does not require the parent of the bootstrapped domain
to be secure.  The protocol should not concern itself with the chain of
trust above the domain that is being bootstrapped.


This intension was not clear to me from reading the draft. You want to
DNSSEC bootstrap "islands of trust" ? I think that should be out of
scope. You are then already in enterprise/provisioning territory where
this provisioning can just be added without this new protocol.


The protocol should not make any assumptions like that, so that
bootstrapping of several domains along the same branch in the DNS tree
(e.g. example.com, and foo.example.com) can be fully orthogonal.


I disagree. Sure you can have an island of trust, eg a manually
configured trust anchor for internal.example.com with a DS trust anchor,
but then you should still insist on all checks from internal.example.com
to be securely delegated. So you first have to do foo.internal.example.com
before you can do bar.foo.internal.example.com.

While I think this is true from a security and logical point of view, I
think you will run into practical issues if you are attempting to
retrieve or publish DS records that lack DNSSEC validation.


Let's consider the bootstrapping namespace under _boot.ns1.desec.io.
There would usually be NS/DS records at this name.

However, it should be possible to introduce zone cuts underneath that
name, so operators can control the size and churn of the zones involved
in bootstrapping.  This idea madeit into the draft based on feedback
by John Levine, who pointed out that scalability should be a very
strong priority.

So, there may be additional NS/DS rrsets at 

Re: [DNSOP] draft-moura-dnsop-negative-cache-loop

[Ralf Weber]

Moin!

On 9 Nov 2021, at 17:12, Petr Špaček wrote:
>> 4.  New requirement
> I think section 4 should not require full blown _loop_ detection, but any 
> sort of limit should be good enough for compliance.
>
> I mean, implementing a loop detection algorithm in hot path might not be a 
> good idea, mainly because most of the time it just wastes resources - 
> compared to a simple resource limit like, say, number of delegation steps per 
> query.
>
> To be clear:
> I don't think the resolver _has to_ stop resolution at the earliest moment it 
> has data to potentially detect the cycle. If the cycle has length 2, it 
> should be okay to allow the resolver to do 4,6,8,... steps before giving up. 
> For compliance it should be good enough to stop within "a" reasonable limit 
> (not necessarily specified by a number).
I fully agree here. Most of the current or older implementations solve this by 
resource limiting and had no problem with tsuName. Only some new cloud 
implementations had a problems. So please don’t require those that had working 
mitigations to change them.

> An additional nitpick: I think section 4.  New requirement sound avoid term 
> "negative" caching. In my eyes it is a bit misleading because "negative" is 
> typically used for different kinds of answers.
Maybe failed resolution caching is a better term here.

So long
-Ralf
——-
Ralf Weber

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

Re: [DNSOP] nsec3-parameters opinions gathered

[Petr Špaček]

On 09. 11. 21 18:57, Viktor Dukhovni wrote

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.


Agreed, 1 is probably what we will have to live with in spec for validators.


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.


+1

Petr Špaček

___
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] IETF 112 DNSOP WG agenda

[Benno Overeinder]

An updated agenda for DNSOP has been published.  We had to swap some 
presentations due to the availability of presenters.


https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-01


Best regards

Suzanne, Tim and Benno


On 03/11/2021 22:37, Benno Overeinder wrote:

All,

The DNSOP WG agenda for IETF 112 has been published, see 
https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-00.


Best regards,

Suzanne
Tim
Benno

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


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

Re: [DNSOP] draft-moura-dnsop-negative-cache-loop

[Petr Špaček]

On 08. 11. 21 8:49, Giovane C. M. Moura wrote:

Folks,

Loops in DNS are an old problem, but as our tsuname[0,1] disclosure last
May shows, they are still a problem.

We wrote a new draft that adds a new requirement to existing solutions:
recursive resolvers must detect and negative cache problematic (loop)
records.

It would be nice to hear what folks have to say.


I generally support the direction, 22+ years after RFC 2308 was 
published it's time to have a look at it again.



If I understand this correctly, TL;DR summary essentially is
""" make https://datatracker.ietf.org/doc/html/rfc2308#section-7.1 
mandatory """

(even though your version is a bit stronger). Is that correct?

If it is the case, then the document needs to clearly update 2308 
section 7.1 and go through standards track. Right now this might not be 
clear.



Ad the draft content:


2.  Past solutions
This section somehow does not mention RFC 2308 section 7.1 which solves 
most of the problem if implemented. In fact BIND has an implementation 
of it and is not vulnerable to the TsuNAME attack (or at least I was not 
able to reproduce it).



3.  Current Problem
Nitpick: Maybe this should go to Appendix as there is no protocol 
description in here?




4.  New requirement
I think section 4 should not require full blown _loop_ detection, but 
any sort of limit should be good enough for compliance.


I mean, implementing a loop detection algorithm in hot path might not be 
a good idea, mainly because most of the time it just wastes resources - 
compared to a simple resource limit like, say, number of delegation 
steps per query.


To be clear:
I don't think the resolver _has to_ stop resolution at the earliest 
moment it has data to potentially detect the cycle. If the cycle has 
length 2, it should be okay to allow the resolver to do 4,6,8,... steps 
before giving up. For compliance it should be good enough to stop within 
"a" reasonable limit (not necessarily specified by a number).



An additional nitpick: I think section 4.  New requirement sound avoid 
term "negative" caching. In my eyes it is a bit misleading because 
"negative" is typically used for different kinds of answers.



I hope this early feedback helps a bit.

--
Petr Špaček

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

Re: [DNSOP] [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Peter Thomassen]

Hi Paul,

On 11/9/21 3:56 PM, Paul Wouters wrote:

Now let's consider bootstrapping for dedyn.io *itself* (not one of its
children!).  The location of the bootstrapping records for this domain
would be dedyn.io._boot.ns1.desec.io, which is the same as the name of
the *zone* which constains bootstrapping records for domains *under*
dedyn.io, such as at example.dedyn.io._boot.ns1.desec.io.


Aren't you saying here that you want to be able to boostrap dedyn.io,
meaning it is currently unsigned, while also having a problem with
containing its "children", eg it is already used for boostrapping
other domains, while it it unsigned yet itself ?


In such a situation, a domain like dedyn.io (which has other subzones
on the same nameserver) is not necessarily already being used for
bootstrapping.

Example: Imagine a DNS operator which supports both DNSSEC and
bootstrapping.  They have a customer with the zone example.com and
a subzone foo.example.com, but DNSSEC is currently off.

Suppose the customer turns on DNSSEC in the operator's service portal.
What will happen now is that the _boot zones under the operator's
nameserver hostnames will be populated with bootstrapping records for
these domains, with prefixes example.com._boot and
foo.example.com._boot.

Remember, the bootstrapping records are of type CDS/CDNSKEY, and they
will now show up both at the level of "foo.example.com._boot" and one
level up, at the level of "example.com._boot".

As a result, the DNS operator is no longer free to make a delegation
at "example.com._boot", because that would change the meaning of the
bootstrapping records.  (CDS/CDNSKEY records have a conflicting meaning
when they occur at an apex.)

However, there's nothing wrong with enabling bootstrapping records
for both these domains at once.  There's no reason why DS records for
foo.example.com should not be put into example.com while
bootstrapping for example.com is running in parallel.  (It's not
even necessary for example.com to ever be securely delegated, if there
is another trust root for it, e.g. in an enterprise setting.)

DS bootstrapping does not require the parent of the bootstrapped domain
to be secure.  The protocol should not concern itself with the chain of
trust above the domain that is being bootstrapped.

The protocol should not make any assumptions like that, so that
bootstrapping of several domains along the same branch in the DNS tree
(e.g. example.com, and foo.example.com) can be fully orthogonal.
The only thing that's necessary is that the NS hostname have a
validation path.


To clear up the misunderstanding, I'll write out the example in detail.

dedyn.io has NS ns1.desec.io and ns2.desec.org.  Children of dedyn.io
typically have the same NS rrset.


I'm a bit confused about the term "children" here. Normally in DNS we
say children for subdomains/delegations. But further done, you are
talking about entrie in .com too, so I think the term children here is
confusing. Maybe use "target domains" or "customer domains" instead of
the term "children" ?


The example I gave was primarily about dedyn.io and example.dedyn.io;
that's why I made the statement about the children of dedyn.io and
their NS records.

Of course, other zones (such as under .com) can be hosted on the same
nameserver.  That's why I later gave another example of a bootstrapping
zone that may deserve its own delegation (com._boot.ns1.desec.io).
Apologies in case this made things less clear.


dedyn.io._boot.ns1.desec.io  # bootstrapping zone for dedyn.io children
 com._boot.ns1.desec.io  # bootstrapping zone for com children
 _boot.ns1.desec.io  # zone for all other bootstrapping


Ok, so you want either an NS/DS for _boot.ns1.desec.io or you want
individual NS/DS records for ._boot.s1.desec.io ?


Let's consider the bootstrapping namespace under _boot.ns1.desec.io.
There would usually be NS/DS records at this name.

However, it should be possible to introduce zone cuts underneath that
name, so operators can control the size and churn of the zones involved
in bootstrapping.  This idea madeit into the draft based on feedback
by John Levine, who pointed out that scalability should be a very
strong priority.

So, there may be additional NS/DS rrsets at com._boot.ns1.desec.io, or
dedyn.io._boot.ns1.desec.io.

Adding such a delegation turns the corresponding name into an apex, and
thus requires that there are no bootstrapping CDS/CDNSKEY records at
that name, because they would silently change in meaning.

The problem is that if we now put bootstrapping records at these
delegation points, they suddenly take on the meaning of conventional
(non-bootstrapping) CDS/CDNSKEY records for these subzones.


Now let's consider bootstrapping for dedyn.io *itself* (not one of its
children!).  The location of the bootstrapping records for this domain
would be dedyn.io._boot.ns1.desec.io, which is the same as the name of
the *zone* which constains bootstrapping records for domains *under*
dedyn.io, such 

Re: [DNSOP] [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Paul Wouters]

On Tue, 9 Nov 2021, Peter Thomassen wrote:

[ cut hashing or not discussion, can be done later ]


 You can't bootstrap in-baliwick anyway, can you?


There seems to be a misunderstanding:  The not-in-bailiwick limitation
means that a nameserver can't bootstrap its own domain, for lack for a
pre-existing validation path.  But in the above example, it was not
assumed that any of the zones mentioned has any in-bailiwick NS.


right. But then I am confused by:


Now let's consider bootstrapping for dedyn.io *itself* (not one of its
children!).  The location of the bootstrapping records for this domain
would be dedyn.io._boot.ns1.desec.io, which is the same as the name of
the *zone* which constains bootstrapping records for domains *under*
dedyn.io, such as at example.dedyn.io._boot.ns1.desec.io.


Aren't you saying here that you want to be able to boostrap dedyn.io,
meaning it is currently unsigned, while also having a problem with
containing its "children", eg it is already used for boostrapping
other domains, while it it unsigned yet itself ?




To clear up the misunderstanding, I'll write out the example in detail.

dedyn.io has NS ns1.desec.io and ns2.desec.org.  Children of dedyn.io
typically have the same NS rrset.


I'm a bit confused about the term "children" here. Normally in DNS we
say children for subdomains/delegations. But further done, you are
talking about entrie in .com too, so I think the term children here is
confusing. Maybe use "target domains" or "customer domains" instead of
the term "children" ?


When a customer registers a new name under dedyn.io (it is a public
suffix), we currently have some kind of hook that creates the DS
records in the dedyn.io zone.  Once there is a good bootstrapping
protocol, there should be no need to keep that kludge.


Right. But I would assume that this means dedyn.io is already fully
DNSSEC enabled. Else any _boot records cannot be trusted as they have
no DNSSEC protection.


We would like to use the bootstrapping protocol to enable DNSSEC for
such sub-zones.  For that, we have to read the bootstrapping records,
which would be, without hashing, located at something like
example.dedyn.io._boot.ns1.desec.io (sticking to _boot for now).

Because dedyn.io has a lot of delegations and keeps changing, we'd like
to run bootstrapping for dedyn.io in a separate zone (same for com).
We'd arrive at a setup like this:

dedyn.io._boot.ns1.desec.io  # bootstrapping zone for dedyn.io children
 com._boot.ns1.desec.io  # bootstrapping zone for com children
 _boot.ns1.desec.io  # zone for all other bootstrapping


Ok, so you want either an NS/DS for _boot.ns1.desec.io or you want
individual NS/DS records for ._boot.s1.desec.io ?


Now let's consider bootstrapping for dedyn.io *itself* (not one of its
children!).  The location of the bootstrapping records for this domain
would be dedyn.io._boot.ns1.desec.io, which is the same as the name of
the *zone* which constains bootstrapping records for domains *under*
dedyn.io, such as at example.dedyn.io._boot.ns1.desec.io.


So as stated above, I don't think this is a valid use case, as you need
the bootstrap already in place ?


This has nothing to do with in-bailiwick.  The problem occurs because
bootstrapping records cannot be at the apex (as to not overload the
meaning of apex CDS/CDNSKEY records), but by "inheriting" the structure
under dedyn.io, a situation arises where this condition is not met.

The solution is to not "inherit", but flatten the hierarchy, which is
what the hash does.  With hashing, children of dedyn.io would have
their bootstrapping records under h(dedyn.io)._boot.ns1.desec.io, such
as example.h(dedyn.io)._boot.ns1.desec.io.


I would think you could still use exmaple.dedyn.io._boot.ns1.desec.io.
(regardless of hashing or not). But you need desec.io to already be DNSSEC
signed, and since you control desec.io, it should be trivial to add NS
and DS for _boot.dedyn.io, or TLD._boot.dedyn.io without needing to
bootstrap?


It is unclear to me how such situations would properly be dealt with if
the bootstrapping owner names retained the target domains' hierarchy.


Can you explain why the above wouldn't work ?


One could of course specify that you can only ever bootstrap *one*
name along a certain branch of the DNS tree.  But what would be the
motivation for such a limitation?


No, you should be able to do all the domains you want, as long as you
prefix them into the _boot zone?


I'm sure the situation could be complicated futher by considering more
sophisticated delegation hierarchies (e.g. dedyn.io is at ns1.desec.io,
foo.dedyn.io is not, but bar.foo.dedyn.io is again at ns1.desec.io, and
so on).  These are all things the protocol should be ignorant of.


I don't think that needs to matter, you can even run NS/DS onto
_boot.ns1.dedyn.io with only ns1 as its nameserver and _boot.ns2.dedyn.io
with only ns2 as its nameserver?


The hash ensures that *different things* get *different names*.

Re: [DNSOP] [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Nils Wisiol]

On Tue, 2021-11-09 at 04:55 +0100, Peter Thomassen wrote:
> The problem occurs because bootstrapping records cannot be at the
> apex (as to not overload the meaning of apex CDS/CDNSKEY records),
> but by "inheriting" the structure under dedyn.io, a situation arises
> where this condition is not met.

Following Peter's argument, a solution that avoids hashing requires to
use new record types for bootstrapping in order to avoid confusion with
the original meaning of CDS/CDNSKEY records. This would increase
implementation work for the proposal quite a lot, as currently no
changes to popular auth NS software is needed.

Nils

-- 
deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525


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

Re: [DNSOP] nsec3-parameters opinions gathered

[Petr Špaček]

On 08. 11. 21 14:41, Wes Hardaker wrote:

Petr Špaček  writes:

Thanks for the detail notes Petr, very helpful.


 From my point of view the RFC does not need to stick to the value
currently implemented in resolvers.


Good point, and maybe the right phrasing I should have used should have
been "what value would implementations refuse to switch to"?


Well, the answer is the same:
For validators it's a moving target. A high value which was "necessary" 
yesterday might not be needed today because a large hoster moved on.




In part, I worry that code authors would object to having just changed
something and refused to change again.  It seems like reports are
overcoming that problem though  :-)

[I'm not sure we're at zero yet...]


Sure, but that's not the point. The value is ever-changing.

As I see it, we can either:
a) Specify _a_ value valid for November 2021 and produce a RFC with 
values not reliable beyond November 2021.
b) Specify _the_ ultimate target which guarantees interoperability in 
future, and make it really clear in the text.


I think the second option is much better, so let me try this approach. 
I'm proposing text along those lines:



Addition for section

3.1.  Best-practice for zone publishe


Please note that any number of iterations larger than 0 carries risk of 
interoperability problems. Any zone using higher iterations counts is 
willingly signing up for problems.
The reason for this is that DNSSEC responders and validators have to 
limit resource usage caused by excessive iteration values, and even very 
small numbers of iterations impose significant overhead, which motivates 
software vendors to drive the limit down to 0.

-

If we really wanted we could add an appendix with an illustrative table 
(with disclamer about being just ilustrative for one software version, 
point in time, hardware etc. etc.):


| Iterations | QPS [% of 0 iterations QPS] |
||-|
| 0  | 100 %   |
| 10 | 89 %|
| 20 | 82 %|
| 50 | 64 %|
| 100| 47 %|
| 150| 38 %|

If we wanted a simpler example we could say something like "at the time 
of this writing, mere 10 iterations caused over 10 % QPS drop on two 
popular authoritative server implementations".
(As a sanity check I just tested Knot DNS and the impact there is very 
similar to what we see in the table about for BIND.)


Honestly I don't think it's necessary.


As for

3.2.  Recommendation for validating resolvers


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?

--
Petr Špaček

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