From b307a45e4128a6d2450fb9dbf7b8ac055e8e4db1 Mon Sep 17 00:00:00 2001 From: Alexandre Dulaunoy Date: Thu, 21 Nov 2013 08:07:59 +0100 Subject: [PATCH] Generated text I-D added --- i-d/pdns-qof.txt | 724 +++++++++++++++++++++++------------------------ 1 file changed, 362 insertions(+), 362 deletions(-) diff --git a/i-d/pdns-qof.txt b/i-d/pdns-qof.txt index 424c6e7..72a308a 100644 --- a/i-d/pdns-qof.txt +++ b/i-d/pdns-qof.txt @@ -1,362 +1,362 @@ - - - -Internet Engineering Task Force Dulaunoy -Internet-Draft CIRCL -Intended status: Informational Kaplan -Expires: October 13, 2013 CERT.at - Vixie - ISC - hs Stern - Cisco - April 2013 - - Passive DNS - Common Output Format - draft-ietf-dulaunoy-kaplan-pdns-cof-01 - -Abstract - - This document describes the output format used between Passive DNS - query interface. The output format description includes also a - common meaning per Passive DNS system. - -Status of this Memo - - This Internet-Draft will expire on October 13, 2013. - -Copyright Notice - - Copyright (c) 2013 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents (http://trustee.ietf.org/ - license-info) in effect on the date of publication of this document. - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. Code Components - extracted from this document must include Simplified BSD License text - as described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Simplified BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 - 2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 3. Common Output Format . . . . . . . . . . . . . . . . . . . . . 3 - 3.1. Overview and Example . . . . . . . . . . . . . . . . . . . 3 - 3.2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . 3 - 3.2.1. rrname . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.2.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.2.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.2.4. time_first . . . . . . . . . . . . . . . . . . . . . . 4 - 3.2.5. time_last . . . . . . . . . . . . . . . . . . . . . . 4 - 3.3. Optional Fields . . . . . . . . . . . . . . . . . . . . . 4 - 3.3.1. count . . . . . . . . . . . . . . . . . . . . . . . . 4 - -Dulaunoy, Kaplan, Vixie & Stern info [Page 1] - -Internet-Draft Abbreviated Title April 2013 - - 3.3.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . 4 - 3.4. Additional Fields . . . . . . . . . . . . . . . . . . . . 4 - 3.4.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 - Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . . 5 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 - -1. Introduction - - Passive DNS is a technique described by Florian Weimer in 2005 in - Passive DNS replication, F Weimer - 17th Annual FIRST Conference on - Computer Security. Since then multiple Passive DNS implementations - evolved over time. Users of these Passive DNS servers query a server - (often via Whois [Ref: WHOIS] or HTTP and ReST), parse the results - and process them in other applications. - - There are multiple implementation of Passive DNS software. Users of - passive DNS query each implementation and aggregate the results for - their search. This document describes the output format of three - Passive DNS Systems which are in use today and which already share a - nearly identical output format. As the format and the meaning of - output fields from each Passive DNS need to be consistent, we propose - in this document a solution to commonly name each field along with - their corresponding interpretation. The format format is following a - simple key-value structure in JSON [RFC4627] format. The benefit of - having a consistent Passive DNS output format is that multiple client - implementations can query different servers without having to have a - separate parser for each individual server. [http://code.google.com/ - p/passive-dns-query-tool/] currently implements multiple parsers due - to a lack of standardization. The document does not describe the - protocol (e.g. whois, HTTP REST or XMPP) nor the query format used - to query the Passive DNS. Neither does this document describe "pre- - recursor" Passive DNS Systems. - -1.1. Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -2. Limitation - - As a Passive DNS can include protection mechanisms for their - operation, results might be different due to those protection - measures. These mechanisms filter out DNS answers if they fail some - criteria. The bailiwick algorithm (c.f. http://www.isc.org/files/ - passive_dns_hardening_handout.pdf) protects the Passive DNS Database - from cache poisoning attacks [ref: Dan Kaminsky]. Another - limitiation that clients querying the database need to be aware of is - - - -Dulaunoy, Kaplan, Vixie & Stern info [Page 2] - -Internet-Draft Abbreviated Title April 2013 - - that each query simply gets an snapshot-answer of the time of - querying. Clients MUST NOT rely on consistent answers. - -3. Common Output Format - - The formatting of the answer follows the JSON [RFC4627] format. The - order of the fields is not significant for the same resource type. - That means, the same name tuple plus timing information identifies a - unique answer per server. - -3.1. Overview and Example - - The intent of this output format is to be easily parseable by - scripts. Every implementation MUST support the JSON output format. - - A sample output using the JSON format: - - ... (list of )... - { "count": 97167, - "time_first": "2010-06-25 17:07:02", - "rrtype": "A", "rrname": "google-public-dns-a.google.com.", - "rdata": "8.8.8.8", - "time_last": "2013-02-05 17:34:03" } - ... (separated by newline)... - -3.2. Mandatory Fields - - Implementation MUST support all the mandatory fields. - - The tuple (rrtype,rrname,rdata) will always be unique within one - answer per server. - -3.2.1. rrname - - This field returns the name of the queried resource. - -3.2.2. rrtype - - This field returns the resource record type as seen by the passive - DNS. The key is rrtype and the value is in the interpreted record - type. If the value cannot be interpreted the decimal value is - returned following the principle of transparency as described in RFC - 3597 [RFC3597]. The resource record type can be any values as - described by IANA in the DNS parameters document in the section 'DNS - Label types' (http://www.iana.org/assignments/dns-parameters). - Currently known and supported textual descritptions of rrtypes are: - A, AAAA, CNAME, PTR, SOA, TXT, DNAME, NS, SRV, RP, NAPTR, HINFO, A6 A - client MUST be able to understand these textual rtype values. In - addition, a client MUST be able to handle a decimal value (as - mentioned above) as answer. - -3.2.3. rdata - - - - - -Dulaunoy, Kaplan, Vixie & Stern info [Page 3] - -Internet-Draft Abbreviated Title April 2013 - - - This field returns the data of the queried resource. In general, - this is to be interpreted as string. Depending on the rtype, this - can be an IPv4 or IPv6 address, a domain name (as in the case of - CNAMEs), an SPF record, etc. A client MUST be able to interpret any - value which is legal as the right hand side in a DNS zone file RFC - 1035 [RFC1035] and RFC 1034 [RFC1034]. If the rdata came from an - unknown DNS resource records, the server must follow the transparency - principle as described in RFC 3597 [RFC3597]. (binary stream if any? - base64?) - -3.2.4. time_first - - This field returns the first time that the record / unique tuple - (rrname, rrtype, rdata) has been seen by the passive DNS. The date is - expressed in seconds (decimal ascii) since 1st of January 1970 (unix - timestamp). The time zone MUST be UTC. - -3.2.5. time_last - - This field returns the last time that the unique tuple (rrname, - rrtype, rdata) record has been seen by the passive DNS. The date is - expressed in seconds (decimal ascii) since 1st of January 1970 (unix - timestamp). The time zone MUST be UTC.. - -3.3. Optional Fields - - Implementation SHOULD support one or more field. - -3.3.1. count - - Specifies how many answers were received with the set of answers - (i.e. same data). The number of requests is expressed as a decimal - value. - - Specifies the number of times this particular event denoted by the - other type fields has been seen in the given time interval (between - time_last and time_first). Decimal number. - -3.3.2. bailiwick - - The bailiwick is the best estimate of the apex of the zone where this - data is authoritative. String. - -3.4. Additional Fields - - Implementations MAY support the following fields: - -3.4.1. sensor_id - - This field returns the sensor information where the record was seen. - The sensor_id is an opaque byte string as defined by RFC 5001 in - section 2.3 [RFC5001]. - -4. Acknowledgements - - -Dulaunoy, Kaplan, Vixie & Stern info [Page 4] - -Internet-Draft Abbreviated Title April 2013 - - - Thanks to the Passive DNS developers who contributed to the document. - -5. IANA Considerations - - This memo includes no request to IANA. - -6. Security Considerations - - In some cases, Passive DNS output might contain confidential - information and its access might be restricted. When an user is - querying multiple Passive DNS and aggregating the data, the - sensitivity of the data must be considered. - -7. References - -7.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC4627] Crockford, D., "The application/json Media Type for - JavaScript Object Notation (JSON)", RFC 4627, July 2006. - - [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", - RFC 5001, August 2007. - - [min_ref] authSurName, authInitials, "Minimal Reference", 2006. - -7.2. Informative References - - [I-D.narten-iana-considerations-rfc2434bis] - Narten, T and H Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", Internet-Draft - draft-narten-iana-considerations-rfc2434bis-09, March - 2008. - - [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, - June 1999. - - [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC - Text on Security Considerations", BCP 72, RFC 3552, July - 2003. - -Appendix A. Appendix - - This becomes an Appendix. - -Dulaunoy, Kaplan, Vixie & Stern info [Page 5] - -Internet-Draft Abbreviated Title April 2013 - - -Authors' Addresses - - Alexandre Dulaunoy - CIRCL - 41, avenue de la gare - Luxembourg, L-1611 - LU - - Phone: (+352) 247 88444 - Email: alexandre.dulaunoy@circl.lu - URI: http://www.circl.lu/ - - - Leon Aaron Kaplan - CERT.at - Karlsplatz 1/2/9 - Vienna, A-1010 - AT - - Phone: +43 1 5056416 78 - Email: kaplan@cert.at - URI: http://www.cert.at/ - - - Paul Vixie - ISC - - Email: vixie@isc.org - URI: / - - - Henry Stern - Cisco - 1741 Brunswick Street, Suite 500 - Halifax, Nova Scotia B3J 3X8 - Canada - - Phone: +1 408 922 4555 - Email: hestern@cisco.com - URI: http://www.cisco.com/security - - - - - - - - - - - - - - - - -Dulaunoy, Kaplan, Vixie & Stern info [Page 6] + + + +Internet Engineering Task Force Dulaunoy +Internet-Draft CIRCL +Intended status: Informational Kaplan +Expires: October 13, 2013 CERT.at + Vixie + Farsight Security, Inc. + hs Stern + Cisco + April 2013 + + Passive DNS - Common Output Format + draft-ietf-dulaunoy-kaplan-pdns-cof-01 + +Abstract + + This document describes the output format used between Passive DNS + query interface. The output format description includes also a + common meaning per Passive DNS system. + +Status of this Memo + + This Internet-Draft will expire on October 13, 2013. + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (http://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Simplified BSD License text + as described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 + 2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3. Common Output Format . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Overview and Example . . . . . . . . . . . . . . . . . . . 3 + 3.2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . 3 + 3.2.1. rrname . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.2.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.2.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.2.4. time_first . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2.5. time_last . . . . . . . . . . . . . . . . . . . . . . 4 + 3.3. Optional Fields . . . . . . . . . . . . . . . . . . . . . 4 + 3.3.1. count . . . . . . . . . . . . . . . . . . . . . . . . 4 + +Dulaunoy, Kaplan, Vixie & Stern info [Page 1] + +Internet-Draft Abbreviated Title April 2013 + + 3.3.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . 4 + 3.4. Additional Fields . . . . . . . . . . . . . . . . . . . . 4 + 3.4.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 + Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . . 5 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 + +1. Introduction + + Passive DNS is a technique described by Florian Weimer in 2005 in + Passive DNS replication, F Weimer - 17th Annual FIRST Conference on + Computer Security. Since then multiple Passive DNS implementations + evolved over time. Users of these Passive DNS servers query a server + (often via Whois [Ref: WHOIS] or HTTP and ReST), parse the results + and process them in other applications. + + There are multiple implementation of Passive DNS software. Users of + passive DNS query each implementation and aggregate the results for + their search. This document describes the output format of three + Passive DNS Systems which are in use today and which already share a + nearly identical output format. As the format and the meaning of + output fields from each Passive DNS need to be consistent, we propose + in this document a solution to commonly name each field along with + their corresponding interpretation. The format format is following a + simple key-value structure in JSON [RFC4627] format. The benefit of + having a consistent Passive DNS output format is that multiple client + implementations can query different servers without having to have a + separate parser for each individual server. [http://code.google.com/ + p/passive-dns-query-tool/] currently implements multiple parsers due + to a lack of standardization. The document does not describe the + protocol (e.g. whois, HTTP REST or XMPP) nor the query format used + to query the Passive DNS. Neither does this document describe "pre- + recursor" Passive DNS Systems. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Limitation + + As a Passive DNS can include protection mechanisms for their + operation, results might be different due to those protection + measures. These mechanisms filter out DNS answers if they fail some + criteria. The bailiwick algorithm (c.f. http://www.isc.org/files/ + passive_dns_hardening_handout.pdf) protects the Passive DNS Database + from cache poisoning attacks [ref: Dan Kaminsky]. Another + limitiation that clients querying the database need to be aware of is + + + +Dulaunoy, Kaplan, Vixie & Stern info [Page 2] + +Internet-Draft Abbreviated Title April 2013 + + that each query simply gets an snapshot-answer of the time of + querying. Clients MUST NOT rely on consistent answers. + +3. Common Output Format + + The formatting of the answer follows the JSON [RFC4627] format. The + order of the fields is not significant for the same resource type. + That means, the same name tuple plus timing information identifies a + unique answer per server. + +3.1. Overview and Example + + The intent of this output format is to be easily parseable by + scripts. Every implementation MUST support the JSON output format. + + A sample output using the JSON format: + + ... (list of )... + { "count": 97167, + "time_first": "2010-06-25 17:07:02", + "rrtype": "A", "rrname": "google-public-dns-a.google.com.", + "rdata": "8.8.8.8", + "time_last": "2013-02-05 17:34:03" } + ... (separated by newline)... + +3.2. Mandatory Fields + + Implementation MUST support all the mandatory fields. + + The tuple (rrtype,rrname,rdata) will always be unique within one + answer per server. + +3.2.1. rrname + + This field returns the name of the queried resource. + +3.2.2. rrtype + + This field returns the resource record type as seen by the passive + DNS. The key is rrtype and the value is in the interpreted record + type. If the value cannot be interpreted the decimal value is + returned following the principle of transparency as described in RFC + 3597 [RFC3597]. The resource record type can be any values as + described by IANA in the DNS parameters document in the section 'DNS + Label types' (http://www.iana.org/assignments/dns-parameters). + Currently known and supported textual descritptions of rrtypes are: + A, AAAA, CNAME, PTR, SOA, TXT, DNAME, NS, SRV, RP, NAPTR, HINFO, A6 A + client MUST be able to understand these textual rtype values. In + addition, a client MUST be able to handle a decimal value (as + mentioned above) as answer. + +3.2.3. rdata + + + + + +Dulaunoy, Kaplan, Vixie & Stern info [Page 3] + +Internet-Draft Abbreviated Title April 2013 + + + This field returns the data of the queried resource. In general, + this is to be interpreted as string. Depending on the rtype, this + can be an IPv4 or IPv6 address, a domain name (as in the case of + CNAMEs), an SPF record, etc. A client MUST be able to interpret any + value which is legal as the right hand side in a DNS zone file RFC + 1035 [RFC1035] and RFC 1034 [RFC1034]. If the rdata came from an + unknown DNS resource records, the server must follow the transparency + principle as described in RFC 3597 [RFC3597]. (binary stream if any? + base64?) + +3.2.4. time_first + + This field returns the first time that the record / unique tuple + (rrname, rrtype, rdata) has been seen by the passive DNS. The date is + expressed in seconds (decimal ascii) since 1st of January 1970 (unix + timestamp). The time zone MUST be UTC. + +3.2.5. time_last + + This field returns the last time that the unique tuple (rrname, + rrtype, rdata) record has been seen by the passive DNS. The date is + expressed in seconds (decimal ascii) since 1st of January 1970 (unix + timestamp). The time zone MUST be UTC.. + +3.3. Optional Fields + + Implementation SHOULD support one or more field. + +3.3.1. count + + Specifies how many answers were received with the set of answers + (i.e. same data). The number of requests is expressed as a decimal + value. + + Specifies the number of times this particular event denoted by the + other type fields has been seen in the given time interval (between + time_last and time_first). Decimal number. + +3.3.2. bailiwick + + The bailiwick is the best estimate of the apex of the zone where this + data is authoritative. String. + +3.4. Additional Fields + + Implementations MAY support the following fields: + +3.4.1. sensor_id + + This field returns the sensor information where the record was seen. + The sensor_id is an opaque byte string as defined by RFC 5001 in + section 2.3 [RFC5001]. + +4. Acknowledgements + + +Dulaunoy, Kaplan, Vixie & Stern info [Page 4] + +Internet-Draft Abbreviated Title April 2013 + + + Thanks to the Passive DNS developers who contributed to the document. + +5. IANA Considerations + + This memo includes no request to IANA. + +6. Security Considerations + + In some cases, Passive DNS output might contain confidential + information and its access might be restricted. When an user is + querying multiple Passive DNS and aggregating the data, the + sensitivity of the data must be considered. + +7. References + +7.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC4627] Crockford, D., "The application/json Media Type for + JavaScript Object Notation (JSON)", RFC 4627, July 2006. + + [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", + RFC 5001, August 2007. + + [min_ref] authSurName, authInitials, "Minimal Reference", 2006. + +7.2. Informative References + + [I-D.narten-iana-considerations-rfc2434bis] + Narten, T and H Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", Internet-Draft + draft-narten-iana-considerations-rfc2434bis-09, March + 2008. + + [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, July + 2003. + +Appendix A. Appendix + + This becomes an Appendix. + +Dulaunoy, Kaplan, Vixie & Stern info [Page 5] + +Internet-Draft Abbreviated Title April 2013 + + +Authors' Addresses + + Alexandre Dulaunoy + CIRCL + 41, avenue de la gare + Luxembourg, L-1611 + LU + + Phone: (+352) 247 88444 + Email: alexandre.dulaunoy@circl.lu + URI: http://www.circl.lu/ + + + Leon Aaron Kaplan + CERT.at + Karlsplatz 1/2/9 + Vienna, A-1010 + AT + + Phone: +43 1 5056416 78 + Email: kaplan@cert.at + URI: http://www.cert.at/ + + + Paul Vixie + Farsight Security, Inc. + + Email: paul@redbarn.org + URI: / + + + Henry Stern + Cisco + 1741 Brunswick Street, Suite 500 + Halifax, Nova Scotia B3J 3X8 + Canada + + Phone: +1 408 922 4555 + Email: hestern@cisco.com + URI: http://www.cisco.com/security + + + + + + + + + + + + + + + + +Dulaunoy, Kaplan, Vixie & Stern info [Page 6]