On Sun, 2020-11-15 at 12:40 -0800, Brian Dickson wrote:
>
> > > Using TLSA records at _853._tcp. in a signed zone provides an
> > > unambiguous signal to use optionally TLSA, in a downgrade-resistant
> > > manner.
> >
> > Not downgrade-resistant, until NS names in delegations become signed.
>
Thanks for reading and providing feedback!
Peter van Dijk wrote:
> On Wed, 2020-11-11 at 19:07 +, Tony Finch wrote:
> >
> > * Encryption would apply to the server as a whole, whereas the
> > working group consensus is that it should be possible for
> > different zones on the same
Brian Dickson wrote:
> Attempting to do XFR for many name servers which are infrequently used
> would have scalability issues from any resolver, if the server names are
> in a large number of zones. One approach to reducing this issue is
> aggregating server names inside many fewer zones. Doing
On Mon, Nov 16, 2020 at 5:28 PM Tony Finch wrote:
> Brian Dickson wrote:
>
> > Attempting to do XFR for many name servers which are infrequently used
> > would have scalability issues from any resolver, if the server names are
> > in a large number of zones. One approach to reducing this issue
On Mon, Nov 16, 2020 at 2:02 AM Peter van Dijk
wrote:
> On Sun, 2020-11-15 at 12:40 -0800, Brian Dickson wrote:
> >
> > > > Using TLSA records at _853._tcp. in a signed zone provides
> an unambiguous signal to use optionally TLSA, in a downgrade-resistant
> manner.
> > >
> > > Not
On Mon, 2020-11-16 at 10:22 -0800, Brian Dickson wrote:
> > > That's a moot point.
> > > TLSA records MUST be signed, and the TLSA RFC makes this very clear: RFC
> > > 6698 section 4.1 (Determining whether a TLSA RRSet can be used MUST be
> > > based on the
> > >DNSSEC validation state (as
