On Wed, Nov 11, 2020 at 1:20 PM Tony Finch <[email protected]> wrote: > Manu Bretelle <[email protected]> wrote: > > > Having this as an ID or possibly a github repo may make it easier to > refer > > to/iterate than just this email. > > Yes! https://github.com/fanf2/draft-dprive-adot
Thanks! > > > > I had attempted to quickly categorize some of those approaches (albeit a > > much smaller list) in a matrix in [0] but did not follow through since. > > > > [0] > https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 > > Ah, I haven't been paying enough attention to meetings so I missed this! I > think I need the speaker notes to understand it properly :-) > Totally fair, pretty sure there were no speaker notes ;) . The presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 . Originally, there was this draft https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01 and the solutions in the slide deck were compiled from feedback/ideas that came up while talking with other folks. > > Your title "DoT for insecure delegations" is interesting: one of the > problems with what I have written so far is that it is too much a post-hoc > justification for using TLSA records to support ADoT. So I have built > nameserver authentication on top of TLSA on top of DNSSEC. > Speaking of which, I think Brian Dickson did a good job of describing an "hybrid" approach which I had notes of, but never got to write down properly. Here is the link: https://mailarchive.ietf.org/arch/msg/dns-privacy/FdUhMUGNR-CybLrTBQfgGjq0ZY0/ My TL;DRed notes, in the context of serving zones across name servers in (multiple) out-of-bailiwick zones, that I think echoes Brian's more throughout description: Other approaches to signalling DoT support to the recursive nameservers may be through the presence of TLSA record, special record at the name server side. In the end, the name server zone owner will have to be authoritative, such authoritative answer can only be validated if it is signed. By separating zones from nameservers, one can provide DNSSEC signing at the name server zone level without having to enforce it at the zones which are served. Having multiple name server zones would: - allow enabling DNSSEC on a subset of the nameservers without risking impacting all the DNS traffic. - allow to stage key roll on a subset of the nameservers, and ensuring that in the worst case, only a subset of the traffic is impacted in case of mishap. > One of my unstated assumptions is that DoT will be problematic for TLDs, > and (with QNAME minimization) it matters more for leaf zones, so it is > likely to be deployed there first. But DNSSEC is deployed to a much higher > proportion of TLDs than leaf zones, so there's a good chance I'm wrong. > yeah, and this is where zones hosted by DNS providers may benefit of this hybrid approach if the providers are supporting DNSSEC for their name server zones. But I just quickly checked Route53 and Google Domain, and none of them have their NS names signed. Manu > > Tony. > -- > f.anthony.n.finch <[email protected]> http://dotat.at/ > Shetland Isles: Southerly 6 to gale 8, decreasing 4 or 5 later in west. > Rough > or very rough. Rain or drizzle. Moderate or poor, becoming good later in > west. >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
