On 7/10/18 10:30 AM, Joe Abley wrote:
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.
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
![https://example.com/img/f.jpg"](https://example.com/img/f.jpg"){kind=link}