Re: [DNSOP] additional section, was Over on the dbound list: draft-dcrocker-dns-perimeter-00

"John R Levine" <johnl@taugh.com> Sun, 14 April 2019 15:13 UTC

Return-Path: <johnl@taugh.com>
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 96B8912000F for <dnsop@ietfa.amsl.com>; Sun, 14 Apr 2019 08:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=I6Q6f2wm; dkim=pass (1536-bit key) header.d=taugh.com header.b=UMGii84s
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 Sm7DfF7b3xWo for <dnsop@ietfa.amsl.com>; Sun, 14 Apr 2019 08:13:51 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 0200C120006 for <dnsop@ietf.org>; Sun, 14 Apr 2019 08:13:50 -0700 (PDT)
Received: (qmail 77918 invoked from network); 14 Apr 2019 15:13:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1305a.5cb34e2c.k1904; bh=NVkpS023rjUwyBF61Yn6Mx73/ocmSyqgY1LvM61FZ6w=; b=I6Q6f2wm0hmOMIzg26RFDRwTE/Q9YDiDBwF+L4l9lrNJn33Ce7hUDyMGoyVAo+2LKRLRHU6Bdb/ZqpvJJwEBsAkdlnBBSUMmn9dmsMui1y8kdJZde9q7htKhBR2Ba4iBysVmaczqn5nXU7jozShj7lQxGZHLdSNZTdeb8LUZQufbbiFKGdQsvitmNuINRxh/LJx3M8Uu/+BvqGEPk94jS4q3Nupd8H1/zCbihcpj5IQDVh/uTmfFhWxlOHnqWAeJ
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1305a.5cb34e2c.k1904; bh=NVkpS023rjUwyBF61Yn6Mx73/ocmSyqgY1LvM61FZ6w=; b=UMGii84sfEP80TrbNhcg/ZytdErJYMPEZfQJhRpCuUG+eATU/OgevDpHwpAvrwmPn/yEtNdZP60sdltyEbA89RlTHY6P3t4A1sRNJqAxlDZs1FcSF33vfMn0yNE4xO3K7alyJI9Th7hh0fNXOeBhBRTHIAvmRoSCDLV2wpkKOZ0ReZgt7NeQYktA+wxrpeZbc/aEMSW8D7cqLtid+I2Y1GJiYGlQ/Nl2CfiW9HnHgtnBUgumEsp3+/UlEivHwDha
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Apr 2019 15:13:48 -0000
Date: Sun, 14 Apr 2019 11:13:48 -0400
Message-ID: <alpine.OSX.2.21.1904111712180.22307@ary.local>
From: John R Levine <johnl@taugh.com>
To: dnsop@ietf.org
In-Reply-To: <20190404012010.64DB6201162C3F@ary.qy>
References: <20190404012010.64DB6201162C3F@ary.qy>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KFhrjan0WofaAkBSznJ_nT8ROUM>
Subject: Re: [DNSOP] additional section, was Over on the dbound list: draft-dcrocker-dns-perimeter-00
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: Sun, 14 Apr 2019 15:13:54 -0000

On Thu, 3 Apr 2019, John Levine wrote:
> The part of interest to DNSOP would be section 7 on pages 12 and 13
> where it discusses tree walks and potential new additional section
> processing to find the closest perimeter record above a name being
> checked.

This draft proposes to publish TXT records to mark logical (not zone) 
boundaries, sort of like what the Mozilla PSL does.

Let's say there's a boundary between d.example and example.  Then the 
domain owner would publish _perim.example to show that's where a boundary 
(perimiter in the draft's language) is.  But what if the names go deeper 
and a client is wondering where the boundary is in a.b.c.d.example?  The 
proposal is that the client asks for _perim.a.b.c.d.example, and the DNS 
server returns NXDOMAIN but also puts the _perim.example in the additional 
section, so the client knows that's where the boundary is and doesn't have 
to do a tree walk.

It seems to me that this can't work.  Additional section entries are only 
hints, and just because it returns _perim.example, that doesn't mean that 
_perim.c.d.example doesn't exist.  In a DNS cache, there's no promise that 
additional section records will be remembered for the same time as the 
main answer, or for that matter remembered at all.  The client still has 
to probe all of the intermediate names to check that they don't exist.

Another issue is that qname minimzation breaks this, since the 
authoritative server often won't see the full query.  Or if the boundary 
is above a zone cut, the authoritative server won't have the additional 
record to return.

Although it is legal to put an additional section in an NXDOMAIN response, 
it's uncommon and I don't know how the bailiwick checks would work.

It seems unlikely that any DNS servers or caches would implement a feature 
that triggers TXT record additional section records based on the qname.

Am I missing anything here?

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

PS: for a different design that (ab)uses wildcards to do the same thing 
and avoids tree walks see draft-levine-dbound-dns-02.