Network Working Group H. Connery, Ed. Internet-Draft Technical University of Denmark Intended status: Informational June 2013 Expires: December 3, 2013 DNSRPZ Feedback Zone Abstract DNS Response Policy Zone (RPZ) Feedback Zone (RPZ-FBZ) is a mechanism for an organisation using RPZ to provide feedback to anyone, though principally to the source RPZ zone maintainer, about how resource records in an RPZ zone are being used in DNS filtering. Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 3, 2013. Connery Expires December 3, 2013 [Page 1] Internet-Draft DNSRPZ Feedback Zone June 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Nomenclature . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. RPZ Data Flow . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Resource Records . . . . . . . . . . . . . . . . . . . . . 4 2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Mechanics . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Aging . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Frequency . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Informative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Connery Expires December 3, 2013 [Page 2] Internet-Draft DNSRPZ Feedback Zone June 2013 1. Introduction DNS Response Policy Zone (RPZ) [DNSRPZ] allows customizable DNS based filtering by recursive DNS resolvers. An implementation of RPZ may involve multiple data sources for use in DNS filtering. These zones may be internal and/or externally sourced. RPZ Feedback Zone (RPZ-FBZ) allows an organization using RPZ zones to gather information about how RPZ data is being used for DNS filtering within their organization and selectively make that information to others. 1.1. Nomenclature RPZ is a reputation data ecosystem in which domain name lookup is filtered for domains with a poor reputation. There are two key classes of actors in the use of RPZ. From the perspective of reputation data providers they are: o Organizations using RPZ to filter DNS: Reputation Data Consumers (RD-C) o Organisations supplying data to RD-C's: Reputation Data Providers (RD-P) 1.2. RPZ Data Flow RD-C's receive data from RD-P's which have derived their data from a collection of intelligence sources. +---------+ DNS +----------+ RPZ +------+ +---------+ | RD-C | <---> | RD-C | <------- | RD-P | <--- | RD-P | | Clients | Query | Resolver | Data | | | Sources | +---------+ +----------+ +------+ +---------+ RPZ in Normal Operation Figure 1 1.3. Motivation When an RD-C uses external data from an RD-P, the RD-P has no general method of knowing which elements of their dataset(s) are supporting DNS filtering. Access to this data enables RD-P's to improve their data based on its usage. RPZ-FBZ provides a mechanism whereby this potentially valuable data Connery Expires December 3, 2013 [Page 3] Internet-Draft DNSRPZ Feedback Zone June 2013 may be supplied by the RD-C to the RD-P, and/or to others. +---------+ DNS +----------+ RPZ +------+ +---------+ | RD-C | <---> | RD-C | <------- | RD-P | <--- | RD-P | | Clients | Query | Resolver | Data | | | Sources | +---------+ | | | ^ | +---------+ | | | Feedback | | | | --> | -------> |-- | | | Data | | +----------+ +------+ RPZ with Feedback Zone(s) Figure 2 2. Mechanism 2.1. Overview The RPZ-FBZ mechansim is based on identifying 'hits' from each client DNS resolution response which resulted in data from an RPZ zone being used, rather than normal DNS recursion. Dynamic DNS (DDNS) is employed to transfer 'hits' into a corresponding feedback zone. RD-P's may subscribe to these feedback zone(s), as authorized by the RD-C. A process examines data from the resolver's log file(s) and transfers information regarding RPZ type responses, via DDNS, to a feedback zone. This process is called rpzlog2feedback in this document. The nature of the logging format, zone format, and DDNS update mechanism, which are used by rpzlog2feedback, are deliberately left unspecified as they may vary for differing resolvers. rpzlog2feedback has been implemented as a proof of concept, utilizing the logging channels of the BIND resolver and its DDNS mechanism. 2.2. Resource Records Note that each resource record in an RPZ zone identifies the zone from which it was obtainted, and the rule which matched the record. 2.3. Requirements The log data generated by a resolver using RPZ must allow for rpzlog2feedback to distinguish between normal behaviour and responses for RPZ zones. Additionally, rpzlog2feedback, must be able to Connery Expires December 3, 2013 [Page 4] Internet-Draft DNSRPZ Feedback Zone June 2013 identify the RPZ zone from which the response was made, and the resource record (RR) from that zone which was used to make the response. 2.4. Operation rpzlog2feedback executes, gathering 'hit' data to insert into the feedback zone. For each 'hit' it identifies the: o domain name queried by the client o RR which matched the query The RR contains both the name of the zone which contained the RR, and the type of match which was used to select the RR. The resolver's DDNS mechanism is used by rpzlog2feedback to insert records into the corresponding feedback zone to identify the query and the RR. If the update generates new data in the feedback zone, the resolver software should generate a notication of a change to the zone to be received by approved subscribers. The gathering of 'hit' data, and its corresponding update of the feedback zone shall be regularly performed based on a timing interval. This takes advantage of the incremental zone transfer mechanism inherint in ISC's initial implimentation of RPZ and reduces the workload on both parties in the data transfer. Additionally, rpzlog2feedback may choose to remove 'old' records from the feedback zone. The choice of how rpzlog2feedback runs and how it removes old records from the feedback zone affects the level of system resources for the producer of the feedback zone, and the subscriber of that feedback zone. The effect on the subscriber (likely a reputation data provider) is potentially high, if they choose to monitor the difference records made available through the transfer process. 3. Mechanics The amounts of work exerted by the producer of the feedback zone and its consumer, are largely based on the consideration of the following two choices. These choices also determine the amount of data that the consumer may obtain. Connery Expires December 3, 2013 [Page 5] Internet-Draft DNSRPZ Feedback Zone June 2013 o Aging: will the feedback zone producer remove old records from the zone? o Frequency: how frequently will the feedback zone maintainer update the zone? o Timestamp: shall the feedback zone creator include timestamp information for *each* feedback zone record? The ability of a subscriber to identify the difference records obtained during an update to the zone allows them to potentially obtain considerably more information from the zone, irrespective of the above choices. 3.1. Aging If no records are ever removed from a feedback zone then the zone will continuously grow and consume ever greater system resources (both primary and secondary storage). Thus, some form of removal of 'old' records is highly recommended. It is assumed below that some form of Aging (removing old records is being performed). 3.2. Frequency Each occasion in a period of update may, depending on whether new data is inserted into the feedback zone, result in a notification of change, causing the subscriber to 'pull' the change. 3.3. Timestamp The feedback zone builder may choose to include timestamps within the data, and a local identifier indicating which resolver generated the 'hit'. Format: {unix epoch timestamp}.{local id}.{query zone} IN CNAME {matching resource identifier} 4. Security Considerations RPZ-FBZ assembles data describing which domains with a poor reputation are being queried by clients within some network/ organisation. No identifying information about particular clients is made available. Connery Expires December 3, 2013 [Page 6] Internet-Draft DNSRPZ Feedback Zone June 2013 Leaking this information is unlikely to have serious conseqences. Nonetheless, if is recommended that organizations implementing RPZ- FBZ are judicious with whom they share their data. RPZ-FBZ is based on the zone transfer (and DDNS) technologies inherent in the local and remote DNS servers. Thus, security is based on the security of those softwares and the operating system over which they operate. 5. Contributors April Lorenzen (DissectCyber) and the editor are the originators of this mechanism. Other significant inputs: o Carel van Straten (Spamhaus) o Paul Vixie (ISC) 6. Informative References [DNSRPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones (DNS RPZ, Format 3)", 2010, . Author's Address Hugo M. Connery (editor) Technical University of Denmark DTU Environment, Miljoevej Kongen's Lyngby, Greater Copenhagen 2800 DK Phone: +45 4525 1555 Email: hmc@env.dtu.dk Connery Expires December 3, 2013 [Page 7] Internet-Draft DNSRPZ Feedback Zone June 2013 Full Copyright Statement Copyright (C) The IETF Trust (2013). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Connery Expires December 3, 2013 [Page 8]