[DNSOP] unsolicited HTTPSSVC responses

Eric Orth <ericorth@google.com> Tue, 26 May 2020 19:43 UTC

Return-Path: <ericorth@google.com>
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 34C843A0F86 for <dnsop@ietfa.amsl.com>; Tue, 26 May 2020 12:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 xZfenH3ibYN5 for <dnsop@ietfa.amsl.com>; Tue, 26 May 2020 12:43:41 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 C131B3A0F85 for <dnsop@ietf.org>; Tue, 26 May 2020 12:43:40 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id q11so9527920wrp.3 for <dnsop@ietf.org>; Tue, 26 May 2020 12:43:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=t2zPbXOf7zhBnr3Js3qWazvOxjlqnIbh1OLWCuymAe0=; b=MRxv+ATvIu41vhEE+NpwB1VOq/Okr6TqqZqORHkHQQQrjmCENx+9MwAKXQu0GRIZqX lfgntz77VKD2q9hAZIONZK3/WLtKlrjzOJq/I9ssL+MQ71zw1juBlK2s81DbReeZBOwp vBXsDuB5OkDhC/2LeJUeru7iJSkZwLIVVepwvKTq8gNNOtZit6uo02GO7kbnh9oZ15aD jFgktRNPX/qoQYfHcxLFRmJKVpHmGk9sNo7n8B+s/rE2h1pEPc2xHPFbyzvab6SuP4PX qdc7XlSgG7oaLKCHRGA/tUHR5K5vayZ06vexDLbDAli1FQJTycgjQwq17Z/ikS78BVgY cxJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=t2zPbXOf7zhBnr3Js3qWazvOxjlqnIbh1OLWCuymAe0=; b=Y9dIIlpjqDNQ57Tfb5qfyZ2bp1JbK38GNwf1dSMuyDmHyQ/6b5m5Q3pDyyrsPHP8b9 sKcC5mBGIWEagzHeaBmXvXeab7qGNv5AAZHP5YiLxhEAzSxEtmXJBIMkxY9a5VFtwv5V V6KhpYtzAu+qyt/Dwu5sWSjy47VIJi9PXOmaGRm+fUygG+Fm0FggxPVRSS8hQj5uYOiD xfS79vIdoyPHsT1ui1tDGg+GraZRG95srFSw3aDg0CwhgrLh6Qaz3DEgEzWVKRY522rj jTSuk+KSL9sgKXSdnr/zkb7pD1T/fC2nbbP/m7EOWWsE+gdHzKVZXzFdIFaxzZuc6Gw9 YwsA==
X-Gm-Message-State: AOAM533bl5XFG4glHRNCpfM6/Fd2h0j7PQILqjaQqcoe7ohvq3KEHGUv Wkkdqc240CoNUiQFo1ZQCA2tW5i49BXxQD9Ye4PTttgp
X-Google-Smtp-Source: ABdhPJxbgADxl3LNp+Vkh24iSHEEDescdzqxYdrkYdr5lWjZ4oqdU1MCOs/wRFr7+fGpuv8eebGUXysi1+GATpXP4Ug=
X-Received: by 2002:adf:ab4e:: with SMTP id r14mr10645684wrc.147.1590522218666; Tue, 26 May 2020 12:43:38 -0700 (PDT)
MIME-Version: 1.0
From: Eric Orth <ericorth@google.com>
Date: Tue, 26 May 2020 15:43:27 -0400
Message-ID: <CAMOjQcHAKC6ge2te8eqPz3JFmmLrpBoTSt2yKKxFXHpQEyjLqg@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000da7dd305a6924fa8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DFHTdDiJqphi6qPPIQEHEJ6Dd7Y>
Subject: [DNSOP] unsolicited HTTPSSVC responses
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: Tue, 26 May 2020 19:43:42 -0000

One of my colleagues recently brought up the idea of suggesting recursives
add additional HTTPSSVC records into responses for A/AAAA queries as a way
to make HTTPSSVC more available for cases where a stub is hesitant to make
additional queries out of concern for bad behavior from bad middleboxes (a
frequent concern for Chrome when not using DoH).  My initial impression is
that it's not a reasonable idea, but I wanted to bring it here to DNSOP in
case anybody has further ideas to make it workable.  So any relevant
thoughts or concerns from anybody here?

The obvious problems I could think of (all basically along the theme of it
not being ideal when the stub might not even care about HTTPSSVC):

   - Performance implications if the recursive has to retrieve HTTPSSVC or
   follow alias chains.  Maybe not as bad if only done opportunistically when
   the recursive happens to already have everything in cache.
   - Polluting DNS for non-browsers.  Maybe not as bad if SVCB instead of
   HTTPSSVC, but this would likely only be of use for web browsers which are
   obviously not the only queryers of A/AAAA.
   - Could lead to lots of unnecessary truncation, especially for large
   records containing ESNI data.