Re: [DNSOP] SVCB and the specialness of _

Tommy Pauly <tpauly@apple.com> Wed, 07 October 2020 21:11 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 86FA63A13CE for <dnsop@ietfa.amsl.com>; Wed, 7 Oct 2020 14:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.3
X-Spam-Level:
X-Spam-Status: No, score=-3.3 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 9ujjSvMIT_3m for <dnsop@ietfa.amsl.com>; Wed, 7 Oct 2020 14:11:16 -0700 (PDT)
Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 02ECC3A13CC for <dnsop@ietf.org>; Wed, 7 Oct 2020 14:11:15 -0700 (PDT)
Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.43/8.16.0.42) with SMTP id 097L5vsC016028; Wed, 7 Oct 2020 14:11:13 -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=j+DDuIBDKYtuiayRYtD1A7uPlb43VXR8s7aTN7QlIPc=; b=sjlInjTAp6/v4uME/lkDYIpzOyi0+1KxEz2kDvYrZkGgZyu+2azKf6deQHH6vczwwXjZ TfZp23yVPNbF6CClE65CEWFBhfpn6c+38MeAeT9Txnoqft7Z+AdFcylG9a3hza00avSS YJPHp+Fk/2/vQBnM2BPsaDLC4UQedw2uk+7nfADzOYKmCxwj4FjdG0JViNgTEnLkDior vRSJktAcv4f80573eQQ37UFl2PuqJDOiNfKSWHiDxnXxA+aIes31lNQ8bTfPI9zTwQnK /CfsE+6xtUGFfwfmoXILI1++KY5QW7g+sn/sliOag3I+BYb+m8eQI9+Uo1gRrFZ3ul5i 7w==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp01.apple.com with ESMTP id 33xr815074-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 07 Oct 2020 14:11:13 -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-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QHU00HAPO6NK8D0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 07 Oct 2020 14:11:12 -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 <0QHU00D00O5NHS00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 07 Oct 2020 14:11:11 -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: 4031b3ab-a0fc-436d-8f5b-72db04b3e0c1
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: e975154c-35ca-4ab0-8758-4ac45ffdd786
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-07_10:2020-10-07, 2020-10-07 signatures=0
Received: from localhost.localdomain (unknown [17.234.30.129]) 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 <0QHU00F02O6LEN00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 07 Oct 2020 14:11:11 -0700 (PDT)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <463ECEDF-C14C-4970-AC7C-BD67DE4FF215@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_9A5F4856-4534-457C-ABC5-CA4D1A13B5EB"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.26\))
Date: Wed, 07 Oct 2020 14:11:08 -0700
In-reply-to: <CAHbrMsAfePUP+V7Ta5DV+rsSUuzso-zg=TenGrQ+nG72+OF_mA@mail.gmail.com>
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, dnsop <dnsop@ietf.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
References: <CAHbrMsCLy8jERObtJU6XNQd2ef0U9sQbPMriHAGx=n513Dgx1g@mail.gmail.com> <CAH1iCirmkES-T9LhZnm-gGAmLshso6GvDpNawqVYQwTEF9HiCw@mail.gmail.com> <CAHbrMsANeW1hCV+Te9j1qd13qrn1n6wW4QYfGE=FuezNw7z+Xw@mail.gmail.com> <CAH1iCiqO6ezfxXRUM92f9BaeXP6wqgL-5fB+T=2SWy6zpQae3A@mail.gmail.com> <CAHbrMsAfePUP+V7Ta5DV+rsSUuzso-zg=TenGrQ+nG72+OF_mA@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_10:2020-10-07, 2020-10-07 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zAGxfkf9xgvIEgFfvK5CiNS3t6Q>
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 21:11:18 -0000


> On Oct 7, 2020, at 12:26 PM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> 
> 
> On Wed, Oct 7, 2020 at 3:20 PM Brian Dickson <brian.peter.dickson@gmail.com <mailto:brian.peter.dickson@gmail.com>> wrote:
> 
> 
> On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz <bemasc@google.com <mailto:bemasc@google.com>> wrote:
> On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson <brian.peter.dickson@gmail.com <mailto:brian.peter.dickson@gmail.com>> wrote:
> 
> Other than the syntactic brevity, is there any functional difference to the client between a TargetName of "." versus a TargetName of "$HOSTNAME" in the description above?
> 
> Currently, "." means $HOSTNAME for the HTTPS record (when no prefixes are applied).  With the proposed change, "." would always mean $HOSTNAME when a ServiceMode record is returned directly for the original query.  However, if the ServiceMode record is reached via a CNAME or AliasMode record, then "." does not correspond to (the original) $HOSTNAME.
> 
> This presents two significant problems.
> 
> First, this (what you write above) means that "." will not be guaranteed 100% of the time to result in the "correct" value, if I understand correctly.
> 
> I'm not sure what you mean by "correct".  With or without this proposal, the expanded name for "." is well-defined.
> 
> Second, the use of "." by whoever creates the ServiceMode record may not be aware of how it is reached (e.g. by CNAME or AliasMode records not under their control or that they are aware of or which may be added later).
> 
> The expanded name does not depend on how the record was reached.  I'm merely trying to point out that, after an alias has been followed, any information about "$HOSTNAME" has been lost.

+1. The “.” is very clear in meaning, since it is only referring to a name that is in the record itself. It’s not about where the chain comes from. This proposal is only about cleaning up a case where that name in the record has less helpful “_foo" prefixes. We absolutely should keep the “.” meaning as-is for all other cases.

Tommy

> 
> ...
> As you note below, "@" is available, and while perhaps not as elegant, is handled in the authority server's loading of zone files, and never results in dynamic processing or additional handling requirements. I.e. it achieves maybe 90% of the intended "happy" result, but does so with 100% interoperability after the zone itself is constructed and loaded.
> 
> My impression is that "@" is always, or nearly always, a zone apex.  I expect that the majority of HTTPS and SVCB records will not be for the zone apex.  Setting a ServiceMode TargetName of @ would instruct those records to use the A/AAAA records for the apex name.  This strikes me as an unlikely configuration.
> 
>  
> 
> First, is the use of the standard zone file construct of "@", which only exists within the zone master file, and gets substituted on import with whatever $ORIGIN is.
> 
> Yes, the syntax already supports "@" and relative names when writing out a TargetName in the zone file.  This is useful, but I don't think it has the effect of guiding users toward a good configuration.
> 
> Brian 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop