Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS
Ben Schwartz <bemasc@google.com> Thu, 23 July 2020 14:32 UTC
Return-Path: <bemasc@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 2741B3A07B8 for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 07:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 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, URIBL_BLOCKED=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 52XiSVaAPRqz for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 07:32:07 -0700 (PDT)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 F113D3A07CE for <dnsop@ietf.org>; Thu, 23 Jul 2020 07:32:06 -0700 (PDT)
Received: by mail-yb1-xb34.google.com with SMTP id l19so2949603ybl.1 for <dnsop@ietf.org>; Thu, 23 Jul 2020 07:32:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JMZm+HB48ZiXjXW+bzgiITFCj97n1ckaZmyXuQoheQY=; b=Huv8TNWQ6o6y+Rt+5XvpAX08w7OVl5xEXbNqsvApQcWWcQiYLyjufAx3t6xXOZGtqi f5sqV2XuW/C15jcMQrxW+f8EwDsEB1kZToILgw95ydLB70ju0UrwXWzlyCSvl74xgi02 ERD+HUP66d7zJexm4TDJaZl5Or+vmsQQsx2n4V4nJIeYiu/7htA0BjxwrHT2vcoy57GO +r6LMVEA7hzdWMpDtuNA8t5ge651O8MV1HQcig+XFgeSTU3OFgSCMC1+NQR0NG4DFYsI ruYeoJqDhRLbQtjYDK2Q4gUyEsMeUnkq8sxrPrxvXnuBvmvBw+9xONGIpJ+U86pyVDM4 z2kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JMZm+HB48ZiXjXW+bzgiITFCj97n1ckaZmyXuQoheQY=; b=evwTirl9opJU/0YPNUCmEdlLJKCPOuZMrGOMJIIOT+Epdyf1vGUFTLqWl3Mx0KjS5b irHoQRmhcbWS2yV9Fb4d3mjw6IWr+18rAoQap1V3Lr3tKW3TKFVScxWD4sIUm+aQyB9q EMVcfhW29YRqRqhOy0r752NEIhm6Ac5JQU3x5LvQ4YjDa8o+/Tb4IEkTp0sQpYa+Lj/f eWbDw+IX0Sorj+HnvaHkkJZgtxgcAliJVbI21YijIFY6tdOrzE+1lx++mJxWP5S3Rny5 G/XfvG5ClX0Q3RJzCDLELRUAxo6gf0fTou55z7PrxqrZPI4HFvNbwt5zM8HhJUVK0LHG Z2dQ==
X-Gm-Message-State: AOAM530Kz6yj1KeZCq1ZT7LFB4xAs6yKntCYyEzlJ0jRC5HpPKfXd0AI rw2siN2AhNOl4cD2guhYYkj1GOQGBXqGt6FN+gPOQQ==
X-Google-Smtp-Source: ABdhPJwDZyuy7vjSnBY6y9TsuCBO9jjuMHwyKFKokGrKOAurplWGITs38A1nfqN3q3s8mG7yKWopP2hTIEAtZVd695s=
X-Received: by 2002:a25:41d3:: with SMTP id o202mr7640859yba.236.1595514725572; Thu, 23 Jul 2020 07:32:05 -0700 (PDT)
MIME-Version: 1.0
References: <20200716151356.GA60024@wakko.flat11.house> <18174930-D601-462A-BB4E-E994DB2EB4B9@isc.org> <20200716172604.GA65961@wakko.flat11.house> <E80B5A6A-9EB1-497B-81C1-2FA67012FAD3@isc.org> <20200723095040.GA1524@wakko.flat11.house> <20200723095729.GB1524@wakko.flat11.house>
In-Reply-To: <20200723095729.GB1524@wakko.flat11.house>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 23 Jul 2020 10:31:50 -0400
Message-ID: <CAHbrMsBRHoUAWo9khN_kJL-jNa9H1TWb-YqqYNanhCJ_Jb2s0w@mail.gmail.com>
To: Alessandro Ghedini <alessandro@ghedini.me>
Cc: Mark Andrews <marka@isc.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000007d1e7105ab1cb831"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4kiKCO4kZBjZfIYxq-lrflHLvf8>
Subject: Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS
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: Thu, 23 Jul 2020 14:32:09 -0000
On Thu, Jul 23, 2020 at 5:57 AM Alessandro Ghedini <alessandro@ghedini.me> wrote: > > Also btw, currently we always include ipv4hint and ipv6hint in our HTTPS > responses, this is to avoid breaking connections in multi-CDN scenarios, Note that this is not guaranteed to work. A client who has the other CDN's AAAA record in cache will ignore your ipv6hint, leading to ECH failure. The proper way to support this is to make sure that TargetName is never a multi-CDN name. The advice in previous drafts was arguably confusing on this point. The latest draft updates the "Structuring Zones for Performance" section in an attempt to clarify: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-5.3 so I > guess a resolver could in theory use this information instead? The draft > is, I > believe, a tad too strict regarding the usage of hints, so I'm not sure if > this > is forbidden or not. > I'm not sure what you're proposing, but recursive resolvers are certainly forbidden from synthesizing address records based on the ipv*hints. However, the ipv*hints do allow clients to connect without waiting for followup queries if they don't get address records in the Additional section, which should address the performance question in this case. Cheers > > > > > Cheers > > > > > We need to get to the state where HTTPS/SVBC alias form always reaches > a HTTPS/SVBC > > > service form. When we are mostly in that state we can stop doing A > and AAAA queries > > > along side the HTTPS/SVBC query for names in the HTTPS/SVBC alias form > and take the > > > RTT hit on the occasional NODATA response. To get to that state we > need the DNS > > > servers of the content providers to be HTTPS/SVBC aware and to > populate the additional > > > section whenever possible. > > > > > > BIND’s HTTPS/SVBC implementation adds A, AAAA, CNAME, and HTTPS/SVBC > records and > > > looks for them in the response. I would expect all HTTPS/SVBC aware > clients to > > > look for these records in the response. At the moment we don’t look > for DNAME in > > > the additional section nor do we add it because, quite frankly, they > should not be > > > there in any sensible deployment. DNAME in the answer section is > expected. > > > > > > Mark > > > > > > >>> On 17 Jul 2020, at 01:13, Alessandro Ghedini < > alessandro@ghedini.me> wrote: > > > >>> > > > >>> Hello, > > > >>> > > > >>> Just a quick note that we have started serving "HTTPS" DNS records > from > > > >>> Cloudflare's authoritative DNS servers. Our main use-case right > now is > > > >>> advertising HTTP/3 support for those customers that enabled that > feature (in > > > >>> addition to using Alt-Svc HTTP headers). > > > >>> > > > >>> If anyone is interested in trying this out you can query pretty > much all domains > > > >>> served by Cloudflare DNS for which we terminate HTTP. > > > >>> > > > >>> For example: > > > >>> > > > >>> % dig blog.cloudflare.com type65 > > > >>> > > > >>> ; <<>> DiG 9.16.4-Debian <<>> blog.cloudflare.com type65 > > > >>> ;; global options: +cmd > > > >>> ;; Got answer: > > > >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17291 > > > >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: > 1 > > > >>> > > > >>> ;; OPT PSEUDOSECTION: > > > >>> ; EDNS: version: 0, flags:; udp: 4096 > > > >>> ;; QUESTION SECTION: > > > >>> ;blog.cloudflare.com. IN TYPE65 > > > >>> > > > >>> ;; ANSWER SECTION: > > > >>> blog.cloudflare.com. 300 IN TYPE65 \# 76 > 000100000100150568332D32390568332D32380568332D3237026832 > 0004000868121A2E68121B2E00060020260647000000000000000000 > 68121A2E26064700000000000000000068121B2E > > > >>> > > > >>> Cheers > > > >>> > > > >>> _______________________________________________ > > > >>> DNSOP mailing list > > > >>> DNSOP@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/dnsop > > > >> > > > >> -- > > > >> Mark Andrews, ISC > > > >> 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > >> PHONE: +61 2 9871 4742 <+61%202%209871%204742> > INTERNET: marka@isc.org > > > >> > > > > > > -- > > > Mark Andrews, ISC > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > > PHONE: +61 2 9871 4742 <+61%202%209871%204742> INTERNET: > marka@isc.org > > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
- [DNSOP] HTTPS/SVCB on Cloudflare DNS Alessandro Ghedini
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Mark Andrews
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Alessandro Ghedini
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Mark Andrews
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Tim Wicinski
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Wellington, Brian
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Tommy Pauly
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Mark Andrews
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Wellington, Brian
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Tim Wicinski
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Ben Schwartz
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Mark Andrews
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Wellington, Brian
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Mark Andrews
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Mark Andrews
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Wellington, Brian
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Petr Špaček
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Mark Andrews
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Dick Franks
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Brian Dickson
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Alessandro Ghedini
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Alessandro Ghedini
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Alessandro Ghedini
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Jared Mauch
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Ben Schwartz
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Ben Schwartz
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Mark Andrews
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Alessandro Ghedini
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Alessandro Ghedini
- Re: [DNSOP] HTTPS/SVCB on Cloudflare DNS Mark Andrews