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

Joe Abley <jabley@hopcount.ca> Tue, 10 July 2018 16:34 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BAD131120 for <dnsop@ietfa.amsl.com>; Tue, 10 Jul 2018 09:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 017gNN7tzVcu for <dnsop@ietfa.amsl.com>; Tue, 10 Jul 2018 09:34:44 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 128F4131016 for <dnsop@ietf.org>; Tue, 10 Jul 2018 09:34:41 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id t21-v6so17221326lji.0 for <dnsop@ietf.org>; Tue, 10 Jul 2018 09:34:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=RhOwDeizS2p1sDwMvQJpECvp62XALlw/l7BD48f8O0Q=; b=IyH9v9MEpD3onkQOraCj1qlObMwPrP4rA3G0nIFK5gpGgsOfkOUvMGU8njqdifHky/ 8NT14mdS//rC2adaxFv+A4yWyWfhfWrgAUKtSpeZTpuTsIPIhpeEpJVcK2/j7W+8o2RH Whp9rf5a9MlCekbQJGxQV7Y3GcJBqOuQVVA5E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=RhOwDeizS2p1sDwMvQJpECvp62XALlw/l7BD48f8O0Q=; b=KAHLpsLCczQ5R44Qyw9v+OEPeH2H5Z465FwRqIANmEcJPWJW/iwXu5cW5407XMSy9/ 53JFch7xMmr11RoQfkNBUBHCvhd3f5hhmQlCz0TjUSXgGpq1hyPpvIJrT+9Wushc4qKE lLBnNIR9wmPn4ApmRfuEIIL5LEgooRCV+IiqTIKnV73U69Movwxzr240NPPf7iFSSNqG dUS0hSFpT3N6Eu6s2m78CCdFQNtp0XIMN/wLfhGM1TrU73Di2El6HEGNZ79V+GwbXUqe 1GfTgo6yHzqT/Sw59uzxCtPdkTYm+3O/rzC3wNAT763cvrUBPYbHjoRc/ljkzSPaz006 HCxQ==
X-Gm-Message-State: APt69E1dQSauOlzUWHaUb4b62mybQznTldmjwbsuxCJSZ+w16COkuAgY 2j1P/v4dwP0mtIcdWZm47Pph5qnS+PPRFMtOKfWswQ==
X-Google-Smtp-Source: AAOMgper5iC5ciWT5QSOvbIfNf6C6wptrj2+IxkwIumOQxfjmkMTjaAHuYnX5/TaPLQ3dJmbX3RViLPifzrbV9roP5Q=
X-Received: by 2002:a2e:7815:: with SMTP id t21-v6mr9092751ljc.61.1531240479262; Tue, 10 Jul 2018 09:34:39 -0700 (PDT)
Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 10 Jul 2018 09:34:38 -0700
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
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>
In-Reply-To: <e1675184-f0bc-670d-3db1-b99a9daf1657@nostrum.com>
Date: Tue, 10 Jul 2018 09:34:38 -0700
Message-ID: <CAJhMdTOZtOpF_aK-ZzP0DfkDMcAtTKFLdSpKkrSPvP1cOgnOjQ@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UZhkcOMaPhOs2zCqsXx2JTl6iEo>
Subject: Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2018 16:34:49 -0000

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.

> 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;

Likewise. However, I think DNS protocol advice is probably more useful
as input to the analysis if it's clear that the DNS is necessarily
involved.


Joe