- From: Adam Roach <adam@nostrum.com>
- Date: Tue, 10 Jul 2018 12:02:55 -0500
- To: Joe Abley <jabley@hopcount.ca>
- Cc: DoH WG <doh@ietf.org>, driu@ietf.org, Philip Homburg <pch-dnsop-3@u-1.phicoh.com>, dnsop@ietf.org, Patrick McManus <pmcmanus@mozilla.com>, Paul Wouters <paul@nohats.ca>, HTTP Working Group <ietf-http-wg@w3.org>
On 7/10/18 11:34 AM, Joe Abley wrote: > On Jul 10, 2018, at 17:22, Adam Roach <adam@nostrum.com> wrote: > >> 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"> > Ok, interesting. I would suggest considering a richer scheme that > accommodates address families and multiple addresses with priorities, > but I see how that kind of thing would allow a client to do so > certificate matching and resource retrieval without using the DNS. > >> 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. > My question is why you would involve the DNS at all if all the > performance-based resolution decisions can be made without it. You're > just adding cost and complexity without benefit. In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities". /a
Received on Tuesday, 10 July 2018 17:03:23 UTC