Re: [DNSOP] SVCB and the specialness of _

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 07 October 2020 00:51 UTC

Return-Path: <brian.peter.dickson@gmail.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 D309D3A1590 for <dnsop@ietfa.amsl.com>; Tue, 6 Oct 2020 17:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gChV5z8W_dqq for <dnsop@ietfa.amsl.com>; Tue, 6 Oct 2020 17:51:45 -0700 (PDT)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C423A158E for <dnsop@ietf.org>; Tue, 6 Oct 2020 17:51:45 -0700 (PDT)
Received: by mail-vs1-xe35.google.com with SMTP id 5so265823vsu.5 for <dnsop@ietf.org>; Tue, 06 Oct 2020 17:51:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MXqkxdrWXwMF4cqR6VE3L4OVKOa9sa+oPb4fqVM47yE=; b=RoDqH6FMsRC/rcRwkzk0ES11/0aBUOP4kxBdEtstfiT9LH3r/TwisTK3/1RkTqp1YK gWgFl1XEjsp4lmfsV9fPt7EcyVDWDRuWejnIWQgQGlRWIlkezhMYIRKGKP206m6POCnb Bz5GcIN9ZpR+kFeRCqW/pV+OZxHmH2SYZ7i0mcDLTT51OABwYrRO2kzaHVn3U9tsa7SK yJj4PFXr1BJVEaf04HxoFokjSXXM8Rhw8LUvtbW3Wmi7QNS/vA33OVzJ4UxnLQKIeJTI OI5DeNL7teUOmjk6dBtyZjvXHOhJlYQu4kt6gozBVsm4XlKexoeeunWexvwNnWXa5leF JtwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MXqkxdrWXwMF4cqR6VE3L4OVKOa9sa+oPb4fqVM47yE=; b=ESjFol9frjeiuC1OpfEl5qRRwAuDAjETIrEfJtzYT5YOC3omRczbBt+NzsAnzjv1Ir 5riNP+fDtHbj8PAiuF3/ICShDd4VQ2cyCXv6+RWSmzxep/QkGqVCh0U/2nRXhQ7fVnGr eINE9OXKuTASWizCym99nf0N2FA7PAeVmTnyWKtnKhvsrxZe4wtkwdX5imv1lJf954KS b6+PqvOc5Mfnl8QliE6WF6cAwKboha4z46WbgUUrnIy59o9Skm7Dj9MZNJVeaybyqvpY AXpHDLwGEk1ax0yn/c/VfPaGL0cxZ7tKEXKYoQQYvsVBQvomRGmFi0UbDlMcownqDumX sGMg==
X-Gm-Message-State: AOAM530+5V0Gix/LlnyBO31sC1h08RBTGV0kEwgcqlYs4S2d/RHDHFP+ 0Mvd4P8wf6uGKaoyo+/Vlt06XIPAwm3JDgPJ19M=
X-Google-Smtp-Source: ABdhPJzee4Xmcv0E634EI3uUAxd29e8Lm7QYTpZmMv7CvWmOghecPMMBW2q6Y53vo+gzcMFU9MyBHazakY4PQ6oiEmE=
X-Received: by 2002:a67:1d86:: with SMTP id d128mr379100vsd.58.1602031904303; Tue, 06 Oct 2020 17:51:44 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsCLy8jERObtJU6XNQd2ef0U9sQbPMriHAGx=n513Dgx1g@mail.gmail.com>
In-Reply-To: <CAHbrMsCLy8jERObtJU6XNQd2ef0U9sQbPMriHAGx=n513Dgx1g@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 6 Oct 2020 17:51:33 -0700
Message-ID: <CAH1iCirmkES-T9LhZnm-gGAmLshso6GvDpNawqVYQwTEF9HiCw@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000932ee505b10a1e34"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/O1HdJkYA7eKsyW2fgnYpTSVMNP0>
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 00:51:50 -0000

On Tue, Oct 6, 2020 at 4:52 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.  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).
>
> 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.
>

(Apologies for not scattering comments in-line above, however, doing so may
detract from the context for the comments.)

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?

I'm not a huge fan of making RDATA special casing exclusively for zone
editing convenience. I think the RDATA size argument is not something that
should hold much (or any) weight, IMNSHO.

There are perhaps other ways of achieving the same goals, with more-or-less
the same level of user guidance and simplicity, in the zone file editing
function.

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.

Second, is the use of DomainConnect templates, which allow service
providers (such as CDNs or hosting companies) to provide templates for end
users (registrants) that are used by DNS providers to populate fields
automatically.
In the DomainConnect world, the template is managed by the service
provider, not the user, and removes most of the difficulty from managing
common DNS records.

(Non-sequitur: I am intending to pick up the IETF drafts for
domainconnect and update them, and try to get them adopted and published.)

I think both of these alternative techniques would be effective, and would
not have the problems listed in the "Con" section above.

Brian