Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal

On 7/10/18 10:30 AM, Joe Abley wrote:
> On Jul 10, 2018, at 16:09, Adam Roach <adam@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.

Basically, you're describing a solution space that could be realized as 
something like:

<img src="https://example.com/img/f.jpg" ip="192.0.2.1">

But this is really equivalent in just about every important way to 
sending the normal <img src="https://example.com/img/f.jpg"> along with 
a pushed DNS record that indicates that "example.com" resolves to 
"192.0.2.1" -- and this latter thing is (to my understanding, at least) 
in scope of the conversation that Patrick is proposing to have.

Note: I'm not saying anything about the trust issues that arise in 
either case, and I'm not trying to gloss over the need to perform a 
really careful analysis; I'm just saying that what you're suggesting is 
definitely equivalent to one of the implied eventual outcomes of what is 
being proposed.

/a

Received on Tuesday, 10 July 2018 16:23:29 UTC