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

Mark Andrews <> Wed, 12 August 2020 01:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9F853A0E2F for <>; Tue, 11 Aug 2020 18:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mUN18anxrTto for <>; Tue, 11 Aug 2020 18:16:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BFB83A0E2A for <>; Tue, 11 Aug 2020 18:16:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB5A73AB070; Wed, 12 Aug 2020 01:16:03 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTPS id D9285160051; Wed, 12 Aug 2020 01:16:03 +0000 (UTC)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C619C16000C; Wed, 12 Aug 2020 01:16:03 +0000 (UTC)
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id zIGh6XcRRhyc; Wed, 12 Aug 2020 01:16:03 +0000 (UTC)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 78D33160051; Wed, 12 Aug 2020 01:16:02 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.6\))
From: Mark Andrews <>
In-Reply-To: <>
Date: Wed, 12 Aug 2020 11:15:58 +1000
Cc: Tony Finch <>, dnsop <>, Brian Dickson <>, Pieter Lexis <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Ben Schwartz <>
X-Mailer: Apple Mail (2.3445.9.6)
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 01:16:06 -0000

> On 12 Aug 2020, at 10:25, Ben Schwartz <> wrote:
> 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 procedure). 

The negative caching of NODATA/NXDOMAIN indication is tied directly the QNAME, QTYPE and rcode.  In the Additional section there is such linkage.  See RFC 2308.

If I have " SVBC 0” and “ SOA …” what exactly does the SOA record mean?
There is no records at  There is no SVBC record at  There is no A or AAAA record at There is no CNAME at  What if one can’t fit some of these RRsets but can fit a SOA?

What happens when you know there isn’t a SVBC, have a A RRset and know nothing about AAAA?  Do you add the SOA or leave it out?  If you add it then what does it imply?

If one wants to have negative answers, included in the additional section then I would suggest defining a EDNS option the returns <SOA Record sans class and rdlen><target name><rcode><typelist-if-nodata> for unsigned zones and NSEC/NSEC3 negative data proofs for signed zones and require clients to be DNSSEC aware.  RFC 2308, while it doesn’t state it, only adds SOA records so non-DNSSEC clients/non-DNSSEC zones will get a cacheable response.  There is enough information in the NSEC/NSEC3 proofs to maintain a negative cache entries if all clients where DNSSEC aware.

> 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.

> That
> 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 position:
> * Auths are not required to do any additional section processing
> * Auths SHOULD do some kind of additional section processing, details unspecified
> * 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.
> _______________________________________________
> DNSOP mailing list

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: