Re: [dmarc-ietf] [dbound] 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 4ACF712016D for <>; Wed, 3 Apr 2019 11:53:04 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bCAewJTZaczL for <>; Wed, 3 Apr 2019 11:53:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 016A212017C for <>; Wed, 3 Apr 2019 11:53:00 -0700 (PDT)
Received: by with SMTP id i207so10611509vsd.10 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=QscFUU24FkO8pvLWgJwco6LDK9krm2yojrWSaxMJCsocz1C9c7dwS8LXZg/4ueHGOO 1P3DMlhx+PPt0cKU9nSaZRdgKJXRk5pF6WjZHsy/e1I91WYCw+rDxPPBbUsj1McNF5rs kRPLOw9PpnfDUHBetCbtOxbzyTWZXE+nbJD22ZkU/mvfPlY91dLVaBYanxe1obTO9XoV 8deLaaT95gHeTjkeeKYvPDhRxIA7eTmJRYorWiEL+P+oMIyvHV2gOummbqBOt6U3J7Ws OlL1V1uj/yy0+odB792gPuV058KGoXRkKjJYp4Ueu9B/UBOElam3e3C6T1PL8GrmPjr5 z5+g==
X-Gm-Message-State: APjAAAVhKSECFzd2Gfe9Xoyhh9i1Z31+hnQejAtTg24B9wf+TXEnt6bH aYGrMnTXen9c8kJ773OjclwQg+MavyfxP4YRDgFyew==
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: [dmarc-ietf] [dbound] Fwd: New Version Notification for draft-dcrocker-dns-perimeter-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
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