Re: [DNSOP] SVCB and the specialness of _

Tommy Pauly <tpauly@apple.com> Wed, 07 October 2020 13:23 UTC

Return-Path: <tpauly@apple.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 426583A09D7; Wed, 7 Oct 2020 06:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.297
X-Spam-Level:
X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=apple.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 ZZJ45_iOdeUE; Wed, 7 Oct 2020 06:23:41 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C793A0962; Wed, 7 Oct 2020 06:23:41 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 097DI4aQ056976; Wed, 7 Oct 2020 06:23:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=GolIPLegGSJnxVQOU3iaNlVdJGm26xRlXCs1/MmTdDg=; b=KSCfVnYKHcdd50TBe88xy+HgZBIxHXyrtAWd3i+TKLlQ7L5xfg3rMudtyOnt3rhvP25r LfoqtSHY6QP0FN3D4DJtSOpri8Civ/1vnEuKusFbdBdOo0rHKoYRuqGADZqCfLa+l39d IJDppjSSPBlwzZBtlEXmjpoG91Xm56lKVxzPRI+NB13IR0KOTjUZzG4OcKt7GPUy6pI2 l0qErbmoUttE0/P+pL/Gqd2TNJTe1DBD0NWUvhiwS5Ksscx/UcAm2I9frAIZ0HV+tAhX RkYGATx5V1QBEA8ztPEPDt944lJSm85+8mnmMM8MrSs1mf/NCqBHix/lXmHulceL8QsM GQ==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 33xqy2b675-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 07 Oct 2020 06:23:40 -0700
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QHU00E3K2JBW270@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 07 Oct 2020 06:23:35 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QHU00A002DUZR00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 07 Oct 2020 06:23:35 -0700 (PDT)
X-Va-A:
X-Va-T-CD: e72da815dcb01dab2f988f94f1719970
X-Va-E-CD: ce91707defd30c40d543c0bf2f023518
X-Va-R-CD: fd5d03022bb8351903aca9e245651bf1
X-Va-CD: 0
X-Va-ID: 8af1a2cd-59a3-4179-9591-c039ee5581be
X-V-A:
X-V-T-CD: e72da815dcb01dab2f988f94f1719970
X-V-E-CD: ce91707defd30c40d543c0bf2f023518
X-V-R-CD: fd5d03022bb8351903aca9e245651bf1
X-V-CD: 0
X-V-ID: 3eb05c68-6cb6-4549-b2ab-0e6ae04951eb
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-07_08:2020-10-06, 2020-10-07 signatures=0
Received: from localhost.localdomain (unknown [17.234.7.156]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QHU00XFS2HPRP00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 07 Oct 2020 06:23:34 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <282240ED-43EB-4A62-A1D3-BBB5E92ADE17@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_27C61260-7C5E-4586-820D-503C1FEE8DF0"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\))
Date: Wed, 07 Oct 2020 06:23:34 -0700
In-reply-to: <CAHbrMsCLy8jERObtJU6XNQd2ef0U9sQbPMriHAGx=n513Dgx1g@mail.gmail.com>
Cc: dnsop <dnsop@ietf.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
References: <CAHbrMsCLy8jERObtJU6XNQd2ef0U9sQbPMriHAGx=n513Dgx1g@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.0.3.2.26)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-07_08:2020-10-06, 2020-10-07 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5mxeMgTvwT0jBvorzG3Y5PwT14U>
Subject: Re: [DNSOP] SVCB and the specialness of _
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, 07 Oct 2020 13:23:43 -0000

This change seems reasonable, and makes “.” still more useful for the generic SVCB case.

Thanks,
Tommy

> On Oct 6, 2020, at 4:51 PM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> Hi DNSOP,
> 
> There was recently an interesting proposal [1] for a change to the SVCB draft that seems to merit input from the working group.
> 
> Background:
> When using SVCB, clients append an underscore prefix ("Attrleaf") to the name, containing the "scheme".  When there is an actual URI involved this will literally be the URI scheme, e.g. _ftp.ftp.example.net <http://ftp.ftp.example.net/>.  Schemes can prepend additional underscore-prefix labels to encode scheme-specific service identifiers; the only anticipated use for this is a port number (e.g. _8080._https.www.example.com <http://https.www.example.com/>).
> 
> SVCB also contains a small optimization: In ServiceMode, if the TargetName is ".", this means "use the address records for the owner name".  This reduces packet size (since name compression is not possible in new RR types), but more importantly, it makes zone file editing easier and guides zone owners toward the "happy path", where there is no latency penalty because the resolver has already requested the corresponding address records.
> 
> This construction works well for HTTPS on port 443, and for any lookup following an AliasMode record, because in those cases the SVCB/HTTPS, A, and AAAA queries all share the same QNAME.  However, it does not work when the initial query has underscore labels and returns a ServiceMode record, because the ServiceMode record's name is not the hostname (due to the underscore labels).
> 
> Proposal:
> The proposal would change the meaning of "." from "Use the SVCB record's owner name" to "Use the SVCB record's owner name *minus any leading underscore labels*".
> 
> Pro: TargetName = "." would now coincide with the "happy path" in all ordinary cases.
> * Simpler guidance to zone owners (always prefer ".")
> * Clearer design rationale ("." is where the address queries already went)
> * Shorter RDATA in the "happy path" case (for some non-HTTPS uses)
> 
> Con:
> * Servers (recursive and authoritative) that perform Additional Section processing would have to implement this underscore-label stripping procedure.  This would be a rare violation of DNS's usual abstraction barrier (servers don't normally discriminate based on the format of labels).
> * There could be a change of operational control (e.g. zone cut or CNAME) between _port._scheme.$HOSTNAME and $HOSTNAME, in which case the ServiceMode record might actually prefer to use address records at its own name, despite the latency cost.
> * This gets very tricky if an AliasMode or CNAME target contains underscore prefixes.  It may be impossible to stay on the "happy path" in all these cases.
> 
> [1] https://github.com/MikeBishop/dns-alt-svc/issues/252 <https://github.com/MikeBishop/dns-alt-svc/issues/252>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop