[DNSOP] SVCB and the specialness of _

Ben Schwartz <bemasc@google.com> Tue, 06 October 2020 23:52 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C5ECE3A1553 for <dnsop@ietfa.amsl.com>; Tue, 6 Oct 2020 16:52:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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, RCVD_IN_DNSWL_NONE=-0.0001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kNjLba0alY5i for <dnsop@ietfa.amsl.com>; Tue, 6 Oct 2020 16:52:12 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 13DFA3A1552 for <dnsop@ietf.org>; Tue, 6 Oct 2020 16:52:11 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id o18so650286ill.2 for <dnsop@ietf.org>; Tue, 06 Oct 2020 16:52:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DCNpxBHJ7NPBGrB/7rsm5IxzTfA3Vdle3W+yFW7ZHl0=; b=hTAL94XXWtkqPcOeGTkv9nhd0Ra1/bDlpQM/LHnL76C4R9WIVI7V9LN5b0zxi12QNX WzYtfNJQtSkVjIZhhRQ93TxpXkOJk6hRaAqIKujWvumICNuoRI29dqw6ELjO83FHuyKJ OZZLZEHTCJ/EU29BjlD+30R1zWswGd1Jo1uSHxyTnWMqRAZWsqfjV9XSEvtY4R11RRQz 4qOuDKCyTPsH5LhC+8kkPZN3M8Tv9Hud7HuEJ/4eRdCMKKq/er7NCS9sMwVVYpNgGCDg B0bXnlSK3jpL7rFntbbRNQAqDBAk+hIIwT5zdQNCHnY64DJADVIYHp1QBSjMxQLs6nl8 V+aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DCNpxBHJ7NPBGrB/7rsm5IxzTfA3Vdle3W+yFW7ZHl0=; b=lpX8Wh3tE/yxLwCTqR2pAPbdqEcrZbt9dQ+LXu0ja9tq5xaZ3C7lWmyu8YzQgI9xOy Apdtv9vqQhnHPjixjWMaAswabwShPG5vUurxTT4msU8v2XU3Y7z+dCom9hmxRc5ueTIr MT8p/LLs+ONXY5LR1ft7GRbtQ/8MzdSSa4LqV8VtVT0Y11i9MUcuF0p6VxUsHnd0dNGd 8tt4ot1u+8l0mQkAQfBa3B5cZ44gEIvRxeJXjpIGDxL1UYYnlkDQNHSv0CjORWtuVoOV mBBa59rsOBbF4LNHPW8VJhA1nCGtt1C2daDeHmCaT2b/HrpHzq8bjUz9Zw7QpaX/Xzr1 yeHQ==
X-Gm-Message-State: AOAM5303jlvYqEsz7chFp2eoANq1ib7PGn5tFzEV09sXS37H7adX5VqF x+yUchjP0P0CiV3kX9ioFG2xqUn4cDyDmBbD3/C+Xh0TKMWNKg==
X-Google-Smtp-Source: ABdhPJyxOLSEfK7W59c0Sf/Yiopl6Qu5XoFbTN1ImW/6K/2K0N3NsAolDizkLfHFK56h7HPQ+atmkTQ0qXhk5S9T20s=
X-Received: by 2002:a05:6e02:1085:: with SMTP id r5mr573615ilj.44.1602028330811; Tue, 06 Oct 2020 16:52:10 -0700 (PDT)
MIME-Version: 1.0
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 06 Oct 2020 19:51:59 -0400
Message-ID: <CAHbrMsCLy8jERObtJU6XNQd2ef0U9sQbPMriHAGx=n513Dgx1g@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000009aea6005b1094912"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/K6uyh2B5uFpNgNcgLc8PtOK9uEg>
Subject: [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: Tue, 06 Oct 2020 23:52:14 -0000


There was recently an interesting proposal [1] for a change to the SVCB
draft that seems to merit input from the working group.

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

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

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)

* 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

[1] https://github.com/MikeBishop/dns-alt-svc/issues/252