Jump to content

Response policy zone

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 2001:16b8:2c81:d100:2d27:b1dd:841d:3b65 (talk) at 13:34, 18 February 2021. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

DNS flow diagram
DNS response modification under policy restrictions

A response policy zone (RPZ) is a mechanism to introduce a customized policy in Domain Name System servers, so that recursive resolvers return possibly modified results. By modifying a result, access to the corresponding host can be blocked.

Usage of an RPZ is based on DNS data feeds, known as zone transfer, from an RPZ provider to the deploying server. With respect to other blocklist methods, such as Google Safe Browsing, the actual blocklist is not managed, not even seen, by the client application. Web browsers, and any other client applications which connect to servers on the Internet, need the IP address of the server in order to open the connection. The local resolver is usually a system software which in turn puts the query to a recursive resolver, which often is located at the Internet service provider. If the latter server deploys RPZ, and either the queried name or the resulting address are in the blocklist, the response is modified so as to impede access.

History

The RPZ mechanism was developed by the Internet Systems Consortium led by Paul Vixie as a component of the BIND Domain Name Server (DNS).[1] It was first available in BIND release 9.8.1 released 2010, and first publicly announced at Black Hat in July, 2010.[2]

The RPZ mechanism is published as an open and vendor-neutral standard for the interchange of DNS Firewall configuration information, allowing other DNS resolution software to implement it. [3][4]

RPZ was developed as a technology to combat the misuse of the DNS by groups and/or persons with malicious intent or other nefarious purposes. It follows on from the Mail Abuse Prevention System project which introduced reputation data as a mechanism for protecting against email spam. RPZ extends the use of reputation data into the Domain Name System.

Function

RPZ allows a DNS recursive resolver to choose specific actions to be performed for a number of collections of domain name data (zones).

For each zone, the DNS service may choose to perform full resolution (normal behaviour), or other actions, including declaring that the requested domain does not exist (technically, NXDOMAIN), or that the user should visit a different domain (technically, CNAME), amongst other potential actions.

As zone information can be obtained from external sources (via a zone transfer) this allows a DNS service to obtain information from an external organisation about domain information and then choose to handle that information in a non-standard manner.

Purpose

RPZ is essentially a filtering mechanism, either preventing people from visiting internet domains, or pointing them to other locations by manipulating the DNS answers in different ways.

RPZ provides the opportunity for DNS recursive resolver operators to be able to obtain reputational data from external organisations about domains that may be harmful, and then use that information to avoid harm coming to the computers that use the recursive resolver by preventing those computers from visiting the potentially harmful domains.

Mechanism and data

RPZ is a mechanism that needs data on which it is to respond.

Some Internet security organisations have offered data describing potentially dangerous domains early in the development of the RPZ mechanism. Others services also offer RPZ for specific domain categories (for example for adult content domains). A recursive resolver operator is also easily capable of defining their own domain name data (zones) to be used by RPZ.

Example of use

Consider that Alice uses a computer which uses a DNS service (recursive resolver) which is configured to use RPZ and has access to some source of zone data which lists domains that are believed to be dangerous.

Alice receives an email with a link that appears to resolve to some place that she trusts, and she wishes to click on the link. She does so, but the actual location is not the trusted source that she read but a dangerous location which is known to the DNS service.

As the DNS service realizes that the resulting web location is dangerous, instead of informing her computer how to get to it (unmodified response), it sends information which leads to a safe location. Depending on how the DNS service configures its policy actions, the modified response can be a fixed page on a web site which informs her of what has happened, or a DNS error code such as NXDOMAIN or NODATA, or send no response at all.

See also

References

  1. ^ Paul Vixie; Vernon Schryver (June 21, 2018). "History and Evolution". DNS Response Policy Zones (RPZ). IETF. sec. 10. I-D vixie-dnsop-dns-rpz.
  2. ^ Andrew Fried; Victoria Risk (9 May 2017). "Tutorial on Configuring BIND to use Response Policy Zones (RPZ)" (PDF). Internet Systems Consortium.
  3. ^ Paul Vixie; Vernon Schryver (December 2010). "DNS Response Policy Zones (DNS RPZ)". Internet Systems Consortium.
  4. ^ https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Response_policy_zone&oldid=1007502361"