From nobody Wed Oct 7 14:11:18 2020 Return-Path: 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 ; 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 ; 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 ; 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 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: Cc: Brian Dickson , dnsop To: Ben Schwartz References: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 21:11:18 -0000 --Apple-Mail=_9A5F4856-4534-457C-ABC5-CA4D1A13B5EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 7, 2020, at 12:26 PM, Ben Schwartz = wrote: >=20 >=20 >=20 > On Wed, Oct 7, 2020 at 3:20 PM Brian Dickson = > = wrote: >=20 >=20 > On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz > wrote: > On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson = > = wrote: >=20 > 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? >=20 > 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. >=20 > This presents two significant problems. >=20 > 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. >=20 > I'm not sure what you mean by "correct". With or without this = proposal, the expanded name for "." is well-defined. >=20 > 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). >=20 > 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 =E2=80=9C.=E2=80=9D is very clear in meaning, since it is only = referring to a name that is in the record itself. It=E2=80=99s 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 =E2=80=9C_foo" = prefixes. We absolutely should keep the =E2=80=9C.=E2=80=9D meaning = as-is for all other cases. Tommy >=20 > ... > 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. >=20 > 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. >=20 > =20 >=20 > 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. >=20 > 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. >=20 > Brian=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_9A5F4856-4534-457C-ABC5-CA4D1A13B5EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 7, 2020, at 12:26 PM, Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:



On Wed, Oct = 7, 2020 at 3:20 PM Brian Dickson <brian.peter.dickson@gmail.com> wrote:


On Tue, Oct 6, 2020 at 6:10 PM Ben = Schwartz <bemasc@google.com> wrote:
On Tue, Oct 6, 2020 = at 8:51 PM Brian Dickson <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 =E2=80=9C.=E2=80=9D is very clear in meaning, = since it is only referring to a name that is in the record itself. = It=E2=80=99s 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 = =E2=80=9C_foo" prefixes. We absolutely should keep the =E2=80=9C.=E2=80=9D= 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

= --Apple-Mail=_9A5F4856-4534-457C-ABC5-CA4D1A13B5EB--