Generated with 2.4.4

This commit is contained in:
Alexandre Dulaunoy 2013-12-25 15:45:13 +01:00
parent cec7b8a09e
commit 8a7b17f689

View file

@ -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, <http://www.centr.org/system/files/
agenda/attachment/rd4-papst-passive_dns.pdf>.
5th 2012", 2012, <http://www.centr.org/system/files/agenda
/attachment/rd4-papst-passive_dns.pdf>.
[PDNSCIRCL]
"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
[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/>.
[REST] "Representational State Transfer (REST)", 2000, <http://
www.ics.uci.edu/~fielding/pubs/dissertation/
[REST] "Representational State Transfer (REST)", 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/
rest_arch_style.htm>.
[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]