mirror of
https://github.com/adulau/pdns-qof.git
synced 2024-10-06 14:21:44 +00:00
240 lines
8.8 KiB
Text
240 lines
8.8 KiB
Text
|
||
|
||
|
||
Internet Engineering Task Force A.D. Dulaunoy
|
||
Internet-Draft CIRCL
|
||
Intended status: Informational L.A. Kaplan
|
||
Expires: July 15, 2013 CERT.at
|
||
January 2013
|
||
|
||
Passive DNS - Common Output Format
|
||
draft-ietf-xml2rfc-template-05
|
||
|
||
Abstract
|
||
|
||
This document describes the output format used between Passive DNS
|
||
query interface. The output format description includes also a
|
||
common meaning per Passive DNS system.
|
||
|
||
Status of this Memo
|
||
|
||
This Internet-Draft will expire on July 15, 2013.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) 2013 IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.
|
||
|
||
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 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 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 . . . . . . . . . . . . . . . . . . 2
|
||
2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2.1. first_seen . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2.2. last_seen . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2.3. rrtype . . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2.4. rrname . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
3. Optional Fields . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
3.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
3.2. count . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
3.3. ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
3.4. bailiwick . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
|
||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 3
|
||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 3
|
||
|
||
Dulaunoy & Kaplan info [Page 1]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
7.2. Informative References . . . . . . . . . . . . . . . . . . 4
|
||
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 4
|
||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
|
||
1. Introduction
|
||
|
||
Passive DNS is a technique described by Florian Weimer in 2005 in
|
||
Passive DNS replication, F Weimer - 17th Annual FIRST Conference on
|
||
Computer Security. Since then multiple Passive DNS implementations
|
||
evolved over time. Users of these Passive DNS servers query a server
|
||
(often via Whois [Ref: WHOIS]), parse the results and process them in
|
||
other applications.
|
||
|
||
There are multiple implementation of Passive DNS software. Users of
|
||
passive DNS query each implementation and aggregate the results for
|
||
their search. This document describes the output format of three
|
||
Passive DNS Systems which are in use today and which already share a
|
||
nearly identical 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 cor responding interpretation. The format format is following
|
||
a simple key-value structure. 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. [http://code.google.com/p/passive-dns-query-
|
||
tool/] currently implements multiple parsers due to a lack of
|
||
standardization. The document does not describe the protocol (e.g.
|
||
whois ref:TOADD) used to query the Passive DNS.
|
||
|
||
1.1. Requirements Language
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in RFC 2119 [RFC2119].
|
||
|
||
2. Mandatory Fields
|
||
|
||
A field is composed a key followed by a value separated by the single
|
||
':' character and a space before the value. The format is based on
|
||
the initial work done by Florian Weimer and the RIPE whois format
|
||
(ref:http://www.enyo.de/fw/software/dnslogger/whois.html). The
|
||
ordered of the fields is not significant for the same resource type,
|
||
name tuple.
|
||
|
||
2.1. first_seen
|
||
|
||
This field returns the first time that the record has been seen by
|
||
the passive DNS. The date is expressed in ISO 8601 and UTC.
|
||
|
||
2.2. last_seen
|
||
|
||
This field returns the last time that the record has been seen by the
|
||
passive DNS. The date is expressed in ISO 8601 and UTC.
|
||
|
||
2.3. rrtype
|
||
|
||
|
||
Dulaunoy & Kaplan info [Page 2]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
This field returns the resource record type as seen by the passive
|
||
DNS. The key is rr-type and the value is in the interpreted record
|
||
type. If the value cannot be interpreted the decimal value is
|
||
returned. 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).
|
||
|
||
2.4. rrname
|
||
|
||
This field returns the name of the queried resource.
|
||
|
||
3. Optional Fields
|
||
|
||
3.1. sensor_id
|
||
|
||
3.2. count
|
||
|
||
Specifies how many authoritative answers were received with the set
|
||
of answers (i.e. same data) over all sensors. The number of
|
||
requests is expressed as a decimal value.
|
||
|
||
3.3. ttl
|
||
|
||
3.4. bailiwick
|
||
|
||
4. Acknowledgements
|
||
|
||
This template was derived from an initial version written by Pekka
|
||
Savola and contributed by him to the xml2rfc project.
|
||
|
||
This document is part of a plan to make xml2rfc indispensable
|
||
[DOMINATION].
|
||
|
||
5. IANA Considerations
|
||
|
||
This memo includes no request to IANA.
|
||
|
||
All drafts are required to have an IANA considerations section (see
|
||
the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
|
||
for a guide). If the draft does not require IANA to do anything, the
|
||
section contains an explicit statement that this is the case (as
|
||
above). If there are no requirements for IANA, the section will be
|
||
removed during conversion into an RFC by the RFC Editor.
|
||
|
||
6. Security Considerations
|
||
|
||
All drafts are required to have a security considerations section.
|
||
See RFC 3552 [RFC3552] for a guide.
|
||
|
||
7. References
|
||
|
||
7.1. Normative References
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
Dulaunoy & Kaplan info [Page 3]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
[min_ref] authSurName, authInitials, "Minimal Reference", 2006.
|
||
|
||
7.2. Informative References
|
||
|
||
[DOMINATION]
|
||
Mad Dominators, Inc., "Ultimate Plan for Taking Over the
|
||
World", 1984, <http://www.example.com/dominator.html>.
|
||
|
||
[I-D.narten-iana-considerations-rfc2434bis]
|
||
Narten, T and H Alvestrand, "Guidelines for Writing an
|
||
IANA Considerations Section in RFCs", Internet-Draft
|
||
draft-narten-iana-considerations-rfc2434bis-09, March
|
||
2008.
|
||
|
||
[RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629,
|
||
June 1999.
|
||
|
||
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
|
||
Text on Security Considerations", BCP 72, RFC 3552, July
|
||
2003.
|
||
|
||
Appendix A. Additional Stuff
|
||
|
||
This becomes an Appendix.
|
||
|
||
Authors' Addresses
|
||
|
||
Alexandre Dulaunoy
|
||
CIRCL
|
||
41, avenue de la gare
|
||
Luxembourg, L-1611
|
||
LU
|
||
|
||
Phone: (+352) 247 88444
|
||
Email: alexandre.dulaunoy@circl.lu
|
||
URI: http://www.circl.lu/
|
||
|
||
|
||
Leon Aaron Kaplan
|
||
CERT.at
|
||
Karlsplatz 1/2/9
|
||
Wien, A-1010
|
||
AT
|
||
|
||
Phone: +43 1 5056416 78
|
||
Email: kaplan@cert.at
|
||
URI: http://www.cert.at/
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan info [Page 4]
|