[RPZ] Comments on ISC-TN-2010-1, and some questions [long, sorry]

Rich Kulawiec rsk at gsp.org
Wed Oct 6 16:03:53 UTC 2010


This is a set of comments of ISC-TN-2010-1.  Because the draft is
relatively brief, I've left the entire document intact and just
inserted my comments, in-line and exdented.  I've included some
general comments and questions below this marked-up version.






   ISC-TN-2010-1                                           Paul Vixie, ISC
   July-2010 (Draft 1)                           Vernon Schryver, Rhyolite

                     DNS Response Policy Zones (DNS RPZ)

   ISC Technical Note Series

      This memo describes a methodology in use inside ISC which may be of
      use to other members of the Internet technical community.

      Use of the methods and formats depicted herein is free of any and all
      license or other encumberance.

   Copyright Notice

      Copyright (C) Internet Systems Consortium, Inc. (2010).
      All Rights Reserved.

      Distribution of this memo is unlimited, if full attribution is given.

   Abstract

      This memo describes a method for expressing DNS response policy
      inside a specially constructed DNS zone, and for processing the
      contents of such zones inside recursive name servers.

s/and for processing.*/and for using the contents of such zones to
modify the query responses returned by recursive name servers.

      These response
      policis are intended for use in fighting e-crime, since all Internet
      crime relies on DNS and most domains in existence at the time of this
      writing are malicious.

1. Personal peeve: e-anything.  I try to remind myself to write "mail"
and not "email" but I know I slip up.  A lot.

2. Less personal critique: a lot of what the three of us (and colleagues)
would agree is wrong, abusive, unethical, sleazy, etc. isn't actually
criminal.  Moreover, what's criminal "here" isn't criminal "there".  So I'll
argue that "crime" isn't the right word.

3. Not all Internet crime relies on DNS.

4. While I strongly concur that most domains in existence at the moment
are involved in some kind of malicious activity, I'm not sure that
this expression of opinion should be in this document.

   1 - Overview

   1.1. This memo specifies a method of expressing DNS policy information
   inside a specially constructed DNS zone, allowing cooperating DNS
   reputation data producers and consumers to cooperate in the application
   of such policy to real time DNS responses.  In effect this does for
   recursive DNS servers what the anti-spam DNSBL (DNS Block List, ne RBL)
   and RHSBL (Right Hand Side Block List) technologies do for e-mail
   servers.  Under this technology regime, DNS resolution for low-
   reputation domain names can be deliberately made to fail or can be
   deliberately made to return local data such as an alias to a "walled
   garden".  No support is offered for NXDOMAIN remapping ("typo-
   squatting") or any other data-dependent policy.  A full description of
   the expressible policies is given below in Section 2.

s/real time/real-time/
s/ne RBL/nee RBL/
s/Under this technology regime/Using this DNS policy information/


   Vixie & Schryver                   ISC                          [Page 1]

   ISC-TN-2010-1           DNS Response Policy Zones    July-2010 (Draft 1)


   1.2. Configuration examples using ISC BIND Version 9 (BIND9) will be
   given, since this technology has already been implemented on that
   platform.  We expect other recursive DNS implementations to also
   implement these features since the technology is completely unencumbered
   and since the power of a multi-producer multi-consumer multi-vendor
   market to fight e-crime will be much stronger than any single-producer
   or single-vendor market could ever be.  ISC's goal for DNS RPZ is a new
   global market in DNS reputation data, since all e-crime relies on DNS
   and since most domain names in existence at the time of this writing are
   purely malicious.

s/multi-consumer//	(because then the multi-* adjectives match up,
and because I don't see how multiple consumers strengthen the market.
They certainly benefit themselves by using this resource, but I don't
think they help anyone else.)

I'm uncomfortable with "fight e-crime" because again, much of what we
might all concur is malicious activity is not actually a crime.  I think
I would s/fight e-crime/suppress malicious activity/ or similar.

I would strike the last sentence, because it talks about a goal -- which
is certainly a valid goal and a nice goal and a goal I agree with, but
I think that's a matter of ISC policy/position and not a matter for
this standard.  I think perhaps I might say this: "DNS RPZ is capable
of facilitating a market in DNS reputation data."

   2 - Zone Format

   2.1. A DNS Response Policy Zone is at heart a DNS zone, and as such it
   can be transferred between servers (DNS AXFR/IXFR), protected by
   transaction signatures (DNS TSIG), and expedited by real time change
   notifications (DNS NOTIFY).  As a DNS zone it is required to have an SOA
   record and at least one NS record at its apex.  The SOA record is real,
   having a serial number used for NOTIFY and IXFR, and having various
   timers used for AXFR.  However, the NS record will never be used, and no
   parent delegation is required.  By convention, a single NS record having
   the bogus value "LOCALHOST." is provided as a placeholder.

s/is at heart/is an instance of/
s/As a DNS zone/As a DNS zone,/
s/having a serial number/with a serial number/
s/having various timers/with various timers/
s/having the bogus value/with the deliberately-bogus value/

   2.2. The remainder of the zone is expressions of DNS policy.  The owner
   name of a Response Policy Zone resource record set (RRset) is the
   relativised name of the domain name about which policy is being
   expressed.  For example, in a policy zone called RPZ.ISC.ORG, an RRset
   at WWW.VIX.COM.RPZ.SIE.ISC.ORG would affect responses to lookups of
   WWW.VIX.COM.  DNS RPZ RRset owner names can be wildcarded according to
   normal rules, for example *.VIX.COM.RPZ.ISC.ORG would affect responses
   for any subdomain of VIX.COM.  This means that in order to affect both a
   domain and its subdomains, policy must be entered for both that domain
   and its wildcard subdomain.

s/zone is expressions of/zone consists of expressions of/
s/WWW.VIX.COM.RPZ.SIE.ISC.ORG/WWW.VIX.COM.RPZ.ISC.ORG/		(typo?)

I suggest using example.com et.al. instead of of isc.org or vix.com.

Does the wildcard mechanism recursively affect subdomains,
sub-subdomains, etc.?

   2.3. Four possible policies can be expressed, with these encodings:

   2.3.1. NXDOMAIN.  An RRset consisting of a single CNAME whose target is
   the root domain (.) will cause a response of NXDOMAIN to be returned.

Suggest adding example.

   2.3.2. NODATA.  An RRset consisting of a single CNAME whose target is
   the wildcard top-level domain (*.) will cause a response of NODATA
   (ANCOUNT=0) to be returned regardless of query type.

Suggest adding example.

   2.3.3. Exception.  An RRset consisting of a single CNAME whose target is
   the query name itself, will prevent any policy action from this RPZ.



   Vixie & Schryver                   ISC                          [Page 2]

   ISC-TN-2010-1           DNS Response Policy Zones    July-2010 (Draft 1)


   This can be necessary in the presence of a wildcard that would otherwise
   match a query name.

Suggest adding example.

   2.3.4. Local data.  An RRset matching the QTYPE of the original query
   will be returned.

Suggest adding example.

   3 - Subscriber Behaviour

   3.1. In ISC BIND Version 9 (BIND9), the RPZ feature is enabled by an
   option called "response-policy" at the global or per-view level.  For
   example:

s/For example:/Only one instance of the "response-policy" option may appear
at each such level.  For example:/

      options {
           // other stuff
           response-policy { zone "dns-policy.vix.com"; };
      };

   One or more RPZs can be specified in the single response-policy
   statement allowed at the global level and in each view.  These RPZs will
   be tested in left to right order.

Suggest adding example of two or three RPZs.

   3.2. Designated RPZs must be primary or secondary zones, since RPZs
   cannot be queried on the wire, only searched in the recursive server's
   own storage.  By implication, a "zone" statement must therefore be given
   for the RPZ, with all necessary "masters" clauses, each having all
   necessary "key" subclauses.

s/cannot be queried on the wire/cannot be queried in the same way that
other zones may be queried/

I'm not entirely happy with that rephrasing either.

   3.2. A match in any defined RPZ will pre-empt normal query processing.

s/normal query processing/normal query processing and will cause the
response specified for that match in the RPZ to be returned/

   So, it is not possible to use a wildcard RPZ element to implement
   NXDOMAIN remapping (sometimes called "typo-squatting"), or any other
   data-dependent policy.  DNS RPZ acts based on query name and query type
   alone.

s/So, /Therefore /

   4 - Producer Behaviour

   4.1. Any existing data feed capable of producing an RHSBL can be
   trivially used to generate a DNS RPZ.  If the desired policy is to alias
   all e-crime domains to a local walled garden, then for each domain name,
   generate the following records, one for the name itself, and perhaps
   also one for its subdomains:


      bad_domain     CNAME     walled-garden.isp.net.
      *.bad_domain   CNAME     walled-garden.isp.net.

s/generate the following records/one should generate the following records/

s/perhaps also one for its subdomains/perhaps also a wildcard for its subdomains/

Same comments in re "e-crime" as before, and I think I'll stop
harping on it now.  Also use example.net instead of isp.net.

   If on the other hand it's desireable to return NXDOMAIN for each domain



   Vixie & Schryver                   ISC                          [Page 3]

   ISC-TN-2010-1           DNS Response Policy Zones    July-2010 (Draft 1)


   (and its subdomains, in this example):

      bad_domain     CNAME     .
      *.bad_domain   CNAME     .

   Or if there are specific walled gardens for e-mail vs. everything else:

      bad_domain     MX      0 wgmail.isp.net.
      bad_domain     A       192.168.6.66
      *.bad_domain   MX      0 wgmail.isp.net.
      *.bad_domain   A       192.168.6.66

Suggest adding a comment about why one might want to choose this
particular configuration.

   4.2. In the data feed for e-crime domains, each addition or deletion or
   expiration can be handled using DNS UPDATE (see RFC 2136) in order to
   trigger normal DNS NOTIFY and subsequent DNS IXFR activity which can
   keep the subscribing servers well synchronized to the master RPZ.
   Alternatively, the RPZ master server can turn on "ixfr-from-differences"
   in order to generate DNS NOTIFY and subsequent DNS IXFR after the "rndc
   reload" action that ought to accompany each new generation of a RPZ on
   the master server.

Suggest referring back to 2.1 and reminding readers that this works
because the RPZ zone is (in one sense) just another zone.

   4.3. The master server should list all subscribers with "also-notify"
   for the RPZ, in order to ensure that DNS NOTIFY messages are sent.
   Otherwise DNS NOTIFY will only be sent to servers listed in the RPZ's
   apex NS RRset, which will be a placeholder (see Section 2.1).
   Furthermore, since DNS NOTIFY is a lazy protocol, every zone change
   should be accompanied by an "rndc notify" action to force immediate
   propagation of that change.

   4.4. Large numbers of subscribers may require a hierarchical RPZ
   distribution network consisting of one or more RPZ master servers who
   feed a set of intermediate RPZ stealth slave servers who in turn feed
   sets of subscribers.

Why "stealth"?  (I think I know the answer, or least, *an* answer
to this, but will argue that if the word is used here then some
explanation of why is appropriate.)

   4.5. In all cases, subscribers will need to set their RPZ "masters" to
   include all possible RPZ masters from whom DNS NOTIFY requests might be
   received.

   4.6. It's strongly recommended that DNS TSIG be used to both restrict
   access to a RPZ (so that only subscribers can access it) and
   authenticate a producer (so that only the actual producer can generate
   and publish it.)

Suggest adding an example.





   Vixie & Schryver                   ISC                          [Page 4]

   ISC-TN-2010-1           DNS Response Policy Zones    July-2010 (Draft 1)


   4.7. A data producer with a diverse subscriber base may find that some
   of their subscribers want an NXDOMAIN policy and others will want a
   walled garden approach.  There are two solutions here, one is to have
   each subscriber do a local transform of the base NXDOMAIN policy into a
   local walled garden policy, the other is to offer per-subscriber walled
   garden editions of an RPZ for an extra fee.

s/two solutions here,/two possible solutions:/
s/for an extra fee//		(because I don't think that pricing
			guidance needs to be part of this)

   5 - Acknowledgements

   Many folks have been asking for this for many years.  Barry Greene
   deserves special credit for unsticking this idea and championing the
   public release of this technology.

   Vixie & Schryver                   ISC                          [Page 5]



General comments:

1. As far as I can tell, this mechanism will work at the TLD level, e.g.:

      info     MX     walled-garden.example.net.
      *.info   MX     walled-garden.example.net.

will cause all mail to .info domains to be redirected to the walled
garden.  Am I correct?

2. Is there an exception mechanism?  Here's why I'm asking.  One of
things that we might want to do is to treat the (massively infected)
subscribers of a consumer ISP differently than the ISP itself; thus
we may want to have a policy that treats "*.dsl.example.net" differently
than "example.net".  Now...I realize that this particular example
can be handled by creating a RPZ for dsl.example.net, and then
maybe another RPZ for cable.example.net, and another for mobile.example.net;
but not all consumer ISPs provide such a nice, neat demarcation between
their customers and themselves.  In those unfortunate instances, it may
be simpler to enumerate just the resources controlled by the ISP itself
and presume that everything else is under the control of end users.

Perhaps I'm just not seeing how to use this properly and there's a
simpler way than "use an exception mechanism".

3. As Eric pointed out this morning, best practices for DNSBLs et.al.
have been covered in a document produced via the IETF ASRG (Lewis
and Sergeant).  I think a best practices document for this may
be appropriate, and I think it could take a lot of guidance from
that one, but I think it should be separate from this document.

4. I don't see any need to worry *here* about policy questions like "who
might use it?" and "what should be in it?".  Someone may want to create
an RPZ which enumerates "domains with the letter 'q' in them" because
it pleases them to do so.  And if there's a market for it, why not?
Or even if there isn't: why not?   As we've seen, any resource with
sufficiently dubious or inconsistent policies will not be widely used
beyond the purview of its creators.

This includes questions like "how does one appeal a listing?" -- because
it's not necessary that any mechanism for that exist.  (For example:
if I decide to create an RPZ which lists *.info, then there are no valid
appeals.  Ever.  There are zero false positives.  It's thus not necessary
to have a mechanism for them.  One could argue that this is a silly RPZ
or a bad RPZ or an insane RPZ, and those things may be true, but it's as
technically valid an RPZ as any other.  And of course if everyone agrees
that it's silly or bad or insane, then no one will use it anyway.)

5. Do we have any feel for the performance and scalability of this
mechanism?  (I ask in part because I think the number of extant
malicious domains is easily in the tens of millions, and that number
could spike quickly if any sufficiently-attractive new gTLD is launched.)


---rsk



More information about the DNSfirewalls mailing list