Re: [DNSOP] [Add] [ADD] Last Call: <draft-ietf-add-svcb-dns-05.txt> (Service Binding Mapping for DNS Servers) to Proposed Standard

Ben Schwartz <> Mon, 27 June 2022 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A7EBC15A723 for <>; Mon, 27 Jun 2022 11:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.609
X-Spam-Status: No, score=-17.609 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 IAILOSjoHkWQ for <>; Mon, 27 Jun 2022 11:29:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id B025BC14F741 for <>; Mon, 27 Jun 2022 11:29:00 -0700 (PDT)
Received: by with SMTP id h26so4866192vkc.2 for <>; Mon, 27 Jun 2022 11:29:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rKrbWwOvWMXlyi6zhY0IO4KadHJ7bkrsS7XQ9dln8fo=; b=LM+loT62jy5fdLB7+LaqYzp9wcbIqtfFfRkZk/Z266BDRHP/of+IOtRkmYWXmHkxWC nERaMOT4gUNcFNSS3UweC6zGz8rNnKJ6j4rUGgWRFVsjVJZJ9xDjfUoj9RrKBD0Sfi6v Tag7dN5lqmWecW+/VRFl1UI2wkYyBMBTC1eHA3D27fYXbyx1whSk63eFS8wT52zmP3f9 F/wF8bs3RjSd10S+V5S8wc4NLy+7LJSA9tW9ors1VM9CzB/TsoLRVIxiAeX02rDX/8hB QUSuY0CzY2+np+9x6m9Y92o+JuRFZd7mcAwq4+YolFLCLU51bL9yEtKuh/GgTvpplLc6 aXxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rKrbWwOvWMXlyi6zhY0IO4KadHJ7bkrsS7XQ9dln8fo=; b=n/7cJ1711VEdXIvjaOH9E+RETOO7wLjhsNuYUWM2xdQ7LsSDNP846lRQcsLYDrBzkX 5kHxiEyFghyKItbLx6del+JBNOGQ7LiuMyGX6eu51kB16+gKD5VBNWyf4bt4b97JkQlH w/r+Zb+v/gJ6Png8W3kc255dgSJiwTCfSmhQ2Xt2a+6mEh/Sa6Uy3VfmgaABpCuW4hC3 mEPxQAIcdlcfIeNT0nGf0LUFt5RTLabVQFIDZIsfQtcSU/sVvR2qhJL4dtxZ3UQUaCnx FLqiurtFHR91AXsltTRUyYy+fgIdhhRrOXJFw/RImCoa7gjQUb2PzLDmxSK9/kDmQfeH V4mw==
X-Gm-Message-State: AJIora8myCz1mh/4lOXB5Wnjf1HDYEAfc4iE+He+QKoXrD+3U4EVgtFa 3V5TrlHF/JubONxlQwqswBHXgWbzthKR8Qb7ID0OrOi5ryvL9w==
X-Google-Smtp-Source: AGRyM1u2FhafIkxdH+c/SWdiuTdtc+QgAxAvGiiifBnApQcHefh1ZEdn9PkMN+t7AV/6lwCVvXf74TLFWbvUNYtrBrs=
X-Received: by 2002:ac5:c7c7:0:b0:36c:5b47:f01a with SMTP id e7-20020ac5c7c7000000b0036c5b47f01amr291469vkn.39.1656354539448; Mon, 27 Jun 2022 11:28:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Mon, 27 Jun 2022 14:28:48 -0400
Message-ID: <>
To: dnsop <>
Cc:, ADD Mailing list <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000f860a005e272173d"
Archived-At: <>
Subject: Re: [DNSOP] [Add] [ADD] Last Call: <draft-ietf-add-svcb-dns-05.txt> (Service Binding Mapping for DNS Servers) to Proposed Standard
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jun 2022 18:29:01 -0000

On Mon, Jun 27, 2022 at 12:43 PM Viktor Dukhovni <>

> So perhaps the document should note using SVCB to signal transport
> security for nameservers derived from NS records is predicated on a
> suitably secure connection to the parent zone.
> The use of SVCB RRs for authoritative nameservers introduces the
> possibility that the SVCB target name is different from the "service
> name" in the NS record.  Such additional indirection is perhaps
> surprising or even undesirable.
> Also, likely DoH would not be a supported transport for authoritative
> servers, with DoT or DoQ being the available options.
> If this draft is to be adopted for use with authoritative nameservers
> these topics would warrant some further discussion, and perhaps some
> minimal text is warranted to say as much.

Hi Viktor,

I think these are points worth mentioning, and I've written up some
proposed text that would remind the reader about them [1].  Please review.
I've tried to address these topics without focusing too heavily on the
"authoritative nameserver" point because I think they actually have broad