Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

From: Avri Doria <[email-masked]>
Date: Sun, 8 Jan 2017 15:26:05 -0500

Hi,

Finally had a chance to read all of it.  While I understand that it can
be used to create enclaves, I think it can also be used in useful ways
to increase the flexibility of the DNS system, e.g. for example possibly
to avoid some of the problems we see from occasional name collision.

I would very much like to see it well documented.  And if it is
politically too difficult to standardize, informational is good enough.

avri

On 20-Dec-16 10:16, tjw ietf wrote:
> Why not just wade into this discussion...
>
> The draft is being present as "Informational", and the point here is
> to document current working behavior in the DNS (for the past several
> years).   It is obvious that some feel this draft is a large mistake,
> but like edns-client-subnet, more operators are deploying this than
> one is aware of. 
>
> This starts a Call for Adoption for draft-vixie-dns-rpz
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/
>
> Please review this draft to see if you think it is suitable for
> adoption by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> With the holiday period upon us, we'll make this a three week call for
> adoption. This call for adoption ends on 10 January 2017
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
[email-masked] is going out of use in the near future.
Please switch to [email-masked]

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: 神明達哉 <[email-masked]>
Date: Mon, 9 Jan 2017 13:23:41 -0800

On Tue, Dec 20, 2016 at 7:16 AM, tjw ietf <[email-masked]> wrote:

> The draft is being present as "Informational", and the point here is to
> document current working behavior in the DNS (for the past several years).
> It is obvious that some feel this draft is a large mistake, but like
> edns-client-subnet, more operators are deploying this than one is aware of.
>
> Please review this draft to see if you think it is suitable for adoption by
> DNSOP, and comments to the list, clearly stating your view.

I'm still reading the 04 version of draft-vixie-dns-rpz and intending
to make comments on it later, but I'd like to respond to the call
first: I do not think it's suitable for dnsop to adopt the draft in
its current form, with the intent of "just describing currently
deployed practice", and (as I guess) with the intent of eventually
publishing as an (Informational) RFC.

But I think the document itself is very useful, so it would be nice if
it's made more publicly available in other form, e.g., some
white-paper kind or at a popular blog site.  If the adoption means
polishing the document for that goal (although I don't think it's the
intent for this call), I'd support it.

Also, if we're really willing to work on a "standard, interoperable
DNS firewall specification" without worrying about substantially
changing the current practice/implementation, and if the adoption
means the first step for that goal (and so the final publication could
be totally different and may not be compatible with the existing
standard), then I'd support it.  But, again, I suspect that's not the
intent of this call.

Some more specific rationale for this opinion below:

- As I believe most people, and perhaps including the draft authors or
  RPZ implementations, agree, it's an ugly hack to use the standard
  DNS zone to represent the firewall rules.  It might have been a
  convenient way to implement the idea initially (e.g, we can use the
  zone transfer behavior to distribute the rules), but I don't see an
  essential reason why these are represented as DNS RRs.  And, (again
  as I believe everyone knows) it's not just ugly but also has some
  inherent flaws, such as that not all domain names can be represented
  due to length limitation.  In fact, not all existing implementations
  of RPZ-like feature use this form as the primary way of rule
  configuration (unbound is one example I happen to know of, and from
  a quick look knot resolver also seems to adopt its own configuration
  syntax).  Perhaps operators of these implementations use some
  conversion tools form the "standard" RPZ policies to its internal
  form, but that's obviously inconvenient.  Standardizing the spec
  more officially eventually leads to unified configuration (at least
  in concept) to eliminate the need for such a tool, but it would
  require changes to other existing implementations anyway.  Then it
  would be far better to develop a better form of policy
  representation from the beginning.

- If this is to be published as an IETF standard (even if
  "informational") and especially as a product of the dnsop wg, I
  believe it should contain more DNSSEC-related considerations.  The
  current situation is either
  + validly DNSSEC-signed responses bypass RPZ policies (when
    'break-dnssec' is set to no), or
  + 'break-dnssec' is enabled, and it would currently confuse
    validating stub resolvers
  As long as this wg hopes to see more such stub resolvers deployed
  (I'm assuming so), any of its protocol work should IMO help such
  deployment rather than hinder it.

- I know the above points are about to be dismissed with "these are
  out of scope of this doc; it just describes what is currently
  deployed".  And that's exactly another big concern of mine,
  especially because I heard the adoption of this draft would be
  similar to that of edns-client-subnet.  At that time several wg
  participants including myself raised unclear or ambiguous points of
  the spec, some of which were based on attempts of implementing it.
  Sadly, though, many of them were effectively silenced with the
  excuse of "not in scope".  Another excuse at that time was that
  there would be another standard truck doc to fix these issues, but,
  as quite predictably, people seem to have lost interest/energy once
  the RFC was published and there doesn't seem to be any attempt of
  revising the spec.  I've already sensed the same thing could happen
  for draft-vixie-dns-rpz from the adoption discussions on this list,
  and I don't like to see it actually happen.  To be clear, "really
  just describing what is currently deployed" is fine for me.  But my
  lesson from edns-client-subnet it can't well coexist with the intent
  of having more interoperable implementations.  If the intent is
  purely former, then it's better to publish it somewhere else; if our
  intent is to promote interoperability starting with the spec and
  lessons of existing deployment, we should be willing to change the
  current spec.

--
JINMEI, Tatuya

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 23 Jan 2017 13:20:52 -0500

I've been following this discussion and have taken a few weeks to think
about the comments rendered here in some depth.  I find that I most agree
with this statement:

On Tue, Dec 20, 2016 at 10:53:39PM +0000, Warren Kumari wrote:
> I believe that RPZ (and the DNS lies which it creates) is evil --
> unfortunately we live in a world where this is a necessary evil.

I started studying the use of domains by spammers 15 years ago.
I expanded that study to phishers, typosquatters, domaineers, malware
distributors, etc. as it became excruciatingly clear that these are
quite often the same people or operations.  (See "Sanford Wallace"
for one of the canonical examples.)

It's become clear to me that most Internet domains are malicious.
In the new TLDs, "most" asymptotically approaches "all".

( If anyone doubts this, and you shouldn't unless you've done your own
homework, I'll be happy to show you some sample data.  Or you can spend
your morning coffee time for the next week idly perusing new additions to
zone files at https://domainpunch.com/tlds/daily.php and get the flavor
of it for yourself.  Popular this month: domains being used by boiler
room fake technical support operations who make phone calls designed to
convince users to handle over control of their systems.  They're being
registered much faster than I can track them. [1] )

This shouldn't surprise anyone who has even dabbled in the area.  Abusers
register domains by the tens or hundreds of thousands, burn through
them, then register more.  Registrars are happy to have high-volume
repeat customers, so while they may make a pretense of responsibility
by suspending a domain here or there, these are meaningless gestures
designed to placate complainers and support maintenance of a facade of
responsibility.  And in the extremely rare cases where registrars fire
a client, there are plenty of others ready to welcome them with open arms.

The situation is so bad that I think it's a best practice in mail system
operations to block quite a few of the new TLDs outright in MTAs and
make exceptions for specific domains if/when the need arises.

But even if that's done, it's an insufficient defense mechanism.   We need
a way to make huge numbers of domains effectively disappear from users'
view of the Internet -- and this may be it.

I don't like it.  This is not the Internet I would have chosen.

But I'm not the entity who has allowed registrars to profit handsomely off
the Internet's collective misery for a couple of decades, or the entity
who handed them a whole new way to do so by unleashing hundreds of TLDs for
which there is precisely zero need and precisely zero legitimate purpose,
or the entity which let them start obfuscating registration data -- one
of the best things that's ever happened to operators of malicious domains.

---rsk

[1] Here's a single data point, out of a huge number:

	http://www.firemountain.net/~rsk/online.txt

Those are *some* of the domains registered by one registrant in one TLD
in one day.  It's thus a speck on a microscopic speck, but I assure you
it's representative.