2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Internet Engineering Task Force A.D. Dulaunoy
|
|
|
|
|
Internet-Draft CIRCL
|
|
|
|
|
Intended status: Informational L.A. Kaplan
|
2013-01-30 00:04:45 +00:00
|
|
|
|
Expires: July 15, 2013 CERT.at
|
|
|
|
|
January 2013
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
Passive DNS - Common Output Format
|
2011-12-23 14:50:58 +00:00
|
|
|
|
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
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
This Internet-Draft will expire on July 15, 2013.
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
Copyright Notice
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
Copyright (c) 2013 IETF Trust and the persons identified as the
|
2011-12-23 14:50:58 +00:00
|
|
|
|
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
|
2013-01-30 00:04:45 +00:00
|
|
|
|
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
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
Dulaunoy & Kaplan info [Page 1]
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
Internet-Draft Abbreviated Title January 2013
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
7.2. Informative References . . . . . . . . . . . . . . . . . . 4
|
|
|
|
|
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 4
|
|
|
|
|
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
1. Introduction
|
|
|
|
|
|
|
|
|
|
Passive DNS is a technique described by Florian Weimer in 2005 in
|
|
|
|
|
Passive DNS replication, F Weimer - 17th Annual FIRST Conference on
|
2013-01-30 00:04:45 +00:00
|
|
|
|
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.
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
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].
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
2. Mandatory Fields
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
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.
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
2.1. first_seen
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
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.
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
2.2. last_seen
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
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.
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
2.3. rrtype
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dulaunoy & Kaplan info [Page 2]
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
Internet-Draft Abbreviated Title January 2013
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
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).
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
2.4. rrname
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
This field returns the name of the queried resource.
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
3. Optional Fields
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
3.1. sensor_id
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
3.2. count
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
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.
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
3.3. ttl
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
3.4. bailiwick
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
4. Acknowledgements
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
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].
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
5. IANA Considerations
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
6. Security Considerations
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
All drafts are required to have a security considerations section.
|
|
|
|
|
See RFC 3552 [RFC3552] for a guide.
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
7. References
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
7.1. Normative References
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
|
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
Dulaunoy & Kaplan info [Page 3]
|
|
|
|
|
|
|
|
|
|
Internet-Draft Abbreviated Title January 2013
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
[min_ref] authSurName, authInitials, "Minimal Reference", 2006.
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
7.2. Informative References
|
2011-12-23 14:50:58 +00:00
|
|
|
|
|
|
|
|
|
[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
|
2013-01-30 00:04:45 +00:00
|
|
|
|
41, avenue de la gare
|
|
|
|
|
Luxembourg, L-1611
|
2011-12-23 14:50:58 +00:00
|
|
|
|
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/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-30 00:04:45 +00:00
|
|
|
|
Dulaunoy & Kaplan info [Page 4]
|