[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