From d96f2eae0ddf22ebbda4ad3635f416fc122c4553 Mon Sep 17 00:00:00 2001 From: Aaron Kaplan Date: Wed, 25 Dec 2013 14:48:59 +0100 Subject: [PATCH] re-generate .txt file --- i-d/pdns-qof.txt | 316 +++++++++++++++++++++++------------------------ 1 file changed, 158 insertions(+), 158 deletions(-) diff --git a/i-d/pdns-qof.txt b/i-d/pdns-qof.txt index bb8a376..9a5cff6 100644 --- a/i-d/pdns-qof.txt +++ b/i-d/pdns-qof.txt @@ -1,7 +1,6 @@ - Internet Engineering Task Force Dulaunoy Internet-Draft CIRCL Intended status: Informational Kaplan @@ -19,10 +18,10 @@ Expires: June 28, 2014 CERT.at Abstract This document describes the output format used between Passive DNS - query interface. The output format description includes also a + query interfaces. The output format description includes also a common meaning per Passive DNS system. -Status of This Memo +Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -62,35 +61,57 @@ Internet-Draft Passive DNS - Common Output Format December 2013 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 . . . . . . . . . . . . . . . . . . 3 - 2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Common Output Format . . . . . . . . . . . . . . . . . . . . 3 - 3.1. Overview and Example . . . . . . . . . . . . . . . . . . 3 - 3.2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . 4 - 3.2.1. rrname . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.2.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.2.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.2.4. time_first . . . . . . . . . . . . . . . . . . . . . 4 - 3.2.5. time_last . . . . . . . . . . . . . . . . . . . . . . 5 - 3.3. Optional Fields . . . . . . . . . . . . . . . . . . . . . 5 - 3.3.1. count . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.3.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . 5 - 3.4. Additional Fields . . . . . . . . . . . . . . . . . . . . 5 - 3.4.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 5 - 3.4.2. zone_time_first . . . . . . . . . . . . . . . . . . . 5 - 3.4.3. zone_time_last . . . . . . . . . . . . . . . . . . . 6 - 3.5. Additional Fields Registry . . . . . . . . . . . . . . . 6 - 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 - 7.2. References . . . . . . . . . . . . . . . . . . . . . . . 7 - 7.3. Informative References . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 + 2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Common Output Format . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Overview and Example . . . . . . . . . . . . . . . . . . . 4 + 3.2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . 4 + 3.2.1. rrname . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2.4. time_first . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2.5. time_last . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3. Optional Fields . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3.1. count . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.4. Additional Fields . . . . . . . . . . . . . . . . . . . . . 5 + 3.4.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.4.2. zone_time_first . . . . . . . . . . . . . . . . . . . . 6 + 3.4.3. zone_time_last . . . . . . . . . . . . . . . . . . . . 6 + 3.5. Additional Fields Registry . . . . . . . . . . . . . . . . 6 + 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 + 7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7.3. Informative References . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 + + + + + + + + + + + + + + + + + +Dulaunoy, et al. Expires June 28, 2014 [Page 2] + +Internet-Draft Passive DNS - Common Output Format December 2013 + 1. Introduction @@ -106,27 +127,19 @@ Table of Contents their search. This document describes the output format of four Passive DNS Systems ([DNSDB],[PDNSCERTAT], [PDNSCIRCL] and [PDNSCOF]) which are in use today and which already share a nearly identical - - - -Dulaunoy, et al. Expires June 28, 2014 [Page 2] - -Internet-Draft Passive DNS - Common Output Format December 2013 - - 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. passivedns-client - [PDNSCLIENT]currently implements multiple parsers due to a lack of - standardization. The document does not describe the protocol (e.g. - WHOIS [RFC3912], HTTP REST [REST]) nor the query format used to query - the Passive DNS. Neither does this document describe "pre-recursor" - Passive DNS Systems. + interpretation. The 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. passivedns-client [PDNSCLIENT]currently implements + multiple parsers due to a lack of standardization. The document does + not describe the protocol (e.g. WHOIS [RFC3912], HTTP REST [REST]) + nor the query format used to query the Passive DNS. Neither does + this document describe "pre-recursor" Passive DNS Systems. Both of + these are separate topics and deserve their own RFC document. 1.1. Requirements Language @@ -134,6 +147,7 @@ Internet-Draft Passive DNS - Common Output Format December 2013 "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 @@ -143,7 +157,17 @@ Internet-Draft Passive DNS - Common Output Format December 2013 DNS Database from cache poisoning attacks [CACHEPOISONING]. Another limitiation that clients querying the database need to be aware of is that each query simply gets an snapshot-answer of the time of - querying. Clients MUST NOT rely on consistent answers. + querying. Clients MUST NOT rely on consistent answers. Not must + they assume that answers must be identical across multiple Passive + DNS Servers. + + + + +Dulaunoy, et al. Expires June 28, 2014 [Page 3] + +Internet-Draft Passive DNS - Common Output Format December 2013 + 3. Common Output Format @@ -159,17 +183,6 @@ Internet-Draft Passive DNS - Common Output Format December 2013 A sample output using the JSON format: - - - - - - -Dulaunoy, et al. Expires June 28, 2014 [Page 3] - -Internet-Draft Passive DNS - Common Output Format December 2013 - - ... (list of )... { "count": 97167, "time_first": "1277353744", @@ -182,7 +195,7 @@ Internet-Draft Passive DNS - Common Output Format December 2013 Implementation MUST support all the mandatory fields. - The tuple (rrtype,rrname,rdata) will always be unique within one + The tuple (rrname,rrtype,rdata) will always be unique within one answer per server. 3.2.1. rrname @@ -198,12 +211,20 @@ Internet-Draft Passive DNS - Common Output Format December 2013 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 + Currently known and supported textual descriptions 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. + + + +Dulaunoy, et al. Expires June 28, 2014 [Page 4] + +Internet-Draft Passive DNS - Common Output Format December 2013 + + 3.2.3. rdata This field returns the data of the queried resource. In general, @@ -217,15 +238,6 @@ Internet-Draft Passive DNS - Common Output Format December 2013 3.2.4. time_first - - - - -Dulaunoy, et al. Expires June 28, 2014 [Page 4] - -Internet-Draft Passive DNS - Common Output Format December 2013 - - 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 @@ -240,17 +252,17 @@ Internet-Draft Passive DNS - Common Output Format December 2013 3.3. Optional Fields - Implementation SHOULD support one or more field. + Implementations 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 how many authoritative DNS answers were received at the + Passive DNS Server's collectors 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). + time_last and time_first). Decimal number. 3.3.2. bailiwick @@ -261,6 +273,14 @@ Internet-Draft Passive DNS - Common Output Format December 2013 Implementations MAY support the following fields: + + + +Dulaunoy, et al. Expires June 28, 2014 [Page 5] + +Internet-Draft Passive DNS - Common Output Format December 2013 + + 3.4.1. sensor_id This field returns the sensor information where the record was seen. @@ -274,14 +294,6 @@ Internet-Draft Passive DNS - Common Output Format December 2013 is expressed in seconds (decimal ascii) since 1st of January 1970 (unix timestamp). The time zone MUST be UTC. - - - -Dulaunoy, et al. Expires June 28, 2014 [Page 5] - -Internet-Draft Passive DNS - Common Output Format December 2013 - - 3.4.3. zone_time_last This field returns the last time that the unique tuple (rrname, @@ -293,17 +305,20 @@ Internet-Draft Passive DNS - Common Output Format December 2013 In accordance with [RFC6648], designers of new passive DNS applications that would need additional fields can request and - register new field name at https://github.com/adulau/pdns-qof/wiki/ - Additional-Fields. + register new field name at + https://github.com/adulau/pdns-qof/wiki/Additional-Fields. + 4. Acknowledgements 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 @@ -311,8 +326,17 @@ Internet-Draft Passive DNS - Common Output Format December 2013 querying multiple Passive DNS and aggregating the data, the sensitivity of the data must be considered. + 7. References + + + +Dulaunoy, et al. Expires June 28, 2014 [Page 6] + +Internet-Draft Passive DNS - Common Output Format December 2013 + + 7.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", @@ -330,14 +354,6 @@ Internet-Draft Passive DNS - Common Output Format December 2013 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004. - - - -Dulaunoy, et al. Expires June 28, 2014 [Page 6] - -Internet-Draft Passive DNS - Common Output Format December 2013 - - [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. @@ -363,29 +379,12 @@ Internet-Draft Passive DNS - Common Output Format December 2013 [PDNSCERTAT] "pDNS presentation at 4th Centr R&D workshop Frankfurt Jun - 5th 2012", 2012, . + 5th 2012", 2012, . [PDNSCIRCL] "CIRCL Passive DNS", 2012, . - [PDNSCLIENT] - "Queries 5 major Passive DNS databases: BFK, CERTEE, - DNSParse, ISC, and VirusTotal.", 2013, . - - [PDNSCOF] "Passive DNS server interface using the common output - format", 2013, . - - [REST] "Representational State Transfer (REST)", 2000, - . - - [WEINERPDNS] - "Passive DNS Replication", 2005, . - @@ -394,24 +393,42 @@ Dulaunoy, et al. Expires June 28, 2014 [Page 7] Internet-Draft Passive DNS - Common Output Format December 2013 + [PDNSCLIENT] + "Queries 5 major Passive DNS databases: BFK, CERTEE, + DNSParse, ISC, and VirusTotal.", 2013, + . + + [PDNSCOF] "Passive DNS server interface using the common output + format", 2013, + . + + [REST] "Representational State Transfer (REST)", 2000, . + + [WEINERPDNS] + "Passive DNS Replication", 2005, . + 7.3. Informative References [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", draft-narten-iana- - considerations-rfc2434bis-09 (work in progress), March - 2008. + IANA Considerations Section in RFCs", + draft-narten-iana-considerations-rfc2434bis-09 (work in + progress), March 2008. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC - Text on Security Considerations", BCP 72, RFC 3552, July - 2003. + Text on Security Considerations", BCP 72, RFC 3552, + July 2003. + Authors' Addresses Alexandre Dulaunoy CIRCL 41, avenue de la gare - Luxembourg L-1611 + Luxembourg, L-1611 LU Phone: (+352) 247 88444 @@ -419,24 +436,6 @@ Authors' Addresses 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: / - - @@ -450,6 +449,26 @@ Dulaunoy, et al. Expires June 28, 2014 [Page 8] Internet-Draft Passive DNS - Common Output Format December 2013 + 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. + + + Phone: + Email: paul@redbarn.org + URI: / + + Henry Stern Cisco 1741 Brunswick Street, Suite 500 @@ -479,26 +498,7 @@ Internet-Draft Passive DNS - Common Output Format December 2013 - - - - - - - - - - - - - - - - - - - - Dulaunoy, et al. Expires June 28, 2014 [Page 9] +