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

Joe Abley <> Tue, 10 July 2018 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9633D13101B for <>; Tue, 10 Jul 2018 09:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yvAeiDwy-3lB for <>; Tue, 10 Jul 2018 09:34:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF672131010 for <>; Tue, 10 Jul 2018 09:34:40 -0700 (PDT)
Received: by with SMTP id 1-v6so17183637ljv.9 for <>; Tue, 10 Jul 2018 09:34:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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=UvbG8/DTcm7f0SQ7AkONArqy2ilVHXTGFyR7cp2N8L2wSQBcQWeoCE0/m/4520PfJN fyFr6EIIUaKg6NfFpHWYKx3WXs8v19/yooxLl0jiuEwyknH6YGGNDPSqknyygu2Lom5v hoH2jvhtVXV0Zbfh8lI+3SbdeK3i+TCaZYVghIoczjlEI8BJlC75zePKOjq7qW53RuFU APc+Q3qMDXZxf0aHQOeK5uoIeAdCjiuOrYJtpajhu0m4qwfCj3Rl9L/9DnaxCSyRbmUq OK0BWCsxbI5U4NSQL2v1Bh3nNz7jQ3m0U0YVi6cm3NQ3Eq5PepbhdEhjKKZVVQTCI1wR BeCA==
X-Gm-Message-State: APt69E111Z5yaABKB2AvtD79fnqs3p6qzUYqIwXyJy8BroDygGSDTekj ltPAf2gJv1XVSPd5CY+ervZT8vnyz6ne2EIMGyyDYQ==
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 with HTTPREST; Tue, 10 Jul 2018 09:34:38 -0700
From: Joe Abley <>
Mime-Version: 1.0 (1.0)
References: <> <> <> <> <>
In-Reply-To: <>
Date: Tue, 10 Jul 2018 09:34:38 -0700
Message-ID: <>
To: Adam Roach <>
Cc: DoH WG <>,, Philip Homburg <>,, Patrick McManus <>, Paul Wouters <>, HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jul 2018 16:34:44 -0000

On Jul 10, 2018, at 17:22, Adam Roach <> wrote:

> Basically, you're describing a solution space that could be realized as something like:
> <img src="" ip="">

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=""> along with a pushed DNS record that indicates that "" resolves to "" -- 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