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

Tony Finch <dot@dotat.at> Tue, 11 August 2020 20:54 UTC

Return-Path: <dot@dotat.at>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97893A0C63 for <dnsop@ietfa.amsl.com>; Tue, 11 Aug 2020 13:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VUwVM-uBDGD for <dnsop@ietfa.amsl.com>; Tue, 11 Aug 2020 13:54:15 -0700 (PDT)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C5E3A0BF4 for <dnsop@ietf.org>; Tue, 11 Aug 2020 13:54:14 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:41412) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1k5bHg-0000PN-gt (Exim 4.92.3) (return-path <dot@dotat.at>); Tue, 11 Aug 2020 21:54:12 +0100
Date: Tue, 11 Aug 2020 21:54:12 +0100
From: Tony Finch <dot@dotat.at>
To: Ben Schwartz <bemasc@google.com>
cc: Brian Dickson <brian.peter.dickson@gmail.com>, dnsop <dnsop@ietf.org>, Pieter Lexis <pieter.lexis@powerdns.com>
In-Reply-To: <CAHbrMsCePLp=vaw3fgf611TfnFpeUaV3xkCT5BSH3yzu-XZ1rg@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2008112129160.21650@grey.csi.cam.ac.uk>
References: <00cfd965-bf69-d1cb-2df3-1a9bb110d7e0@powerdns.com> <CAHbrMsAJ-cbcW3v4T34f8-gzgzgHSkoBO545_Y3N8D6rof7Nmw@mail.gmail.com> <CAH1iCipZ25XaES0C4MFt3+aOm=d1U5LKigJe5AwKUWG-+yETFw@mail.gmail.com> <alpine.DEB.2.20.2008102304160.21650@grey.csi.cam.ac.uk> <CAHbrMsCePLp=vaw3fgf611TfnFpeUaV3xkCT5BSH3yzu-XZ1rg@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5hS_vAt9d0dKSGHbO2-WOAf7Y70>
Subject: Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2020 20:54:17 -0000

Ben Schwartz <bemasc@google.com> wrote:
>
> 1. If TargetName is not in-bailiwick and is not ".", terminate the procedure.
> 2. If SvcPriority is 0:
>     * If TargetName is ".", terminate the procedure.
>     * Otherwise, perform a SVCB "follow-up" query for TargetName and add all
>       returned records, including any records added by this procedure.
>       If any SVCB records were added, terminate.
> 3. Perform A and AAAA follow-up queries for TargetName (or for the owner name if
>    TargetName is "."), and add all returned records.

I think the actual wording you want here is "in the same zone" not "in
bailiwick". The important thing you don't want is to require an auth
server to go out to the network to query for address records in a
delegated subdomain. The more subtle thing is happens with auth servers
that host zones from many customers: they want to avoid cross-zone
contamination in additional sections because a careless or malicious
customer may have set up a shadow zone for a domains whose NS records
point elsewhere.

The "bailiwick" term should only be used when discussing whether
delegations need glue or not. (See RFC 8499 and DJB's notes on
gluelessness that introduced the term http://cr.yp.to/djbdns/notes.html)

> If the server does not complete this procedure (e.g. due to response size
> limits), it MUST remove any SOA records from the Additional section.
> Recursive resolvers MAY use the presence of an SOA record in the Additional
> section to enable negative caching of the follow-up queries, as in
> {{?RFC2308}}.

I'm not sure I understand this paragraph. Truncation is normally from the
end of the additional section backwards, so it is really weird to drop
records from the authority section first. SOA (start of authority) records
go in the authority section not the additional section - the authority
section is all about gossiping zone cuts (i.e. SOA records) and nameserver
records. I don't understand how negative cacheing is relevant to a
positive response for a SVCB query.

The DNS doesn't allow a client to know that additional data doesn't exist
when it is omitted from a response. It sucks, but that's the way it is.
(This is why most SMTP software doesn't actually use the additional
section in MX responses.) You could in theory put a DNSSEC proof of
nonexistence in the additional section, but I don't know of any software
that will make intelligent use of it.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Southeast Iceland: Southeasterly veering southwesterly 3 to 5. Slight or
moderate. Fog patches, rain at times. Moderate or good, occasionally very
poor.