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

Shane Kerr <> Fri, 15 January 2021 08:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43CF43A108B for <>; Fri, 15 Jan 2021 00:15:45 -0800 (PST)
X-Quarantine-ID: <cZ-9fJZXXDuH>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...T_ADDRESS@@ for details. Content previ[...]
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cZ-9fJZXXDuH for <>; Fri, 15 Jan 2021 00:15:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACA653A1085 for <>; Fri, 15 Jan 2021 00:15:41 -0800 (PST)
Received: from ([2001:984:2b8c:1:fc82:d348:4d1b:be5]) by with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1l0KGc-0002d1-Ld for; Fri, 15 Jan 2021 08:15:37 +0000
References: <>
From: Shane Kerr <>
Message-ID: <>
Date: Fri, 15 Jan 2021 09:15:33 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score-Int: -28
X-Spam-Bar: --
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 08:15:45 -0000


On 15/01/2021 00.43, 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.

This is an interesting observation.

Certainly with the MX fallback to A records sometimes SMTP delivery is 
attempted (or made!) to the wrong server. So we know that this happens.