Re: [dns-privacy] [Ext] Threat Model

On Mon, Nov 4, 2019 at 12:37 PM Tony Finch <dot@dotat.at> wrote:

> Paul Wouters <paul@nohats.ca> wrote:
> >
> > The right way to do this is a DNSKEY flag, which is protected by the
> > signed DS at the parent. Similar to draft-powerbind for the
> > delegation-only domain.
>
> That's per-zone, though, whereas DoT support is per-server.
>

Well, it kind of depends, i.e. yes and no.

E.g. a DNS hosting provider might (or might not) apply the DoT support to
all the zones hosted on a given server, which has the effect of being
per-server, while still being implemented at a per-zone level.

Per-zone also is much friendlier to multi-provider (primary/secondary), in
those cases, i.e. prevents targeted downgrades on such zones (presuming the
secondary actually serves on the DoT port).

The names of the servers (and certificate management) would be orthogonal
to the signaling of DoT support. I would expect the TLSA records would be
per-server and orthogonal to the per-zone signaling of DoT support.

(The analogy would be routing registries and routing announcements. You
have to have the registration done first before the announcement, but the
registration and the announcement are distinct elements. Similar also to DS
and DNSKEY records.)

Brian

>
> DS records that somehow encode NS target names in their rdata might
> work...
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> partnership and community in all areas of life
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>