On Jul 10, 2018, at 16:09, Adam Roach <a...@nostrum.com> wrote: > [as an individual] > >> On 7/10/18 9:59 AM, Paul Wouters wrote: >> It seems more like an extension of the Public Suffix. Which domains can >> make claims about other domains. > > Based on the conversation that took place in DoH in Singapore, I think it's > mostly *not* about this. The questions that have come up so far include: (a) > If the record that is pushed to me is DNSSEC signed, is that sufficient to > trust it? (b) If the record that is pushed to me is not DNS signed, but I'm > using it in a context that requires TLS (e.g., HTTPS), and the thing that I > connect to when I use the record can present a cert that proves its identity, > is that okay?
I think perhaps the people who have been having these conversations are not being ambitious enough. The pressures in the enterprise DNS market are overwhelmingly driven by the need to make web apps more reliable, load faster, and offer user-specific content. There are other reasons to want DNS tricks, but the customers that pay the big money are all concerned with HTTPS UX. Some of the decision points are in the DNS and some are in HTTP. The DNS is overwhelmingly involved at UX session initiation, but after that the HTTP layer has (can have) a far richer set of data about the user and is able to separate user-blocking decision-making from the flow of the UX which also affords extra time to make decisions without the user becoming frustrated. [To illustrate the architectural lunacy of the status quo, consider the data sets that are gathered through real-user-monitoring in browsers, served at the HTTP layer, that are subsequently used to steer DNS traffic used to retrieve resources back at the HTTP layer. There's a whole layer of derived datasets relating to the DNS there that are being generated by the web and used by the web, but with a tangy sandwich filler of DNS that is just overhead.] It seems like it would be nice then, after the UX-blocking elements are loaded and the user is already engaged, for subsequent lookups to be driven in HTTP and client-side scripting and to be presented to the stack as bare addresses rather than DNS names. That avoids the dependency on the DNS after initial page load altogether and leaves all the performance engineering decisions in the same place as the content decisions. There are problems with this approach today (certificate matching, for example) but I don't think the problems necessarily relate to the DNS. Perhaps they relate to a local-context naming system that doesn't exist outside a javascript sandbox. I see the attraction of shifting name resolution to DOH since it makes it look like everything is a web app, but collapsing the address selection back to the extent that you can avoid name resolution at all seems like a better end goal. So rather than resolverless operation, think about resolutionless or nameless, eliminating the DNS as unnecessary overhead. Perhaps I have misunderstood the whole problem space, of course :-) Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
