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

"John R Levine" <johnl@taugh.com> Wed, 03 April 2019 18:45 UTC

Return-Path: <johnl@taugh.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 3B936120163 for <dbound@ietfa.amsl.com>; Wed, 3 Apr 2019 11:45:07 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=nVmUezbn; dkim=pass (1536-bit key) header.d=taugh.com header.b=mkR/I07n
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 6XqIF2JlrzJ2 for <dbound@ietfa.amsl.com>; Wed, 3 Apr 2019 11:45:04 -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 1049412013F for <dbound@ietf.org>; Wed, 3 Apr 2019 11:45:03 -0700 (PDT)
Received: (qmail 4640 invoked from network); 3 Apr 2019 18:45:02 -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=121e.5ca4ff2e.k1904; bh=RiWjXqdi02tRtFWsHlf5LML/zSn96MpMpbLP1+SIZbU=; b=nVmUezbnKNk554YMNKuTkUyX3Y67z4wPtq8jGogwjz5ZsWwg7SeKd5/8w33VlOzJBBeC6rYb0t8x6a5mDWfVBPy0WAD5UtAx+EnNk+xly5eJ0zkfEzQtO8j8nWdKcWOvcQ1OYqwd745VxPTXWHAXlco1k8yibLj3A69n5TzUC59A/hrFgbeqwGx5AZSH6HpHVKsyhgv7RQnmg3L/O3AuMJMU+N2fIGhCAELwxjNMnBV2wh03n+v7DNA009cWJ+K7
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=121e.5ca4ff2e.k1904; bh=RiWjXqdi02tRtFWsHlf5LML/zSn96MpMpbLP1+SIZbU=; b=mkR/I07nmTaHAfvqTrVzSVUQCbMZUovHINjOvdYiAE/ZnhPeRyAPMrSPn6e/aoOPm1dc6PVKArc7J4OE8P5CgWEzJBJwe3UMljYqQ8yg8m0aV1YXgtp5FQ30vIxOtY4oEQta+MNtY2JYeqsvMGLNyH3dVKT4l6XX/8CiYudR/S1cEnwvSJ/DrnA4JITrzccQsXlVOHodG7wTVEnmD8rE1JOeoev9oGtmKJdkYsiz/zbGcwQubpCdGr2RKASFII4d
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; 03 Apr 2019 18:45:02 -0000
Date: 3 Apr 2019 14:45:01 -0400
Message-ID: <alpine.OSX.2.21.1904031430270.21189@ary.qy>
From: "John R Levine" <johnl@taugh.com>
To: dcrocker@bbiw.net
Cc: dmarc@ietf.org, dbound@ietf.org
In-Reply-To: <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.net>
References: <20190403175820.8391420115F376@ary.qy> <2445c121-f77b-0fa2-ca6a-402479abb5a7@dcrocker.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/gtx_w4T57zf5SfgrspjdhLGVjhg>
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: Wed, 03 Apr 2019 18:45:07 -0000

On Wed, 3 Apr 2019, Dave Crocker wrote:
> Section 7's suggestion for using Additional information does not rely on 
> caching.
>
> Reliance on existing wildcard depends on propagation of a new RR, which 
> continues to be problematic.  There's a reason the Attrleaf table has so many entries...

Now we're having a discussion about which is the frying pan and which is 
the fire.

In my experience, these days getting a new rrtype that doesn't have extra 
semantics into DNS servers happens pretty quickly.  It's an entry in a 
table or a new short stylized parse/unparse routine.  DNS caches don't 
have to change at all. The problem is the web provisioning crudware, which 
is what I have tried with limited success to address with my DNS extension 
language work.  My dbound draft has no new DNS semantics, just ordinary 
wildcards and an ordinary rrtype.

To put anything into the additional section, you're asking the DNS servers 
to treat a _perim name specially if there are TXT records under the name 
and to go search through the zone to find the extra stuff and put it in 
the additional section.  DNS caches have to change too, to treat the 
additional stuff as non-hostile and pass it through, since caches throw 
away unrecongnized additional sections to prevent cache poisoning (the 
Kashpureff bug.)

You should run this by dnsop where I expect you'll get a great deal of 
pushback and references to the DNS Camel for anything with new semantics.

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