Re: [DNSOP] SVCB without A/AAAA records at the service name

Ben Schwartz <> Fri, 15 January 2021 19:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96CC63A10BE for <>; Fri, 15 Jan 2021 11:02:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.971
X-Spam-Status: No, score=-17.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, 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, URIBL_BLOCKED=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 o2V-d_BrEW62 for <>; Fri, 15 Jan 2021 11:02:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDA2E3A10BA for <>; Fri, 15 Jan 2021 11:02:05 -0800 (PST)
Received: by with SMTP id u17so20189644iow.1 for <>; Fri, 15 Jan 2021 11:02:05 -0800 (PST)
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=5DHSLRqfJiBuvWk1SPp6Tw7gKgYeu9pgShNpidgiaRg=; b=un0ss0l1cb67xT8wZflVtq42Nk3nVmbRNCOhYaO9y1ao/NpFPXEBw2S1h/Wi1esaik nazPlDR1ziKzQ7gDsvcF3goHbOJeSIOxtekHaX9qacFOMoRgpAyl8EWREDvS9PBZiwnE yGnRyMrHpYJ+h1jQom64RBBPTYDDcbvZQnYAiWxFANmzKaZZkLuRVXVfecGsZcULLnBo vLE0xFzfU9WQKdQcY4+O2jXay7dvUIs0Fb6xUP6ieSWvtQ+SwSscBfrZJ2Gr70abuqdW YB8bIYKR4lZAtw8Xg5KQpKMU9tZ73oKZQBVGA11tmf5GIPKfjtJUfGbsE9kQa4mQv624 rYIQ==
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=5DHSLRqfJiBuvWk1SPp6Tw7gKgYeu9pgShNpidgiaRg=; b=UTqr0zb4b7bIlAL2Cup+z78xLNCL5MybMYD2Fee17FToD367Xo/DD7WCdCSMWz3KM+ N9NblSDlRdplfghZdaU+JlMtv9aY5H6hIPXG33KVE+JZrq81ZxQsIN91T5vRUFQcF1p1 Uc9UyqQuRaU0RKvcOHWZjojb78rhzfEES4UFtxKYjrhcg/k3PosNG///CmUUVOutJUJR p7Wp3zL8czmHwkrszdsX4OFbEQqTtmwIimhu0w9Fsp4fgsdbl3K7SbySaMdLO56gW1wC wkdvL40+CdbF3iAmV83+t3v+1l1fIWX2jAyCbwuzvA9TFyIrmwBqwQmSH5Hu21aISMK1 l2qw==
X-Gm-Message-State: AOAM530Rzp8PcHaXDa6jpNvy5hOgOOgiRdiwZ5esDMfW7VlpD8DVSbWV yabvHT7wOjHvJXvQ97xOMLvkV2M9Rm6VDpmMep7uEWu3akz/cA==
X-Google-Smtp-Source: ABdhPJwcE9sZZToYulGu+F+iIV6RM4WdNmj0bZtsPq4fql3JC2gNpPmY03lDp+W97jN7DApXZyuaZKks8gCsKpuMHeo=
X-Received: by 2002:a6b:b788:: with SMTP id h130mr9526284iof.134.1610737325053; Fri, 15 Jan 2021 11:02:05 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Fri, 15 Jan 2021 14:01:53 -0500
Message-ID: <>
To: Martin Thomson <>
Cc: dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000001b5f5b05b8f5025f"
Archived-At: <>
Subject: Re: [DNSOP] SVCB without A/AAAA records at the service name
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: Fri, 15 Jan 2021 19:02:08 -0000

FWIW, I think this is really an editorial question.  The SVCB draft lays
out how we expect SVCB to be used initially, but there are very few
constraints on how some future protocol specification could make use of the
RR type.  That includes the various possible fallback behaviors.

I'm happy to adjust the text for clarity on this point.  Here are two
alternatives for how to clarify the text:

1. Specify the expected behavior of future SVCB-reliant protocols (which do
not yet exist):

2. Clarify that this section's recommendations are only defaults, and
future protocols can do whatever they want:

On Thu, Jan 14, 2021 at 6:43 PM Martin Thomson <> wrote:

> As requested (I'm not engaged here enough to understand the terms of
> engagement, so my apologies for using an interaction form I'm accustomed
> to), moving discussion from
> to here:
> The SVCB draft basically mandates a fallback to A/AAAA.  I think that this
> is not universal and that this should instead be made an option.
> For HTTP, the fallback is necessary.  For a new protocol, a fallback could
> be undesirable.  Especially if you want to deploy that protocol using a
> service name on which you have already deployed HTTP.  If you don't want
> your HTTP servers getting connection attempts for the new protocol, the
> fallback is more nuisance than useful.
> _______________________________________________
> DNSOP mailing list