adulau/pdns-qof
1
0
Fork 0
mirror of https://github.com/adulau/pdns-qof.git synced 2024-11-22 18:17:04 +00:00
Code Issues Projects Releases Packages Wiki Activity

Generated with 2.4.4

Browse source
This commit is contained in:
Alexandre Dulaunoy 2013-12-25 15:45:13 +01:00
parent cec7b8a09e
commit 8a7b17f689
1 changed files with 117 additions and 117 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

232
i-d/pdns-qof.txt
View file

@ -1,6 +1,7 @@
Internet Engineering Task Force A. Dulaunoy Internet Engineering Task Force A. Dulaunoy
Internet-Draft CIRCL Internet-Draft CIRCL
Intended status: Informational A. Kaplan Intended status: Informational A. Kaplan
@ -24,7 +25,7 @@ Abstract
queries, users of multiple Passive DNS servers will be able to queries, users of multiple Passive DNS servers will be able to
combine result sets easily. combine result sets easily.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. 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 the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Common Output Format . . . . . . . . . . . . . . . . . . . . . 4 3. Common Output Format . . . . . . . . . . . . . . . . . . . . 3
3.1. Overview and Example . . . . . . . . . . . . . . . . . . . 4 3.1. Overview and Example . . . . . . . . . . . . . . . . . . 4
3.2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . 4 3.2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . 4
3.2.1. rrname . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. rrname . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.4. time_first . . . . . . . . . . . . . . . . . . . . . . 5 3.2.4. time_first . . . . . . . . . . . . . . . . . . . . . 5
3.2.5. time_last . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.5. time_last . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Optional Fields . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Optional Fields . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. count . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. count . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Additional Fields . . . . . . . . . . . . . . . . . . . . . 5 3.4. Additional Fields . . . . . . . . . . . . . . . . . . . . 5
3.4.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . . 6 3.4.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 5
3.4.2. zone_time_first . . . . . . . . . . . . . . . . . . . . 6 3.4.2. zone_time_first . . . . . . . . . . . . . . . . . . . 6
3.4.3. zone_time_last . . . . . . . . . . . . . . . . . . . . 6 3.4.3. zone_time_last . . . . . . . . . . . . . . . . . . . 6
3.5. Additional Fields Registry . . . . . . . . . . . . . . . . 6 3.5. Additional Fields Registry . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 7 7.2. References . . . . . . . . . . . . . . . . . . . . . . . 7
7.3. Informative References . . . . . . . . . . . . . . . . . . 8 7.3. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Dulaunoy, et al. Expires June 28, 2014 [Page 2]
Internet-Draft Passive DNS - Common Output Format December 2013
1. Introduction 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 There are multiple implementations of Passive DNS software. Users of
passive DNS query each implementation and aggregate the results for 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 their search. This document describes the output format of four
Passive DNS Systems ([DNSDB],[PDNSCERTAT], [PDNSCIRCL] and [PDNSCOF]) Passive DNS Systems ([DNSDB],[PDNSCERTAT], [PDNSCIRCL] and [PDNSCOF])
which are in use today and which already share a nearly identical which are in use today and which already share a nearly identical
@ -147,7 +137,6 @@ Internet-Draft Passive DNS - Common Output Format December 2013
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Limitation 2. Limitation
As a Passive DNS can include protection mechanisms for their 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 they assume that answers must be identical across multiple Passive
DNS Servers. 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 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 3.1. Overview and Example
The intent of this output format is to be easily parseable by 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 addition, a client MUST be able to handle a decimal value (as
mentioned above) as answer. 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 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 1035 [RFC1035] and RFC 1034 [RFC1034]. If the rdata came from an
unknown DNS resource records, the server must follow the transparency unknown DNS resource records, the server must follow the transparency
principle as described in RFC 3597 [RFC3597]. 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: 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 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 3.4.2. zone_time_first
This field returns the first time that the unique tuple (rrname, 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 In accordance with [RFC6648], designers of new passive DNS
applications that would need additional fields can request and applications that would need additional fields can request and
register new field name at register new field name at https://github.com/adulau/pdns-qof/wiki/
https://github.com/adulau/pdns-qof/wiki/Additional-Fields. Additional-Fields.
4. Acknowledgements 4. Acknowledgements
Thanks to the Passive DNS developers who contributed to the document. Thanks to the Passive DNS developers who contributed to the document.
5. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
6. Security Considerations 6. Security Considerations
In some cases, Passive DNS output might contain confidential 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 querying multiple Passive DNS and aggregating the data, the
sensitivity of the data must be considered. sensitivity of the data must be considered.
7. References 7. References
Dulaunoy, et al. Expires June 28, 2014 [Page 6]
Internet-Draft Passive DNS - Common Output Format December 2013
7.1. Normative References 7.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, September 2003.
@ -379,12 +369,23 @@ Internet-Draft Passive DNS - Common Output Format December 2013
[PDNSCERTAT] [PDNSCERTAT]
"pDNS presentation at 4th Centr R&D workshop Frankfurt Jun "pDNS presentation at 4th Centr R&D workshop Frankfurt Jun
5th 2012", 2012, <http://www.centr.org/system/files/ 5th 2012", 2012, <http://www.centr.org/system/files/agenda
agenda/attachment/rd4-papst-passive_dns.pdf>. /attachment/rd4-papst-passive_dns.pdf>.
[PDNSCIRCL] [PDNSCIRCL]
"CIRCL Passive DNS", 2012, <http://pdns.circl.lu/>. "CIRCL Passive DNS", 2012, <http://pdns.circl.lu/>.
[PDNSCLIENT]
"Queries 5 major Passive DNS databases: BFK, CERTEE,
DNSParse, ISC, and VirusTotal.", 2013, <https://github.com
/chrislee35/passivedns-client>.
[PDNSCOF] "Passive DNS server interface using the common output
format", 2013, <https://github.com/adulau/pdns-qof-server/
>.
@ -393,17 +394,8 @@ Dulaunoy, et al. Expires June 28, 2014 [Page 7]
Internet-Draft Passive DNS - Common Output Format December 2013 Internet-Draft Passive DNS - Common Output Format December 2013
[PDNSCLIENT] [REST] "Representational State Transfer (REST)", 2000,
"Queries 5 major Passive DNS databases: BFK, CERTEE, <http://www.ics.uci.edu/~fielding/pubs/dissertation/
DNSParse, ISC, and VirusTotal.", 2013,
<https://github.com/chrislee35/passivedns-client>.
[PDNSCOF] "Passive DNS server interface using the common output
format", 2013,
<https://github.com/adulau/pdns-qof-server/>.
[REST] "Representational State Transfer (REST)", 2000, <http://
www.ics.uci.edu/~fielding/pubs/dissertation/
rest_arch_style.htm>. rest_arch_style.htm>.
[WEINERPDNS] [WEINERPDNS]
@ -414,21 +406,20 @@ Internet-Draft Passive DNS - Common Output Format December 2013
[I-D.narten-iana-considerations-rfc2434bis] [I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", IANA Considerations Section in RFCs", draft-narten-iana-
draft-narten-iana-considerations-rfc2434bis-09 (work in considerations-rfc2434bis-09 (work in progress), March
progress), March 2008. 2008.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552, July
July 2003. 2003.
Authors' Addresses Authors' Addresses
Alexandre Dulaunoy Alexandre Dulaunoy
CIRCL CIRCL
41, avenue de la gare 41, avenue de la gare
Luxembourg, L-1611 Luxembourg L-1611
LU LU
Phone: (+352) 247 88444 Phone: (+352) 247 88444
@ -436,6 +427,16 @@ Authors' Addresses
URI: http://www.circl.lu/ 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 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 Paul Vixie
Farsight Security, Inc. Farsight Security, Inc.
Phone:
Email: paul@redbarn.org Email: paul@redbarn.org
URI: / 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] Dulaunoy, et al. Expires June 28, 2014 [Page 9]