Re: [DNSOP] SVCB without A/AAAA records at the service name

Martin Thomson <mt@lowentropy.net> Wed, 20 January 2021 00:40 UTC

Return-Path: <mt@lowentropy.net>
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 BA0EB3A0AC4 for <dnsop@ietfa.amsl.com>; Tue, 19 Jan 2021 16:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=j/aSX8OF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IHdL0+0X
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 hEETQn4Z9LBC for <dnsop@ietfa.amsl.com>; Tue, 19 Jan 2021 16:40:52 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E863C3A0A63 for <dnsop@ietf.org>; Tue, 19 Jan 2021 16:40:52 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B7781161A; Tue, 19 Jan 2021 19:40:51 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 19 Jan 2021 19:40:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=AE4Is2nnmRj/lwouqvaA333IYEKb foZ7w49/IKWVNFU=; b=j/aSX8OFNdEr3mZanjsfKVjefFS6voTwZ44phcr/HHFc 26OwHHJiZa+ACGBJnYanZRsXNKJHSKJeUmdwpPmTAGKTSzx6jl+s1XH5DIWH5SPW wWYb7dJP8rxuAG7PaV9dKiM8P4G2IftTksCClyA4LFx7LWJXD7g8T0As5/mdRk2s aRgBYU0mUUwJc6nG1jvSUCWjhS9JUcUB6oBQDS3MBDpMnjmwNUOhhtQxAjFWBZ2A ybe3rzulslmixBNzVBLzbE3vLEvnc7+YuFTrGd+WSa487ZBvFN4+WUNR8IUrpB2P zgAsBEyONOy520z13lKkkNvehT4Mk71R9PuB326hFg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=AE4Is2 nnmRj/lwouqvaA333IYEKbfoZ7w49/IKWVNFU=; b=IHdL0+0XWCjCD8GHu3eLbx Bmg2JKHAcwUP0rml7qdv8wauzhVAu8xfi0ol+jVD2vOsn/R58P0YmMvkVWVbP3r4 rYsRMLT4Fmtu4D5C1twGYs6ERFAnwqYq04ZBCBa4FuqpbFjDvdvtURxZidk6Zoym 1uisTp+ZQ5miV0L0yi1KFiIIg12/SV62BMu5mUtuGOi9TkktWMm/6vbApmmf+h3t 5W5zHnIIYbPwt97RNHOIjly/7jzJM/+FYlOAxEitivfJb7U6dr9hoqNkbjtUygCc wPw9fDDv7+0qNkCXPoYqYSl8PUkJwbujjHOyTwrHaw1fYB21vDl51ST36cc4g6eA ==
X-ME-Sender: <xms:EnwHYL4JlBcmWLF5x14JB6zcV7JUW2PKX-NHKCIPMVRDGif7I5PEFw> <xme:EnwHYA725hET-TSkkd1KeUrtV6S3hp47uUZ9C6sF2aW6ex0YRPIMNATbZ89JHM1_j qBWCXi6-n-Of30yggs>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddugddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:E3wHYCewrxALRFGd3yX-Wg38Iq7E-t5tZsWkPA-e_vyYDdzdQjbB9A> <xmx:E3wHYMJ26G3wYlm2g2CEU7UOPKahwBym1MxYIy1EsLDMos5YxgHkmQ> <xmx:E3wHYPKgyJlcEh-RK3fz5TUzFcH6rthpgCYTFtxj8NpdNMCirimsRg> <xmx:E3wHYKmcYnOpWytUIRMPK9rX2Omc3tFARtJUO33raQpNc-9H9WQgVw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id EAC094E005D; Tue, 19 Jan 2021 19:40:50 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-45-g48392560e8-fm-20210104.001-g48392560
Mime-Version: 1.0
Message-Id: <4b59e60b-f8b0-493b-97b2-210d5541a19d@www.fastmail.com>
In-Reply-To: <CAHbrMsDFuKNMrvi03VjK_eSio5N1w6eAtRpOMx3NdSYu-f_5Yg@mail.gmail.com>
References: <2e1054a0-5a7a-4d62-92a1-095217af82bb@www.fastmail.com> <CAHbrMsCaVER+xDjznjRK4cSjqc+g855GNV2QCfewvCqh=E1FMw@mail.gmail.com> <87098be5-765c-4481-b990-bdb2c936173d@www.fastmail.com> <CAHbrMsCu1bYcEuT2R3g5M9aUBQguVeWhiyZpDH=JzSEPpc=iqg@mail.gmail.com> <45895deb-7432-4ad7-bede-107bf6e1973e@www.fastmail.com> <CAHbrMsDFuKNMrvi03VjK_eSio5N1w6eAtRpOMx3NdSYu-f_5Yg@mail.gmail.com>
Date: Wed, 20 Jan 2021 11:40:31 +1100
From: "Martin Thomson" <mt@lowentropy.net>
To: "Ben Schwartz" <bemasc@google.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3v9eCT2WwPXwq-7MvQJfyGSMHlA>
Subject: Re: [DNSOP] SVCB without A/AAAA records at the service name
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 20 Jan 2021 00:40:55 -0000

On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote:
> As I noted in that discussion, the client generally doesn't know in 
> advance that they aren't needed.  

I am asserting that the client very much knows.  Indeed, it has to know.  If we define a new protocol that relies on SVCB and that protocol is able to use SVCB exclusively (which would be a good thing in my view, all this parallel DNS querying is unnecessary, even if the DNS protocol is pretty good at it), then a client can very much know.

> Another thing I like about the arrangement in #288 is that it 
> simplifies a protocol-independent app/library boundary.  The app can 
> say "SVCBQuery(hostname, prefixes)" and get back a fully resolved 
> object like {svcbEntries: [{...}, ...], hostIPs: [...]}.  

I'm suggesting that the interface might be a little wider.  If the interface is provided with a scheme, them the library might be able to lookup the scheme and know whether A/AAAA is needed, but it might be better to have a very different interface for those protocols that might need fallback as opposed to those that don't.

A protocol might genuinely need SVCB.  If additional SVCB information is critical to the operation of the protocol (think ECH here, but there might be other reasons for this), then the API might look like (eliding the attr-leaf and prefixing stuff):

svcb.query(name) -> svcbEntry[] // where the API fills in an address (or addresses) for each svcbEntry

This is far more ergonomic for something that doesn't care about A/AAAA.  And less wasteful.  If a fallback is possible, then you get something very different, which requires additional logic to handle:

svcb.query_with_fallback(name) -> Either<svcbEntry[], address[]>