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

Jothan Frakes <> Wed, 03 April 2019 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D067012019E for <>; Wed, 3 Apr 2019 11:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qw0WP7_iSke5 for <>; Wed, 3 Apr 2019 11:53:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0160912017B for <>; Wed, 3 Apr 2019 11:53:00 -0700 (PDT)
Received: by with SMTP id g127so10631375vsd.6 for <>; Wed, 03 Apr 2019 11:53:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TmN/qrPhRhV1GHX/Sn1HgNa+l66ldBWUCuTHxO6PdO4=; b=EGg3/sVfEi4QVDsYs3oojakuwOArbJQj8diDQu8pcfWE5uJATlHUTNtk9PFwcc3Jdg IsqD26gDAUtVNysBDDCKUvZqBsZ3ECPkZ1xdcA8bQqRGPZaNHaxwPie7x+a5RuZl0+eo x6AB7h4/lWV7fRpx+ocw9SVXQM6mVUfQEnWeDbk4W1UrRYlPrmlx8o/c37Fv2SG5YSdz 8+OowI0KcN1Uh6Gdh/CrAQffjSzDcIe+PVL33ZDcRRtbaS5HjdSYkqUBXAX+T3Gfo2pA GlKLY5hfWSd1LEF/1Ka1OWvXFkE/hYAOzI9hX9q6FP7WQo/TvJxcdBsoni6w6t5ITEFH BjCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TmN/qrPhRhV1GHX/Sn1HgNa+l66ldBWUCuTHxO6PdO4=; b=NGBoSkMpbj6kPbKl7I+Ba9wiMu5O7cVsnRE3IX7l5c+It5BAip1jMLSHw1TMW0REMQ wU8AnysdZLg86vP4cTH5YYcrJK7g2CGEPzb3T0xORdGROg1A9apXlZaokOaJGy9sa9L7 xqLCLaR8jDoqHZO+HV+bOBYnmofQcvoOl8M1aiQyVqtJeiOw/LFNAvE59rFNYq2hJa5e U5rw5biXgE8Q2gvxDaVdFYAsIstf66IL6Y+UG6ogDBI+MwHUgLDocUSo+5sTqGW8obja 6L+L4KRB27bnAbKxOIIKTuYxjFa2kjurml5nMhM2jL5aFBkoQ75Qucj46U6W65Eks36Q H5XQ==
X-Gm-Message-State: APjAAAWbI7r03SRkG8ZGHtz9mtT0XIpLsRlnOLoNZEoeGXqwzwK8p9qI NtD1wvF9RV+2or4sqlm0TjqL/aDzcSg5GYerXIw1tg==
X-Google-Smtp-Source: APXvYqyQd7Vo9aU1pH11vPWKShBswFBM+sGGCwIh1q8z2jRniO0mvlb4C+Xz2cugK15Fb+gGK6v9fpmezmiIX6jFYpE=
X-Received: by 2002:a67:eb41:: with SMTP id x1mr1449705vso.84.1554317579930; Wed, 03 Apr 2019 11:52:59 -0700 (PDT)
MIME-Version: 1.0
References: <> <20190403175820.8391420115F376@ary.qy>
In-Reply-To: <20190403175820.8391420115F376@ary.qy>
From: Jothan Frakes <>
Date: Wed, 3 Apr 2019 11:52:31 -0700
Message-ID: <>
To: John Levine <>
Cc:, Dave Crocker <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [dbound] [dmarc-ietf] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS tree bounds <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Apr 2019 18:53:04 -0000

I appreciate the time you invested in this Dave.   I definitely like
that we're thinking in terms of how to leverage DNS and its
distributed model vs emulating the hosts.txt situation, and PSL is
essentially a hosts.txt situation.

Some assert there is a benefit to being able to contain some form of
static list locally for speed.  This happens at the trade-off of
potentially stale data, which we experience as maintainers receiving
energy from expressive TLD admins describing their grief over their
domains being directed at search instead of resolving in DNS because
their pc, tablet or mobile device runs a browser software that did not
contain their TLD.

So in those cases (and potentially others) getting things into DNS
_might_ be better.  I think that a TLD administrator being able to
make direct updates in their own zones is vastly better because it
would both alleviate the arduous process of validating authority of
requests, and streamline the requesting process to near zero on their
updates, and enable more direct and exacting control by the registry

That said, we fail the community unless the potential replacements
take into consideration the many constituent / subjective uses of PSL
that have evolved across the years before we tick the box next to any
particular solution meeting the diverse needs.

We have to tread carefully here.  I have great respect for the IETF
and the many wise and noble experts that have donated their
experience, time and wisdom towards solutions and standards.  It is a
process that requires patience and I have been told by many in the
developer community that it is not always one that is inclusive or
able to meet the pace of some development cycles and product or
service evolution.

The PSL basically came into existence outside of the IETF process,
borne of real practical needs, and those needs have forked and

There is a 'lenticular' / perspective issue in how different
stakeholders are using the PSL.   PSL is included in software
libraries, which incorporate it without prescribing how a developer
might use it.  Some care only about the private section of the list,
some only about the "ICANN" section.  Some integrators of the PSL omit
certain elements, or even maintain their own supplementary sections
for their project or service needs.

Think it is safe to assert variety is present - each have an entirely
different need and application of some or all of the PSL's contents
than a browser program, search engine, security professional,
anti-spam, reporting, SSL Cert, or other use.

We (maintainers) don't prescribe specifically how it gets used as
volunteer community maintainers, we just try to guide community
entries and validate them (and focus on ICP-3 or other I* integrity).

PSL is expanding - which grows the file size each time.  As potential
solutions are presented from web developers or even the IETF (or both)
that might help to organize or better architect solutions that could
help PSL from heading towards something that emulates the transition
from the SRI hosts.txt challenges, I fear that unless we can ensure
that some of the dependencies are met by those proposals, the
proposals will not endure, and we'll remain using the PSL in a status
quo manner.

Jothan Frakes

On Wed, Apr 3, 2019 at 10:58 AM John Levine <> wrote:
> In article <> you write:
> >Comments eagerly sought, of course.
> This seems sorta kinda like my dbound draft, only with _tagged TXT
> records rather than a new rrtype, and (unless I missed something) a
> hope that somehow you can use a yet to be invented cache to avoid
> walking up the tree, where mine used wildcards to do one lookup per
> boundary regardless of the tree depth.
> I can see that the tradeoffs are different but I don't see why they're better.
> R's,
> John
> >A new version of I-D, draft-dcrocker-dns-perimeter-00.txt
> >has been successfully submitted by D. Crocker and posted to the
> >IETF repository.
> >
> >Name:          draft-dcrocker-dns-perimeter
> >Revision:      00
> >Title:         DNS Perimeter Overlay
> >Document date: 2019-04-02
> >Group:         Individual Submission
> >Pages:         20
> >URL:
> >
> _______________________________________________
> dbound mailing list