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

Adam Roach <adam@nostrum.com> Tue, 10 July 2018 17:03 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: driu@ietfa.amsl.com
Delivered-To: driu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39B813114C; Tue, 10 Jul 2018 10:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtihJTA2fqCQ; Tue, 10 Jul 2018 10:03:24 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FD8131142; Tue, 10 Jul 2018 10:03:23 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AH2tmL004330 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 12:02:56 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
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>
References: <m1fcoe5-0000GuC@stereo.hq.phicoh.net> <alpine.LRH.2.21.1807101056140.5219@bofh.nohats.ca> <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <e1675184-f0bc-670d-3db1-b99a9daf1657@nostrum.com> <CAJhMdTOZtOpF_aK-ZzP0DfkDMcAtTKFLdSpKkrSPvP1cOgnOjQ@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <e658445a-242b-5f94-f1fc-0bc4c850319d@nostrum.com>
Date: Tue, 10 Jul 2018 12:02:55 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <CAJhMdTOZtOpF_aK-ZzP0DfkDMcAtTKFLdSpKkrSPvP1cOgnOjQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/qL1kCPvs-qAthwPfpoNsdecB0IA>
Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal
X-BeenThere: driu@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <driu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/driu>, <mailto:driu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/driu/>
List-Post: <mailto:driu@ietf.org>
List-Help: <mailto:driu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/driu>, <mailto:driu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2018 17:03:26 -0000

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