On Thu, Oct 31, 2019 at 12:11 PM Jim Reid <[email protected]> wrote: > > > > On 30 Oct 2019, at 18:40, Livingood, Jason <[email protected]> > wrote: > > > > I agree that this is not a technical issue of scaling the root; that > quantity of queries per day and second is not a big problem. Rather, as you > note, it is a layer-9 issue. But I don't think we should constrain our > requirements development & protocol design because of this. > > In principle, I agree with you. Though in practice, I'm questioning if it > makes sense to work on ADoT unless there's a strong likelihood it will get > mainstream deployment and adoption. [What's the point of producing > something that won't see widespread use?] And surely if there's going to be > ongoing protocol design work, that needs to take account of the concerns of > those who run busy authoritative servers? AFAICT apart from a recent ID > from Verisign, they have not been part of the discussion so far. > > I think there will be both interest and deployment, sufficient to justify the effort.
IMHO, including the ability for authority operators to signal support, may be sufficient to address the concerns about the root servers, including that they may have different levels of interest in supporting DoT. E.g. Having a well-defined record at or under the NS name that indicates support for transport protocols would enable each root-server.net instance to signal whether DoT queries might be answered. That itself might crack open another can of worms: DNSSEC signing of root-servers.net, including possible naming choices for the root servers (qv related investigative work that was being done by the RSSAC Caucus.) One idea that was not considered previously, that just occurred to me: have root-servers.net be DNSSEC signed, but without a secure delegation. It would be an island of security that could be optionally be securely accessible via adding a new trust anchor, specifically if/when a particular resolver wishes to use ADoT to authority servers. I believe it would not impact the priming responses. (Also, I think the ADoT requirements should include an assumption that ADoT is not supported unless the nameserver name explicitly signals such at or under the nameserver's name.) Brian
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
