diff --git a/i-d/pdns-qof.txt b/i-d/pdns-qof.txt index a17c51e..da64c74 100644 --- a/i-d/pdns-qof.txt +++ b/i-d/pdns-qof.txt @@ -1,6 +1,7 @@ + Internet Engineering Task Force A. Dulaunoy Internet-Draft CIRCL Intended status: Informational A. Kaplan @@ -24,7 +25,7 @@ Abstract queries, users of multiple Passive DNS servers will be able to combine result sets easily. -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. @@ -64,54 +65,35 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Common Output Format . . . . . . . . . . . . . . . . . . . . 3 + 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 + 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 . . . . . . . . . . . . . . . . . . . . . . 5 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 + 7.2. References . . . . . . . . . . . . . . . . . . . . . . . 7 + 7.3. Informative References . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction @@ -124,6 +106,14 @@ Internet-Draft Passive DNS - Common Output Format December 2013 There are multiple implementations of Passive DNS software. Users of passive DNS query each implementation and aggregate the results for + + + +Dulaunoy, et al. Expires June 28, 2014 [Page 2] + +Internet-Draft Passive DNS - Common Output Format December 2013 + + 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 @@ -136,7 +126,7 @@ Internet-Draft Passive DNS - Common Output Format December 2013 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]) + 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. @@ -147,7 +137,6 @@ 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 @@ -161,6 +150,18 @@ Internet-Draft Passive DNS - Common Output Format December 2013 they assume that answers must be identical across multiple Passive DNS Servers. +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. + + + + + + @@ -169,13 +170,6 @@ Dulaunoy, et al. Expires June 28, 2014 [Page 3] Internet-Draft Passive DNS - Common Output Format December 2013 -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 @@ -217,6 +211,13 @@ Internet-Draft Passive DNS - Common Output Format December 2013 addition, a client MUST be able to handle a decimal value (as mentioned above) as answer. +3.2.3. rdata + + 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 @@ -225,13 +226,6 @@ 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, - 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]. @@ -273,6 +267,13 @@ Internet-Draft Passive DNS - Common Output Format December 2013 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]. + + @@ -281,12 +282,6 @@ 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. - The sensor_id is an opaque byte string as defined by RFC 5001 in - section 2.3 [RFC5001]. - 3.4.2. zone_time_first This field returns the first time that the unique tuple (rrname, @@ -305,20 +300,17 @@ 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 @@ -326,17 +318,8 @@ 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", @@ -348,6 +331,13 @@ Internet-Draft Passive DNS - Common Output Format December 2013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + + +Dulaunoy, et al. Expires June 28, 2014 [Page 6] + +Internet-Draft Passive DNS - Common Output Format December 2013 + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. @@ -379,12 +369,23 @@ 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, . + + + @@ -393,17 +394,8 @@ 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] @@ -414,21 +406,20 @@ Internet-Draft Passive DNS - Common Output Format December 2013 [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 @@ -436,6 +427,16 @@ Authors' Addresses URI: http://www.circl.lu/ + L. 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/ + @@ -449,22 +450,9 @@ Dulaunoy, et al. Expires June 28, 2014 [Page 8] Internet-Draft Passive DNS - Common Output Format December 2013 - L. 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: / @@ -492,6 +480,19 @@ Internet-Draft Passive DNS - Common Output Format December 2013 + + + + + + + + + + + + + @@ -501,4 +502,3 @@ Internet-Draft Passive DNS - Common Output Format December 2013 Dulaunoy, et al. Expires June 28, 2014 [Page 9] -