Re: [dbound] [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt

"John R. Levine" <johnl@iecc.com> Thu, 04 April 2019 02:14 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8547120198 for <dbound@ietfa.amsl.com>; Wed, 3 Apr 2019 19:14: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
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 vtnbMhHpbKoi for <dbound@ietfa.amsl.com>; Wed, 3 Apr 2019 19:14:52 -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 EB60D120195 for <dbound@ietf.org>; Wed, 3 Apr 2019 19:14:51 -0700 (PDT)
Received: (qmail 21565 invoked from network); 4 Apr 2019 02:14:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=543a.5ca56899.k1904; bh=JYHiKGfuvimZSCeLHemZ6BpGAT3vw7bqKWDtYGz7518=; b=efRbE/Hc7swfkmD6zhg5LggzM4CQ30sy93IA+gAMQ9LhsDCRn07IhjeAuN+OZXLMGm61DQ/m3sE1JaZ20jxDHLbxnIP7LbwslDfMyKavFtgPNhuM66KS+OuI0F21eBNDp/8S3IUoNBTK+g04nuApQtESTaZLeKg0uwX0gTbsePL/+Z8BFCICP8mktd3OwTj0ZL7/MHFnkT0He9uzBPdKdvBDadBbWN16IFwzk/3+p+bhIimgOtf30At3ZzHWQtyM
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; 04 Apr 2019 02:14:49 -0000
Date: 3 Apr 2019 22:14:48 -0400
Message-ID: <alpine.OSX.2.21.1904032148150.22920@ary.qy>
From: "John R. Levine" <johnl@iecc.com>
To: "Dave Crocker" <dcrocker@bbiw.net>
Cc: "tjw ietf" <tjw.ietf@gmail.com>, dbound@ietf.org
In-Reply-To: <a5f53382-b1f5-bf9b-aa3e-1fc2e93786f4@bbiw.net>
References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net> <alpine.OSX.2.21.1904031430270.21189@ary.qy> <7e61b445-3844-f769-6a59-16fa396388d0@dcrocker.net> <alpine.OSX.2.21.1904031459480.21189@ary.qy> <AFE01C0B-E47E-4D4E-B60C-FA0810BBE8F8@gmail.com> <310cc611-e1f0-2fbb-6efe-9d266869d025@dcrocker.net> <alpine.OSX.2.21.1904032056230.22661@ary.qy> <da2b2c91-8b9f-1254-d159-997bb77c1a9e@bbiw.net> <alpine.OSX.2.21.1904032126480.22887@ary.qy> <a5f53382-b1f5-bf9b-aa3e-1fc2e93786f4@bbiw.net>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/UaCjUoT4DhEcEGds2vFtL2agpk8>
Subject: Re: [dbound] [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2019 02:14:54 -0000

> Or perhaps you can point to the DNS specs and registries, showing where they 
> specify the constrained set of Additional responses that I'm calling for 
> modifying?  I'm not finding such a list.

This is getting very strange.

Your draft says:

    Another approach is use of the DNS Additional section in the server
    response.  When there is a query for a Perimeter node, the server
    would include the associated Perimeter BEGIN record from earlier in
    the hierarchy, if the queried node is within that hierarchy -- that
    is, is above the actual or virtual END record.  (As for any
    information supplied through the Additional section, the responding
    server will need to be modified to provide this enhanced information
    for specific kinds of queries.)

That bit in the parentheses, who does the modifying, and how does it get 
into the running versions of BIND and NSD and PowerDNS and all the other 
DNS servers and caches that people use?

Although now that I think about it, it won't work anyway.  For one thing, 
if you ask for _perim.a.b.c.tld, and there is only _perim.c.tld, the DNS 
response will be an NXDOMAIN and I don't think that DNS clients expect to 
find additional records in an NXDOMAIN response.  Or if we wave our hands 
some more and somehow make it a NODATA (positive response with no 
records), the fact that there's _perim.c.tld in the additional section 
doesn't mean that there wouldn't also be _perim.b.c.tld if you asked for 
it.  There's another whole set of failures if there's a zone cut between 
the name you ask for and the _perim above it.

So you're back to a tree walk, which is poor form in the DNS.

Don't take my word for it, ask in dnsop.  Or perhaps Tim has some 
opinions.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly