Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

Ben Schwartz <> Wed, 05 August 2020 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAD883A0CFD for <>; Wed, 5 Aug 2020 10:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 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, 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 XuV6CTN0p66s for <>; Wed, 5 Aug 2020 10:08:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F8233A0CD7 for <>; Wed, 5 Aug 2020 10:08:04 -0700 (PDT)
Received: by with SMTP id x5so6474009wmi.2 for <>; Wed, 05 Aug 2020 10:08:04 -0700 (PDT)
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=u9Aj5NGYiilUNpRCGpdBiDThwTJBSsPt1wqYVrldoiY=; b=vfAHK1nTZu3iVeljVkv8Tnnm/uJJoL7qtqi8LoV+Cv1fTBMdn1VH7WjYuaUccFqjgj OGYA+5uHwqqcPrbSHpQq3jc1bnF1QBPt+7wpPy5TwlSBK48mE8Gj9cvJH9KMyY2Fk3GP 7muNd4ImmyDE0d22+hMhrKco3f87n0RnME43fjq6CBvr7nLvGQFdEsL1t0xpi4d0KtFQ XHC0YJF00DPuScZnz4H2kudoBHxUMAuwQ4xxRgWsWhpvH4DvNPXiJMMPDbZt3fdYIXfB zhxSL6yqp2bq8PoFvuPKkuZQweJU+RTUE1dpKa3bvkWy+YvWb0C1j7kXRklzcA11n45o 631g==
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=u9Aj5NGYiilUNpRCGpdBiDThwTJBSsPt1wqYVrldoiY=; b=GR+9WU/61Y7aztHX8PxGLgZ5UcjlXdw3FGpqAZIg6Iq+BOspox6Wg5v3HTj19/Tv1i ElYwjV0Q2Pph1crMbG+npBzJfEpR6OTVI5snZ20+/UJIxMZE00ir/njzjwGOODpP2dIw 0ixHyXBB3qSNZvP0kxKV5LLwsUax9qr9nZc5apJuNtd+Ls7qkC633vUn25RKeVeZuIyb q5sEjWvS7tKoOV8DvImtoDqvbsR3a9OOANpOuPh9lMPi8xHl2IPnMz23voJaalZ+2R5Z EnVgGJu8RcIImFXODz3rtbswJaegXDsQiEixBRh57CcrS0XKtx4dpD/yyTpCKcm38gAQ XJ0g==
X-Gm-Message-State: AOAM531O/oK2v5Lco2Y+M+b6bJRVCMpag0vOj1HJ6kqmdVKjhLgsNWdj nY4CuISsSVV5DjwoxJS4Wq0GiKZGW7pnUKpzQ1d9Dw==
X-Google-Smtp-Source: ABdhPJw5MxE4Q+G3h+PeeIokfaV/VBFiPv6Qsz/MuFdlf5YFK2yUZqcOKGPYiIKSdAv4vz/HKslfVAluclzZ1nBE4WM=
X-Received: by 2002:a1c:7918:: with SMTP id l24mr3931386wme.132.1596647282712; Wed, 05 Aug 2020 10:08:02 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Wed, 5 Aug 2020 13:07:51 -0400
Message-ID: <>
To: Pieter Lexis <>
Cc: dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000249a2805ac246a42"
Archived-At: <>
Subject: Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
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: Wed, 05 Aug 2020 17:08:07 -0000

On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis <>

> Do *both* alias-target{1,2}|SVBC records end up in the
> ADDITIONAL section. Or are they (as is the case with an in-zone CNAME)
> considered an answer and should they go into the ANSWER section?

I think Section 4.1 is pretty clear that everything goes in the Additional
section.  (But this can be changed!)

I find the alias mode semantics (on the DNS-level) unclear and
> under-specified in the draft. I look forward to guidance from the authors.

And I look forward to guidance from you!  How do you think it should work?
Send text!

Personally, I'd like to know which of these questions actually need to be
resolved in the standard, and which can safely be left to the discretion of
implementors.  Is there a compatibility concern with any of these
questions, or is it only a question of consistency across implementations?

Conceptually, AliasMode is not a CNAME: it only affects SVCB queries (not
other RR types), and can safely be implemented entirely as an RFC 3597
Unknown RR Type.  That suggests that it is at least safe, and perhaps
least-surprising, for the authoritative server to put all responses for
other owner names in the Additional section, as the current text seems to
indicate fairly clearly.

P.S. The text on this point has recently changed:
One of the questions there is what should happen for
AliasMode->CNAME->ServiceMode->AAAA, all in-bailiwick.  The draft says
"Clients and recursive resolvers MUST follow CNAMEs as normal.", but it no
longer says anything about authoritatives.