On Mon, Nov 4, 2019 at 12:37 PM Tony Finch <[email protected]> wrote: > Paul Wouters <[email protected]> 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 <[email protected]> http://dotat.at/ > partnership and community in all areas of life > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
