
Farsight Security® Inc.'s (now a part of DomainTools) Newly-Observed Domains (NOD) feed is available as Response Policy Zones (RPZ) which may be used to implement DNS firewalls.
Farsight Security processes hundreds of thousands of DNS resolutions persecond. They maintain a massive database of the observed domain namesand any new domain names feed the NOD service. It is common practice forthe malicious to register and use new domains for temporary abuse toavoid detection.
A Response Policy Zone contains DNS records that describe simple DNSfirewall rules and actions to perform. These are described usingstandard DNS records.
The Farsight RPZ rules only match again the newly-observed domain nameand a DNS wildcard for it (for any record types). The only actiondefined in the Farsight RPZ is to return a DNS NXDOMAIN to any query forthat domain name (or under it) indicating it does not exist. This makesthe new domain name not resolve, effectively disabling its use byclients using the DNS resolver using the RPZ feed.
Farsight publishes seven RPZ zones for increasing amounts of time thatthe newly-observed domain was first identified, The time periods are: 5minutes, 10 minutes, 30 minutes, 1 hour, 3 hours, 12 hours, and 24hours. The number of new domains range from a few hundred within thefirst five minutes and a few hundred thousand in the day long RPZ. Thesezones are updated every minute to add new entries andto expire old.
The RPZ zones are normal DNS zones. Customers configure their nameserver as a secondary zone (aka slave) for one or more RPZ feeds. Theinitial zone transfer uses the DNS AXFR protocol and then later updatesmay use IXFR (incremental) transfers. Farsight's name server can sendDNS NOTIFY messages to the customer's name servers when it has RPZupdates for near-real-time updates. This communication is authenticatedand secured using DNS TSIG.
The DNS Firewall rules as provided by Farsight Security are stored usingDNS records within a DNS zone. The SOA record's serial number is thetimestamp of the last zone file update as represented in Unix Epoch timeformat (number of seconds since Jan. 1, 1970 00:00:00 UTC).
The RPZ specification is in a work-in-progress Internet Draft (https://tools.ietf.org/html/draft-ietf-dnsop-dns-rpz-00).
While the DNS Response Policy Zones (RPZ) specification has severalpolicy triggers and actions, the Farsight Security RPZ zones only usethe QNAME Trigger (including wildcards) and the NXDOMAIN Action.
An example hosted by Farsight Security is:
sebaceoushelp.com IN CNAME . ; first_seen=1533314880
*.sebaceoushelp.com IN CNAME . ; first_seen=1533314880
And the transferred records:
sebaceoushelp.com.24h.rpz.dns-nod.net. 300 IN CNAME .
*.sebaceoushelp.com.24h.rpz.dns-nod.net. 300 IN CNAME .
(Note that the comments are not part of the DNS and aren't transferredalong with the zone updates.)
Common deployments using the Farsight-enabled RPZ zones as a DNSfirewall include: mail servers to reject incoming emails from NODsenders, spam filters to score and/or reject emails containing links toNOD websites, and for web browsers to stop access to very new websites.
The one-day period should be long enough for various reputation servicesto analyze the new domain to see if it has legitimate use. With thedifferent time-based RPZ zones, customers may experiment and choose thebest feed to match their needs.
Farsight's NOD offerings also includes DNSBL blacklist feeds as DNSzones files and DNSBL service via normal DNS queries.
Typical use cases of the RPZ feeds are:
The RPZ feeds are only accessible via DNS zone transfers. Access isrestricted to customer-provided IP addresses and using TSIG with apre-assigned HMAC-SHA512 key.
Farsight does not provide a DNS server for continual queries utilizingthe RPZ feed. (Farsight does for DNSBL though, based on the same NODdata.)
Customers may provide one or more IP addresses of a DNS server that canhandle DNS NOTIFY messages to speed up the transfers. The zone file'srefresh timer is set to ten minutes. If a zone refresh fails, it willretry. every five minutes (until it expires in one day). Depending onthe feeds, the DNS NOTIFY messages may happen a few times a minute toprompt the server to attempt to refresh the zone for updates.
This service is data transferred onto a customer's DNS servers, so thereis no additional hardware requirement.
The amount of data in the feed will vary over time.
The IXFR zone transfers may happen a few times a minute, depending onwhich RPZ feed is enabled. For example, the one-hour or 24-hour feedsmay have incremental transfers from 20 records (666 bytes) to 8822records (189652 bytes). The following is a snapshot of typical zone filesizes:
53K 5m.rpz.dns-nod.net (456 NODs)
110K 10m.rpz.dns-nod.net (931 NODs)
392K 30m.rpz.dns-nod.net (3416 NODs)
823K 1h.rpz.dns-nod.net (7280 NODs)
2.3M 3h.rpz.dns-nod.net (21062 NODs)
16M 12h.rpz.dns-nod.net (151147 NODs)
24M 24h.rpz.dns-nod.net (223710 NODs)
The RPZ technology is commonly used in a caching recursive nameserver.It is supported in ISC's BIND named, the Knot DNS Resolver, and thePowerDNS Recursor.
The NOD feeds do contain honest or non-malicious domains. Use of the RPZrules does make them unaccessible by name for the time period of the RPZfeed.
Farsight Security will provide configuration examples for BIND using itsnative RPZ or for using its FastRPZ. This configuration will include theIP addresses for the Farsight Security name servers to communicate withand the associated private shared secret for accessing the zone(s).
Additionally, Farsight Security provides a proprietary technology calledFastRPZ which provides an interface for a custom Unbound (via a patchshipped with Unbound) and special-built BIND (using the DNS ResponsePolicy Service API) to use this FastRPZ an alternative. This FastRPZprovides a simple DNS transfer server to maintain the RPZ feeds andhooks for the resolving name server to trigger and act on the DNSfirewall rules.
The RPZ feeds include a testing record which may be used for verifying aworking RPZ setup. A DNS query for test.dns-nod.net should result in aNXDOMAIN with a SOA indicating it came from a specific RPZ (with theepoch timestamp in the SOA).