Re: [DNSOP] SVCB and the specialness of _

Ben Schwartz <> Wed, 07 October 2020 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9334D3A00F7 for <>; Wed, 7 Oct 2020 12:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Status: No, score=-17.6 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 do6yG-dzI2uh for <>; Wed, 7 Oct 2020 12:27:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCD5D3A005E for <>; Wed, 7 Oct 2020 12:27:08 -0700 (PDT)
Received: by with SMTP id k6so3680026ior.2 for <>; Wed, 07 Oct 2020 12:27:08 -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=nTLg7ME3ty+NN0XAFwBDz8VMtj4in5nBKOnkIWjaPYo=; b=FgXNsEj+wIexvP8H6G7HndZjkKI0BkiAMFpdb5t985h0eeIJsmQheG6AHJRPbOHPPU 3XDMzEB1w7ZC16BWoXpGOCTkVGB2KQam9fnYm1HpKk5wEGpPyD7cChGbl5nV4XICgOeM 8CVVlj1CksZhJdH8w7tDgRN0cmZPajfrblyEzTcUXiC8ELpbaBstI6eXWm0TCl5NltJ2 tT5dbsQUseNkg8pUuQU87VfHU0JFrnhYmtTLjoBJeVKkSa9bkbrc0r8AbdnPOcL+i0Rt f5Pt96J5WTHJlbCSJOph6LsRXeIReo+nB1ggyoLeX3yUCKkPB7OddGzr5e86OaO8C/OC a5TA==
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=nTLg7ME3ty+NN0XAFwBDz8VMtj4in5nBKOnkIWjaPYo=; b=nblNzM3NezGZVRa+l2oK0FJfznUsnSPJQkTl2SgOkwJget9YtFn6PazSXM1piemPCv p88olbU2r9mAE8TctbMvy192kC686k/oAqbP85zeY0lnPXy9oAmLUMkeNMKaCbYkmvBo 6bPZ1GVG6eahGjfPwnitY+7P+27qe+KYTl3VSKKrIQfeAKKzkm6J+qn38/XBb47JH2/j yDJLzjeGY7MQcwfL9RRLh/Idbgf/p3pqysDUHhnSNkvkXx8NF7nHuYrmkdK1cv9ytgGi h1dXmPJrORbsElaVxTvxDG/uzqFTu8r0P1Ns3E7+dqkVhIwVbqILzrga+FKosTKfqOm0 FwrA==
X-Gm-Message-State: AOAM532JEA5XvUQY5FY2rd/ZJkDv02xRm969BlCOfsspzZzO5ZYjg14U WnxhCaVtt2WBAgaNx082w93bFwFm0rEzJcWWBT3EHw==
X-Google-Smtp-Source: ABdhPJzfvtKMs0V1t+9k0RvYWn9nFc0CCm6NgM9zPvj5PBl5RGEwK7nrucwQa6teFS/fAFuCirNMhGHgSOfCI0Ua4m4=
X-Received: by 2002:a5d:8787:: with SMTP id f7mr3474618ion.79.1602098827795; Wed, 07 Oct 2020 12:27:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Wed, 07 Oct 2020 15:26:56 -0400
Message-ID: <>
To: Brian Dickson <>
Cc: dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000008e606505b119b3be"
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:27:11 -0000

On Wed, Oct 7, 2020 at 3:20 PM Brian Dickson <>

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


> 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