Examine individual changes
Appearance
This page allows you to examine the variables generated by the Edit Filter for an individual change.
Variables generated for this change
Variable | Value |
---|---|
Edit count of the user (user_editcount ) | 1 |
Name of the user account (user_name ) | 'Peter W. D. Davies' |
Age of the user account (user_age ) | 40238705 |
Groups (including implicit) the user is in (user_groups ) | [
0 => '*',
1 => 'user'
] |
Rights that the user has (user_rights ) | [
0 => 'createaccount',
1 => 'read',
2 => 'edit',
3 => 'createtalk',
4 => 'writeapi',
5 => 'viewmywatchlist',
6 => 'editmywatchlist',
7 => 'viewmyprivateinfo',
8 => 'editmyprivateinfo',
9 => 'editmyoptions',
10 => 'abusefilter-log-detail',
11 => 'urlshortener-create-url',
12 => 'centralauth-merge',
13 => 'abusefilter-view',
14 => 'abusefilter-log',
15 => 'vipsscaler-test',
16 => 'collectionsaveasuserpage',
17 => 'reupload-own',
18 => 'move-rootuserpages',
19 => 'createpage',
20 => 'minoredit',
21 => 'editmyusercss',
22 => 'editmyuserjson',
23 => 'editmyuserjs',
24 => 'purge',
25 => 'sendemail',
26 => 'applychangetags',
27 => 'spamblacklistlog',
28 => 'mwoauthmanagemygrants'
] |
Whether the user is editing from mobile app (user_app ) | false |
Whether or not a user is editing through the mobile interface (user_mobile ) | false |
Page ID (page_id ) | 36935800 |
Page namespace (page_namespace ) | 0 |
Page title without namespace (page_title ) | 'Response policy zone' |
Full page title (page_prefixedtitle ) | 'Response policy zone' |
Edit protection level of the page (page_restrictions_edit ) | [] |
Last ten users to contribute to the page (page_recent_contributors ) | [
0 => 'Peter W. D. Davies',
1 => 'Newtonke',
2 => 'Ale2006',
3 => 'Orville',
4 => '195.77.128.141',
5 => 'Doit-right2019',
6 => 'Newslinger',
7 => '76.102.18.33',
8 => 'GermanJoe',
9 => '174.212.12.51'
] |
Page age in seconds (page_age ) | 239748850 |
Action (action ) | 'edit' |
Edit summary/reason (summary ) | 'remove bad ref' |
Old content model (old_content_model ) | 'wikitext' |
New content model (new_content_model ) | 'wikitext' |
Old page wikitext, before the edit (old_wikitext ) | '{{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]]
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 (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==
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>
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=ftp://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>https://deepthought.isc.org/article/AA-00525/110/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html</ref><ref>https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/</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.
==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==
{{Portal|Free and open-source software}}
* [[Google Safe Browsing]]
* [[BIND]]
* [[DNS management software]]
==References==
{{Reflist}}
==External links==
* [http://www.circleid.com/posts/20100728_taking_back_the_dns/ The original blog post (Paul Vixie)]
* [http://www.isc.org/files/imce/DNSRPZ-2011-03-01-Webinar.pdf Slides with more detail (Paul Vixie)]
* [http://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone Spamhaus' RPZ data feed information]
* [https://kb.isc.org/docs/aa-00525 Building DNS Firewalls with Response Policy Zones]
[[Category:DNS software]]
[[Category:Free network-related software]]' |
New page wikitext, after the edit (new_wikitext ) | '{{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]]
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 (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==
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>
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=ftp://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>https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/</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.
==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==
{{Portal|Free and open-source software}}
* [[Google Safe Browsing]]
* [[BIND]]
* [[DNS management software]]
==References==
{{Reflist}}
==External links==
* [http://www.circleid.com/posts/20100728_taking_back_the_dns/ The original blog post (Paul Vixie)]
* [http://www.isc.org/files/imce/DNSRPZ-2011-03-01-Webinar.pdf Slides with more detail (Paul Vixie)]
* [http://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone Spamhaus' RPZ data feed information]
* [https://kb.isc.org/docs/aa-00525 Building DNS Firewalls with Response Policy Zones]
[[Category:DNS software]]
[[Category:Free network-related software]]' |
Unified diff of changes made by edit (edit_diff ) | '@@ -9,5 +9,5 @@
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>
-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=ftp://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>https://deepthought.isc.org/article/AA-00525/110/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html</ref><ref>https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/</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=ftp://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>https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/</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.
@@ -51,5 +51,7 @@
* [http://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone Spamhaus' RPZ data feed information]
* [https://kb.isc.org/docs/aa-00525 Building DNS Firewalls with Response Policy Zones]
+
+
[[Category:DNS software]]
[[Category:Free network-related software]]
' |
New page size (new_size ) | 6185 |
Old page size (old_size ) | 6307 |
Size change in edit (edit_delta ) | -122 |
Lines added in edit (added_lines ) | [
0 => '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=ftp://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>https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/</ref>',
1 => '',
2 => ''
] |
Lines removed in edit (removed_lines ) | [
0 => '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=ftp://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>https://deepthought.isc.org/article/AA-00525/110/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html</ref><ref>https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/</ref>'
] |
All external links added in the edit (added_links ) | [] |
All external links removed in the edit (removed_links ) | [
0 => 'ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt',
1 => 'https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/',
2 => 'https://deepthought.isc.org/article/AA-00525/110/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html'
] |
All external links in the new text (all_links ) | [
0 => 'https://tools.ietf.org/html/vixie-dnsop-dns-rpz#section-10',
1 => 'https://tools.ietf.org/html/vixie-dnsop-dns-rpz',
2 => 'https://www.isc.org/docs/BIND_RPZ.pdf',
3 => '//www.google.com/search?as_eq=wikipedia&q=%22Response+policy+zone%22',
4 => '//www.google.com/search?tbm=nws&q=%22Response+policy+zone%22+-wikipedia',
5 => '//www.google.com/search?&q=%22Response+policy+zone%22+site:news.google.com/newspapers&source=newspapers',
6 => '//www.google.com/search?tbs=bks:1&q=%22Response+policy+zone%22+-wikipedia',
7 => '//scholar.google.com/scholar?q=%22Response+policy+zone%22',
8 => 'https://www.jstor.org/action/doBasicSearch?Query=%22Response+policy+zone%22&acc=on&wc=on',
9 => 'http://www.circleid.com/posts/20100728_taking_back_the_dns/',
10 => 'http://www.isc.org/files/imce/DNSRPZ-2011-03-01-Webinar.pdf',
11 => 'http://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone',
12 => 'https://kb.isc.org/docs/aa-00525'
] |
Links in the page, before the edit (old_links ) | [
0 => '//scholar.google.com/scholar?q=%22Response+policy+zone%22',
1 => '//scholar.google.com/scholar?q=%22Response+policy+zone%22',
2 => '//www.google.com/search?&q=%22Response+policy+zone%22+site:news.google.com/newspapers&source=newspapers',
3 => '//www.google.com/search?&q=%22Response+policy+zone%22+site:news.google.com/newspapers&source=newspapers',
4 => '//www.google.com/search?as_eq=wikipedia&q=%22Response+policy+zone%22',
5 => '//www.google.com/search?as_eq=wikipedia&q=%22Response+policy+zone%22',
6 => '//www.google.com/search?tbm=nws&q=%22Response+policy+zone%22+-wikipedia',
7 => '//www.google.com/search?tbm=nws&q=%22Response+policy+zone%22+-wikipedia',
8 => '//www.google.com/search?tbs=bks:1&q=%22Response+policy+zone%22+-wikipedia',
9 => '//www.google.com/search?tbs=bks:1&q=%22Response+policy+zone%22+-wikipedia',
10 => 'ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt',
11 => 'http://www.circleid.com/posts/20100728_taking_back_the_dns/',
12 => 'http://www.isc.org/files/imce/DNSRPZ-2011-03-01-Webinar.pdf',
13 => 'http://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone',
14 => 'https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-rpz/',
15 => 'https://deepthought.isc.org/article/AA-00525/110/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html',
16 => 'https://kb.isc.org/docs/aa-00525',
17 => 'https://tools.ietf.org/html/vixie-dnsop-dns-rpz#section-10',
18 => 'https://tools.ietf.org/html/vixie-dnsop-dns-rpz',
19 => 'https://www.isc.org/docs/BIND_RPZ.pdf',
20 => 'https://www.jstor.org/action/doBasicSearch?Query=%22Response+policy+zone%22&acc=on&wc=on'
] |
Whether or not the change was made through a Tor exit node (tor_exit_node ) | false |
Unix timestamp of change (timestamp ) | 1586683869 |