mirror of
https://github.com/adulau/pdns-qof.git
synced 2024-10-06 06:21:41 +00:00
0759138dc8
described the three potential output formats be more specific with field descriptions minor corrections
560 lines
17 KiB
Text
560 lines
17 KiB
Text
|
||
|
||
|
||
Internet Engineering Task Force Dulaunoy
|
||
Internet-Draft CIRCL
|
||
Intended status: Informational Kaplan
|
||
Expires: July 5, 2013 CERT.at
|
||
January 2013
|
||
|
||
|
||
Passive DNS - Common Output Format
|
||
draft-ietf-dulaunoy-kaplan-pdns-cof-01
|
||
|
||
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
|
||
|
||
By submitting this Internet-Draft, each author represents that any
|
||
applicable patent or other IPR claims of which he or she is aware
|
||
have been or will be disclosed, and any of which he or she becomes
|
||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF). Note that other groups may also distribute
|
||
working documents as Internet-Drafts. The list of current Internet-
|
||
Drafts is at http://datatracker.ietf.org/drafts/current/.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
This Internet-Draft will expire on July 5, 2013.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan Expires July 5, 2013 [Page 1]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
|
||
2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
3.1. Output Format . . . . . . . . . . . . . . . . . . . . . . 4
|
||
3.1.1. Whois Human Readable . . . . . . . . . . . . . . . . . 4
|
||
3.1.2. JSON . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
3.1.3. Bind format . . . . . . . . . . . . . . . . . . . . . 5
|
||
4. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
4.1. rrname . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
4.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
4.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
4.4. time_first . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
4.5. time_last . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
5. Optional Fields . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
5.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
5.2. count . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
5.3. ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
5.4. bailiwick . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
5.5. class . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
6. Extended Fields . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
|
||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
|
||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
|
||
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
|
||
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 8
|
||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||
Intellectual Property and Copyright Statements . . . . . . . . . . 10
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan Expires July 5, 2013 [Page 2]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
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 corresponding 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, HTTP REST or
|
||
XMPP) 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. Limitation
|
||
|
||
As a Passive DNS can include protection mechanisms for their
|
||
operation, results might be different due to those protection
|
||
measures. These mechanisms filter out DNS answers if they fail some
|
||
criteria. The bailiwick algorithm (c.f.
|
||
http://www.isc.org/files/passive_dns_hardening_handout.pdf) protects
|
||
the Passive DNS Database from cache poisoning attacks [ref: Dan
|
||
Kaminsky]. 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan Expires July 5, 2013 [Page 3]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
3. Format
|
||
|
||
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 order
|
||
of the fields is not significant for the same resource type. That
|
||
measn, the same name tuple plus timing information identifies a
|
||
unique answer per server.
|
||
|
||
A sample output using the common format:
|
||
|
||
rrname: www.foo.be
|
||
rrtype: AAAA
|
||
rdata: 2001:6f8:202:2df::2
|
||
time_first: 2010-07-26 13:04:01
|
||
time_last: 2012-02-06 09:59:00
|
||
count: 87
|
||
|
||
3.1. Output Format
|
||
|
||
Depending on the clients request, there might be one of three
|
||
different answers from the server: Whois (human readable) output
|
||
format (key-value), JSON [RFC4627] output and optionally Bind zone
|
||
file output format. XXX FIXME: how does the client select which
|
||
answer format he wants? XXX
|
||
|
||
3.1.1. Whois Human Readable
|
||
|
||
This output format originates with the original design of BFK's
|
||
passive DNS server implementation. The intent is to be be human
|
||
readable. Every implementation MUST support the Whois human readable
|
||
format.
|
||
|
||
A sample output using the Whois format:
|
||
|
||
rrname: www.foo.be
|
||
rrtype: AAAA
|
||
rdata: 2001:6f8:202:2df::2
|
||
time_first: 2010-07-26 13:04:01
|
||
time_last: 2012-02-06 09:59:00
|
||
count: 87
|
||
|
||
3.1.2. JSON
|
||
|
||
The intent of this output format is to be easily parseable by
|
||
scripts. Every implementation SHOULD support the JSON output format.
|
||
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan Expires July 5, 2013 [Page 4]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
A sample output using the JSON format:
|
||
|
||
... (list of )...
|
||
{ "count": 97167,
|
||
"time_first": "2010-06-25 17:07:02",
|
||
"rrtype": "A", "rrname": "google-public-dns-a.google.com.",
|
||
"rdata": "8.8.8.8",
|
||
"time_last": "2013-02-05 17:34:03" }
|
||
... (separated by newline)...
|
||
|
||
3.1.3. Bind format
|
||
|
||
A sample output using the Bind format:
|
||
|
||
google-public-dns-a.google.com. IN A 8.8.8.8
|
||
|
||
|
||
4. Mandatory Fields
|
||
|
||
Implementation MUST support all the mandatory fields.
|
||
|
||
The tuple (rrtype,rrname,rdata) will always be unique within one
|
||
answer per server.
|
||
|
||
4.1. rrname
|
||
|
||
This field returns the name of the queried resource.
|
||
|
||
4.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
|
||
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). Currently known
|
||
and supported textual descritptions of rrtypes are: A, AAAA, CNAME,
|
||
PTR, SOA, TXT, DNAME, NS, SRV, RP, NAPTR, HINFO, A6 A client MUST be
|
||
able to understand these textual rtype values. In addition, a client
|
||
MUST be able to handle a decimal value (as mentioned above) as
|
||
answer.
|
||
|
||
4.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
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan Expires July 5, 2013 [Page 5]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
value which is legal as the right hand side in a DNS zone file RFC
|
||
1035 [RFC1035] and RFC 1034 [RFC1034].
|
||
|
||
4.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 ISO 8601 and UTC.
|
||
|
||
4.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 ISO 8601 and UTC.
|
||
|
||
|
||
5. Optional Fields
|
||
|
||
Implementation SHOULD support one or more field.
|
||
|
||
5.1. sensor_id
|
||
|
||
This field returns the sensor information where the record was seen.
|
||
The sensor_id is expressed in a decimal value.
|
||
|
||
5.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.
|
||
|
||
5.3. ttl
|
||
|
||
the TTL as specified in RFC 1035 [RFC1035] as a decimal value.
|
||
|
||
5.4. bailiwick
|
||
|
||
XXX FIXME: input from ISC needed
|
||
|
||
5.5. class
|
||
|
||
the class as specified in RFC 1035 [RFC1035]. Valid values are IN,
|
||
HS (for HESIOD), CH (for CHAOS). May be omitted, the default
|
||
assumption that a client should make is IN.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan Expires July 5, 2013 [Page 6]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
6. Extended Fields
|
||
|
||
An x- prefixed key means that is an extension and a non-standard
|
||
field defined by the implementation of the passive DNS.
|
||
|
||
|
||
7. Acknowledgements
|
||
|
||
Thanks to the Passive DNS developers who contributed to the document.
|
||
|
||
|
||
8. IANA Considerations
|
||
|
||
This memo includes no request to IANA.
|
||
|
||
|
||
9. Security Considerations
|
||
|
||
In some cases, Passive DNS output might contain confidential
|
||
information and its access might be restricted. When an user is
|
||
querying multiple Passive DNS and aggregating the data, the
|
||
sensitivity of the data must be considered.
|
||
|
||
Authentication and signing of the output MAY be implemented on the
|
||
server via an extended field, namely x-signature-sha265 which
|
||
contains a SHA256 signature of the output text, signed with the ssh-
|
||
key of the server sending the answer.
|
||
|
||
All drafts are required to have a security considerations section.
|
||
See RFC 3552 [RFC3552] for a guide.
|
||
|
||
|
||
10. References
|
||
|
||
10.1. Normative References
|
||
|
||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
||
STD 13, RFC 1034, November 1987.
|
||
|
||
[RFC1035] Mockapetris, P., "Domain names - implementation and
|
||
specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC4627] Crockford, D., "The application/json Media Type for
|
||
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
|
||
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan Expires July 5, 2013 [Page 7]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
[min_ref] authSurName, authInitials., "Minimal Reference", 2006.
|
||
|
||
10.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",
|
||
draft-narten-iana-considerations-rfc2434bis-09 (work in
|
||
progress), March 2008.
|
||
|
||
[RFC2629] Rose, M., "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/
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan Expires July 5, 2013 [Page 8]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
Leon 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/
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan Expires July 5, 2013 [Page 9]
|
||
|
||
Internet-Draft Abbreviated Title January 2013
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The IETF Trust (2013).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dulaunoy & Kaplan Expires July 5, 2013 [Page 10]
|
||
|