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

Ben Schwartz <> Wed, 12 August 2020 00:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 500B73A0DF4 for <>; Tue, 11 Aug 2020 17:25:18 -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 l1DedTcvicDh for <>; Tue, 11 Aug 2020 17:25:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C7FF3A0DF1 for <>; Tue, 11 Aug 2020 17:25:16 -0700 (PDT)
Received: by with SMTP id t15so856101iob.3 for <>; Tue, 11 Aug 2020 17:25:16 -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=0KB6vjWMyEgD1QdGgE9E0Mpy1Q9J73HsTgHby/10yms=; b=vfa7FNuBW4+hidVauyi2zxwJB3IPYizknrZiP3NaAHx8Qn3U3F20OCGbJEqjVbDUEd qUTm74TfHxM79X4VuMf7z/vxbzw63S/0r+HPqrohtKM5QVZMQlW+DG/gGHPq273tU4T2 p2Q/jRUFANxsNLy+GF2XH9btAA1nZD4JCrtFw6jHt86ytxwGJf7jidDtaSYz2SF1OOkU XixKFoJ/AScu+j41NujUsMCtu3H5eR+oBYvT/7kdDPOV9ikG9cVc1/0axgCfNgkqeidq xrAwYs/mYJtVQ6GK+c2Ee+D07/eh9uliu4D+bKnvey0+11UnM7utoXOuh5IkZM1NHDm0 tYDA==
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=0KB6vjWMyEgD1QdGgE9E0Mpy1Q9J73HsTgHby/10yms=; b=nOwIrYgvsehGDBQX9If4eHRmZkZwsy73k7GIk6IEQdz2u6155GTwjljjCXF8Iu/8qz iS23fNUz8PGvkORZoZ9sCXBgoSzfoVvsBgeEk741GpXBH6ik/aaDL4YUdpfv8XWPb6QJ 796Txavtu6xrq9DbRSxoWfjVsQg3ddWWaLy1fp26FsktU35s3nUz0McDnPISSc9/0iAt ZWcRdjCXLVhZMXE6rnfH5KrepJ9h0pnZbOfuUCbL4HGQh4QukTsqioiM6QKDGU5koDUj 55H925lw422nK9/4a042+E6EptBDQGgK15UzVoA/6lyGlMjOJ7fpgDzA7aG54wvRg88r myaw==
X-Gm-Message-State: AOAM531otaGHwMYAClqEmVDLCVOAk3GVeSnNBpUIrOA2XKOo/X2By2b9 gHpcIiLV3X5e337uQxRIdBDnYdUCK89iON6+XIHUcQ==
X-Google-Smtp-Source: ABdhPJxE88HeXyHAw8xzOR4xjaZFFX1qDn6+EYu0YJOcwZRFGhPtZ3+//pguKHmS0XMlgEzvaFmYs/NiCGYc2BJ7/1s=
X-Received: by 2002:a6b:ce11:: with SMTP id p17mr25315028iob.125.1597191915371; Tue, 11 Aug 2020 17:25:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 11 Aug 2020 20:25:03 -0400
Message-ID: <>
To: Tony Finch <>
Cc: Brian Dickson <>, dnsop <>, Pieter Lexis <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c7b71a05aca3388b"
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, 12 Aug 2020 00:25:18 -0000

On Tue, Aug 11, 2020 at 6:18 PM Tony Finch <> wrote:

> Ben Schwartz <> wrote:

> > In this procedure, "all returned records" for follow-up queries are added
> > to the Additional section.  Therefore, there could be SOA records in the
> > Additional section.
> I thought the target types were just A, AAAA, SVCB, so where does the SOA
> come from?

If one of the follow-up queries for those types returns NODATA, there could
be an SOA in the Authority section.  "all returned records" includes all
sections, so it would be copied into the Additional section (in this

On Tue, Aug 11, 2020 at 6:38 PM Tony Finch <> wrote:

> > It seems to me that returning a (downward) delegation could actually be
> > useful.  So why not include that?
> Additional section processing does not normally include referrals.

Do you know why not?  It seems like a logical thing to include, if you
predict that the resolver will be making a followup query for which you
have a delegation.

> would be weird and new. I thought the point of the SVCB record was to
> appear to existing auth and recursive DNS servers as much as possible like
> a bog standard RR type, i.e. just wire and presentation format and a bit
> of normal additional section processing.

Is there a standard for "normal additional section processing"?  My
impression is that it is RR-type-dependent, so defining what should go
there is in the purview of this draft.

Which is basically what the draft
> says now, though it unnecessarily respecifies additional section
> processing.

Yes, the intent is to work well with "normal additional section
processing", but Pieter and Brian requested some behaviors or
clarifications in this thread, related to CNAME and SOA records, that are
either unclear or not supported with "normal additional section
processing".  Hence this proposal, which would leave us in the following
* Auths are not required to do any additional section processing
* Auths SHOULD do some kind of additional section processing, details
* Auths MAY do this specific form of additional section processing, which
follows CNAME chains, enables negative caching, and (maybe) even provides
referrals when appropriate.

Do you think this proposal would not actually work?  Or do you think that
it is simply too inconvenient to implement?

I would also like to hear Pieter's perspective, since the proposal is based
on his request in this thread.

> Tony.
> --
> f.anthony.n.finch  <>
> Mull of Kintyre to Ardnamurchan Point: Variable, mainly north or
> northwest, 2
> to 4, occasionally 5 near the Mull of Kintyre and Tiree. Slight,
> occasionally
> smooth in shelter, becoming slight or moderate later. Fog patches
> developing.
> Moderate or good, occasionally very poor.