Response policy zone: Difference between revisions
→Example of use: expand slightly |
No edit summary |
||
(17 intermediate revisions by 10 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Internet firewall mechanism for DNS}} |
|||
{{refimprove|date=January 2018}} |
{{refimprove|date=January 2018}} |
||
<!-- The svg version misses some text -->[[File:Response policy zone (raster).png|thumb|alt=DNS flow diagram|upright=1.35|DNS response modification under policy restrictions]] |
<!-- The svg version misses some text -->[[File:Response policy zone (raster).png|thumb|alt=DNS flow diagram|upright=1.35|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. |
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 |
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 (DNS)|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== |
==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).<ref>{{cite IETF |title=DNS Response Policy Zones (RPZ) |author1=Paul Vixie |author2=Vernon Schryver |draft=vixie-dnsop-dns-rpz |section=10 |sectionname=History and Evolution |date=June 21, 2018}}</ref> It was first available in BIND release 9.8.1 released 2010. |
The RPZ mechanism was developed by the [[Internet Systems Consortium]] led by [[Paul Vixie]] as a component of the [[BIND]] Domain Name Server (DNS).<ref>{{cite IETF |title=DNS Response Policy Zones (RPZ) |author1=Paul Vixie |author2=Vernon Schryver |draft=vixie-dnsop-dns-rpz |section=10 |sectionname=History and Evolution |date=June 21, 2018 |publisher=[[Internet Engineering Task Force|IETF]]}}</ref> It was first available in BIND release 9.8.1 released 2010, and first publicly announced at Black Hat in July, 2010.<ref>{{cite web |url=https://www.isc.org/docs/BIND_RPZ.pdf |author1=Andrew Fried |author2=Victoria Risk |date=9 May 2017 |title=Tutorial on Configuring BIND to use Response Policy Zones (RPZ) |publisher=[[Internet Systems Consortium]]}}</ref> It is also available in the [[Unbound (DNS server)|Unbound software]] as of version 1.14.0.<ref>{{cite web | title = Response Policy Zones | url = https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/rpz.html | work = Unbound Docs | publisher = NLnet Labs }}</ref> |
||
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. <ref> |
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. <ref>{{cite web |url=http://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt |title=DNS Response Policy Zones (DNS RPZ) |date=December 2010 |author1=Paul Vixie |author2=Vernon Schryver |publisher=[[Internet Systems Consortium]]}}</ref><ref>{{Cite news|url=https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/|title = Draft-ietf-dnsop-DNS-RPZ-00 - DNS Response Policy Zones (RPZ)| newspaper=Ietf Datatracker }}</ref> |
||
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 (electronic)|spam]]. RPZ extends the use of reputation data into the Domain Name System. |
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 (electronic)|spam]]. RPZ extends the use of reputation data into the Domain Name System. |
||
Line 42: | Line 43: | ||
* [[BIND]] |
* [[BIND]] |
||
* [[DNS management software]] |
* [[DNS management software]] |
||
* [[Quad9]] |
|||
==References== |
==References== |
||
Line 48: | Line 50: | ||
==External links== |
==External links== |
||
* [http://www.circleid.com/posts/20100728_taking_back_the_dns/ The original blog post (Paul Vixie)] |
* [http://www.circleid.com/posts/20100728_taking_back_the_dns/ The original blog post (Paul Vixie)] |
||
⚫ | |||
* [http://www.gcsec.org/sites/default/files/files/History%20of%20Network%20Reputation,%20from%20RBL%20to%20RPZ%20-%20lessons%20so%20far%20of%20MAPS%20and%20COICA%20-%20Paul%20Vixie.pdf Introductory slides with history (Paul Vixie)] |
|||
*[https://www.spamhaustech.com/product/dns-firewall/ Spamhaus' RPZ data feed information] |
|||
⚫ | |||
* [https://kb.isc.org/docs/aa-00525 Building DNS Firewalls with Response Policy Zones ] |
|||
* [http://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone Spamhaus' RPZ data feed information] |
|||
* [https://abuse.ch/blog/using-urlhaus-as-response-policy-zone-rpz/ Using URLhaus as a Response Policy Zone (RPZ)] |
|||
[[Category:DNS software]] |
[[Category:DNS software]] |
Latest revision as of 11:10, 2 August 2023
This article needs additional citations for verification. (January 2018) |
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
[edit]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] It is also available in the Unbound software as of version 1.14.0.[3]
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. [4][5]
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
[edit]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
[edit]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
[edit]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
[edit]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
[edit]References
[edit]- ^ Paul Vixie; Vernon Schryver (June 21, 2018). "History and Evolution". DNS Response Policy Zones (RPZ). IETF. sec. 10. I-D vixie-dnsop-dns-rpz.
- ^ Andrew Fried; Victoria Risk (9 May 2017). "Tutorial on Configuring BIND to use Response Policy Zones (RPZ)" (PDF). Internet Systems Consortium.
- ^ "Response Policy Zones". Unbound Docs. NLnet Labs.
- ^ Paul Vixie; Vernon Schryver (December 2010). "DNS Response Policy Zones (DNS RPZ)". Internet Systems Consortium.
- ^ "Draft-ietf-dnsop-DNS-RPZ-00 - DNS Response Policy Zones (RPZ)". Ietf Datatracker.