mirror of
https://github.com/adulau/pdns-qof.git
synced 2024-11-22 01:57:07 +00:00
Merge
This commit is contained in:
parent
d1d7aab5e2
commit
02718f0ed4
1 changed files with 60 additions and 60 deletions
120
i-d/pdns-qof.txt
120
i-d/pdns-qof.txt
|
@ -7,9 +7,8 @@ Internet-Draft CIRCL
|
|||
Intended status: Informational A. Kaplan
|
||||
Expires: June 28, 2014 CERT.at
|
||||
P. Vixie
|
||||
Farsight Security, Inc.
|
||||
H. Stern
|
||||
Cisco
|
||||
Farsight Security, Inc.
|
||||
December 25, 2013
|
||||
|
||||
|
||||
|
@ -50,6 +49,7 @@ Copyright Notice
|
|||
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
|
||||
|
||||
|
||||
|
||||
|
@ -58,7 +58,6 @@ Dulaunoy, et al. Expires June 28, 2014 [Page 1]
|
|||
Internet-Draft Passive DNS - Common Output Format December 2013
|
||||
|
||||
|
||||
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
|
||||
|
@ -71,21 +70,22 @@ Table of Contents
|
|||
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
|
||||
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3.3. Mandatory Fields . . . . . . . . . . . . . . . . . . . . 4
|
||||
3.3.1. rrname . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3.3.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3.3.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3.3.4. time_first . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.3.5. time_last . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4. Optional Fields . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.1. count . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.2. Bailiwick . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.5. Additional Fields . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.5.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.5.2. zone_time_first . . . . . . . . . . . . . . . . . . . 6
|
||||
3.5.3. zone_time_last . . . . . . . . . . . . . . . . . . . 6
|
||||
3.6. Additional Fields Registry . . . . . . . . . . . . . . . 6
|
||||
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
|
||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
|
||||
|
@ -146,21 +146,21 @@ 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. Not must
|
||||
querying. Clients MUST NOT rely on consistent answers. Nor must
|
||||
they assume that answers must be identical across multiple Passive
|
||||
DNS Servers.
|
||||
|
||||
3. Common Output Format
|
||||
|
||||
3.1. Overview
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The intent of this output format is to be easily parsable by scripts.
|
||||
Every implementation MUST support the JSON output format.
|
||||
|
||||
|
||||
|
||||
|
@ -170,10 +170,7 @@ Dulaunoy, et al. Expires June 28, 2014 [Page 3]
|
|||
Internet-Draft Passive DNS - Common Output Format December 2013
|
||||
|
||||
|
||||
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.
|
||||
3.2. Example
|
||||
|
||||
A sample output using the JSON format:
|
||||
|
||||
|
@ -185,18 +182,18 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
"time_last": "1386405372" }
|
||||
... (separated by newline)...
|
||||
|
||||
3.2. Mandatory Fields
|
||||
3.3. Mandatory Fields
|
||||
|
||||
Implementation MUST support all the mandatory fields.
|
||||
|
||||
The tuple (rrname,rrtype,rdata) will always be unique within one
|
||||
answer per server.
|
||||
|
||||
3.2.1. rrname
|
||||
3.3.1. rrname
|
||||
|
||||
This field returns the name of the queried resource.
|
||||
|
||||
3.2.2. rrtype
|
||||
3.3.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
|
||||
|
@ -211,13 +208,16 @@ 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
|
||||
3.3.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].
|
||||
|
||||
|
||||
|
||||
|
@ -226,29 +226,25 @@ Dulaunoy, et al. Expires June 28, 2014 [Page 4]
|
|||
Internet-Draft Passive DNS - Common Output Format December 2013
|
||||
|
||||
|
||||
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].
|
||||
|
||||
3.2.4. time_first
|
||||
3.3.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.
|
||||
is expressed in seconds (decimal ASCII) since 1st of January 1970
|
||||
(Unix timestamp). The time zone MUST be UTC.
|
||||
|
||||
3.2.5. time_last
|
||||
3.3.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
|
||||
expressed in seconds (decimal ASCII) since 1st of January 1970 (Unix
|
||||
timestamp). The time zone MUST be UTC.
|
||||
|
||||
3.3. Optional Fields
|
||||
3.4. Optional Fields
|
||||
|
||||
Implementations SHOULD support one or more field.
|
||||
|
||||
3.3.1. count
|
||||
3.4.1. count
|
||||
|
||||
Specifies how many authoritative DNS answers were received at the
|
||||
Passive DNS Server's collectors with the set of answers (i.e. same
|
||||
|
@ -258,16 +254,16 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
other type fields has been seen in the given time interval (between
|
||||
time_last and time_first). Decimal number.
|
||||
|
||||
3.3.2. bailiwick
|
||||
3.4.2. Bailiwick
|
||||
|
||||
The bailiwick is the best estimate of the apex of the zone where this
|
||||
data is authoritative. String.
|
||||
|
||||
3.4. Additional Fields
|
||||
3.5. Additional Fields
|
||||
|
||||
Implementations MAY support the following fields:
|
||||
|
||||
3.4.1. sensor_id
|
||||
3.5.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
|
||||
|
@ -277,26 +273,30 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Dulaunoy, et al. Expires June 28, 2014 [Page 5]
|
||||
|
||||
Internet-Draft Passive DNS - Common Output Format December 2013
|
||||
|
||||
|
||||
3.4.2. zone_time_first
|
||||
3.5.2. zone_time_first
|
||||
|
||||
This field returns the first time that the unique tuple (rrname,
|
||||
rrtype, rdata) record has been seen via zone file import. The date
|
||||
is expressed in seconds (decimal ascii) since 1st of January 1970
|
||||
(unix timestamp). The time zone MUST be UTC.
|
||||
is expressed in seconds (decimal ASCII) since 1st of January 1970
|
||||
(Unix timestamp). The time zone MUST be UTC.
|
||||
|
||||
3.4.3. zone_time_last
|
||||
3.5.3. zone_time_last
|
||||
|
||||
This field returns the last time that the unique tuple (rrname,
|
||||
rrtype, rdata) record has been seen via zone file import. The date
|
||||
is expressed in seconds (decimal ascii) since 1st of January 1970
|
||||
(unix timestamp). The time zone MUST be UTC.
|
||||
is expressed in seconds (decimal ASCII) since 1st of January 1970
|
||||
(Unix timestamp). The time zone MUST be UTC.
|
||||
|
||||
3.5. Additional Fields Registry
|
||||
3.6. Additional Fields Registry
|
||||
|
||||
In accordance with [RFC6648], designers of new passive DNS
|
||||
applications that would need additional fields can request and
|
||||
|
@ -314,7 +314,7 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
6. Security Considerations
|
||||
|
||||
In some cases, Passive DNS output might contain confidential
|
||||
information and its access might be restricted. When an user is
|
||||
information and its access might be restricted. When a user is
|
||||
querying multiple Passive DNS and aggregating the data, the
|
||||
sensitivity of the data must be considered.
|
||||
|
||||
|
@ -420,7 +420,7 @@ Authors' Addresses
|
|||
CIRCL
|
||||
41, avenue de la gare
|
||||
Luxembourg L-1611
|
||||
LU
|
||||
Luxembourg
|
||||
|
||||
Phone: (+352) 247 88444
|
||||
Email: alexandre.dulaunoy@circl.lu
|
||||
|
@ -431,7 +431,7 @@ Authors' Addresses
|
|||
CERT.at
|
||||
Karlsplatz 1/2/9
|
||||
Vienna A-1010
|
||||
AT
|
||||
Austria
|
||||
|
||||
Phone: +43 1 5056416 78
|
||||
Email: kaplan@cert.at
|
||||
|
@ -452,13 +452,16 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
|
||||
Paul Vixie
|
||||
Farsight Security, Inc.
|
||||
11400 La Honda Road
|
||||
Woodside, California 94062
|
||||
U.S.A.
|
||||
|
||||
Email: paul@redbarn.org
|
||||
URI: /
|
||||
URI: https://www.farsightsecurity.com/
|
||||
|
||||
|
||||
Henry Stern
|
||||
Cisco
|
||||
Farsight Security, Inc.
|
||||
1741 Brunswick Street, Suite 500
|
||||
Halifax, Nova Scotia B3J 3X8
|
||||
Canada
|
||||
|
@ -494,9 +497,6 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue