Re: [DNSOP] SVCB and the specialness of _

Brian Dickson <> Wed, 07 October 2020 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C86FD3A1350 for <>; Wed, 7 Oct 2020 12:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7xOQs0r85u6v for <>; Wed, 7 Oct 2020 12:20:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 565743A1352 for <>; Wed, 7 Oct 2020 12:20:41 -0700 (PDT)
Received: by with SMTP id l6so902443vsr.7 for <>; Wed, 07 Oct 2020 12:20:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RzsNQtAmrS1QbnI1fi/1zJLm8T6ZtEcxHlK1jofH0Dw=; b=CPCJ8+SgMJfoX2TWBkQqCtcEYfp6x8Rcga4rnR2fUkYlshqySDSuWJP8M1Ff3tXfhC dzslzuwjwCX9Gm0tD97zCjJcyjHRbx0lul+/7qfk06lcKnHrX2B7myhZQzpq2M2KJGw+ pxEJaHkFwecBVBpa+1RRF8XmxhzDDOJ3+JxG9qVsTRtE1xPAv2ckU6pOLoGmDANKZVph GalKMdmGT7QrUh46/Yrnw79zDCtkwiywG/PcEM5AiCzKoV4nlEOKe0rhol5IeogdrS3D 6whCbP+lo6yM7rhqy6ZUWIpBdYpW8QPM6PgY+HCnGU8LgRlJ4fDhKgtQrDvPvLP4HGAk wbMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RzsNQtAmrS1QbnI1fi/1zJLm8T6ZtEcxHlK1jofH0Dw=; b=mjqrhfPE5SgprXzGrKm8iGR1wwA2xt/AJw8hzFPnZpV9MXX1JQK3kD+jY941H6LII8 c1u2NFmEq1xk1rN/oBHV5K253r2rfYyO8skDTlKVg266gk5+sNc7p9WXqN7RoJiUVquk eK7UEur8Yb6uL3Wia3QHCUBsU1ZusRwOS0ONGDoAznr/Sa9npp12YGi7l7o04iNZC4bl sYGvqjLdbQdflzemGilGw9BRYtCSxDSyRDvDgW2fjrJmk88MNhqE1LBV8E9wlEMwkPt0 zg67rPODiJp2mHQwmFIKK768bTxzaMtpELQajogiiuQ0BW9qp4GgAdg1pzlrwSKtjlEf J33A==
X-Gm-Message-State: AOAM533j6pC90ua48Y5X9JpVk0q0+m1/C9ZO2l4oVqH0JdoZMtB2eMhu cQsm/GdBZQ0GGkauO00atvqobZ4OooQRg6+5cug=
X-Google-Smtp-Source: ABdhPJwwMsE/DFoMRmtOFEvLHRjHga5FKid9F80rVMqhhExcHbiKI3AoOOt2FHMz7hDm0hWN81cq1ac7BwlB7hCRDMQ=
X-Received: by 2002:a05:6102:7a3:: with SMTP id x3mr2816778vsg.12.1602098440276; Wed, 07 Oct 2020 12:20:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 07 Oct 2020 12:20:29 -0700
Message-ID: <>
To: Ben Schwartz <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="0000000000006d8e9205b1199c6d"
Archived-At: <>
Subject: Re: [DNSOP] SVCB and the specialness of _
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 19:20:48 -0000

On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz <> wrote:

> On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson <
>> 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

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).

Unless I misunderstand, I think the lack of 100% correctness in all
scenarios means this will cause difficult-to-find-and-fix operational

For this reason, I strongly suggest removing the "." and its special

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.

> 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.