adulau/pdns-qof
1
0
Fork 0
mirror of https://github.com/adulau/pdns-qof.git synced 2024-11-22 10:07:09 +00:00
Code Issues Projects Releases Packages Wiki Activity

Initial import of the common notes done in FIRST Malta

Browse source
This commit is contained in:
Alexandre Dulaunoy 2013-01-30 01:04:45 +01:00
parent 8540fd1012
commit 35ce20589c
2 changed files with 137 additions and 388 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

300
i-d/pdns-qof.txt
View file

@ -4,10 +4,10 @@
Internet Engineering Task Force A.D. Dulaunoy Internet Engineering Task Force A.D. Dulaunoy
Internet-Draft CIRCL Internet-Draft CIRCL
Intended status: Informational L.A. Kaplan Intended status: Informational L.A. Kaplan
Expires: April 13, 2012 CERT.at Expires: July 15, 2013 CERT.at
October 2011 January 2013
Passive DNS - qos Passive DNS - Common Output Format
draft-ietf-xml2rfc-template-05 draft-ietf-xml2rfc-template-05
Abstract Abstract
@ -18,11 +18,11 @@ Abstract
Status of this Memo Status of this Memo
This Internet-Draft will expire on April 13, 2012. This Internet-Draft will expire on July 15, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
@ -38,34 +38,54 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Simple List . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . . . 2
3. Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. first_seen . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Subsections and Tables . . . . . . . . . . . . . . . . . . . . 2 2.2. last_seen . . . . . . . . . . . . . . . . . . . . . . . . 2
4.1. A Subsection . . . . . . . . . . . . . . . . . . . . . . . 2 2.3. rrtype . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.2. Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.4. rrname . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. More about Lists . . . . . . . . . . . . . . . . . . . . . . . 3 3. Optional Fields . . . . . . . . . . . . . . . . . . . . . . . 3
5.1. Numbering Lists across Lists and Sections . . . . . . . . 3 3.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . . . 3
5.2. Where the List Numbering Continues . . . . . . . . . . . . 4 3.2. count . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6. Example of Code or MIB Module To Be Extracted . . . . . . . . 4 3.3. ttl . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. bailiwick . . . . . . . . . . . . . . . . . . . . . . . . 3
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 3
10.1. Normative References . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3
10.2. Informative References . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . . 3
Dulaunoy & Kaplan info [Page 1] Dulaunoy & Kaplan info [Page 1]
Internet-Draft Abbreviated Title October 2011 Internet-Draft Abbreviated Title January 2013
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction 1. Introduction
Passive DNS is a technique described by Florian Weimer in 2005 in Passive DNS is a technique described by Florian Weimer in 2005 in
Passive DNS replication, F Weimer - 17th Annual FIRST Conference on Passive DNS replication, F Weimer - 17th Annual FIRST Conference on
Computer Security. 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 1.1. Requirements Language
@ -73,197 +93,59 @@ Internet-Draft Abbreviated Title October 2011
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Simple List 2. Mandatory Fields
List styles: 'empty', 'symbols', 'letters', 'numbers', 'hanging', A field is composed a key followed by a value separated by the single
'format'. ':' 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.
o First bullet 2.1. first_seen
o Second bullet 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.
You can write text here as well. 2.2. last_seen
3. Figures 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.
Figures should not exceed 69 characters wide to allow for the indent 2.3. rrtype
of sections.
Preamble text - can be omitted or empty.
+-----------------------+
| Use XML, be Happy :-) |
|_______________________|
Cross-references allowed in pre- and postamble. [min_ref].
The CDATA means you don't need to escape meta-characters (especially
< (&lt;) and & (&amp;)) but is not essential. Figures may also have
a title attribute but it won't be displayed unless there is also an
anchor. White space, both horizontal and vertical, is significant in
figures even if you don't use CDATA.
4. Subsections and Tables
4.1. A Subsection
By default 3 levels of nesting show in table of contents but that can
be adjusted with the value of the "tocdepth" processing instruction.
4.2. Tables
.. are very similar to figures:
Dulaunoy & Kaplan info [Page 2] Dulaunoy & Kaplan info [Page 2]
Internet-Draft Abbreviated Title October 2011 Internet-Draft Abbreviated Title January 2013
Tables use ttcol to define column headers and widths. Every cell This field returns the resource record type as seen by the passive
then has a "c" element for its content. 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
| ttcol #1 | ttcol #2 |
+----------+----------+
| c #1 | c #2 |
| c #3 | c #4 |
| c #5 | c #6 |
+----------+----------+
which is a very simple example. This field returns the name of the queried resource.
5. More about Lists 3. Optional Fields
Lists with 'hanging labels': the list item is indented the amount of 3.1. sensor_id
the hangIndent:
short With a label shorter than the hangIndent. 3.2. count
fantastically long label With a label longer than the hangIndent. 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.
vspace_trick 3.3. ttl
Forces the new item to start on a new line.
Simulating more than one paragraph in a list item using <vspace>: 3.4. bailiwick
a. First, a short item. 4. Acknowledgements
b. Second, a longer list item.
And something that looks like a separate pararaph..
Simple indented paragraph using the "empty" style:
The quick, brown fox jumped over the lazy dog and lived to fool
many another hunter in the great wood in the west.
5.1. Numbering Lists across Lists and Sections
Numbering items continuously although they are in separate <list>
elements, maybe in separate sections using the "format" style and a
"counter" variable.
First list:
R11 #1
R12 #2
R13 #3
Specify the indent explicitly so that all the items line up nicely.
Second list:
Dulaunoy & Kaplan info [Page 3]
Internet-Draft Abbreviated Title October 2011
R14 #4
R15 #5
R16 #6
5.2. Where the List Numbering Continues
List continues here.
Third list:
R17 #7
R18 #8
R19 #9
R20 #10
The end of the list.
6. Example of Code or MIB Module To Be Extracted
The <artwork> element has a number of extra attributes that can be
used to substitute a more aesthetically pleasing rendition into HTML
output while continuing to use the ASCII art version in the text and
nroff outputs (see the xml2rfc README for details). It also has a
"type" attribute. This is currently ignored except in the case
'type="abnf"'. In this case the "artwork" is expected to contain a
piece of valid Augmented Backus-Naur Format (ABNF) grammar. This
will be syntax checked by xml2rfc and any errors will cause a fatal
error if the "strict" processing instruction is set to "yes". The
ABNF will also be colorized in HTML output to highlight the syntactic
components. Checking of additional "types" may be provided in future
versions of xml2rfc.
Dulaunoy & Kaplan info [Page 4]
Internet-Draft Abbreviated Title October 2011
/**** an example C program */
#include <stdio.h>
void
main(int argc, char *argv[])
{
int i;
printf("program arguments are:\n");
for (i = 0; i < argc; i++) {
printf("%d: \"%s\"\n", i, argv[i]);
}
exit(0);
} /* main */
/* end of file */
7. Acknowledgements
This template was derived from an initial version written by Pekka This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project. Savola and contributed by him to the xml2rfc project.
@ -271,7 +153,7 @@ Internet-Draft Abbreviated Title October 2011
This document is part of a plan to make xml2rfc indispensable This document is part of a plan to make xml2rfc indispensable
[DOMINATION]. [DOMINATION].
8. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
@ -282,26 +164,26 @@ Internet-Draft Abbreviated Title October 2011
above). If there are no requirements for IANA, the section will be above). If there are no requirements for IANA, the section will be
removed during conversion into an RFC by the RFC Editor. removed during conversion into an RFC by the RFC Editor.
9. Security Considerations 6. Security Considerations
All drafts are required to have a security considerations section. All drafts are required to have a security considerations section.
See RFC 3552 [RFC3552] for a guide. See RFC 3552 [RFC3552] for a guide.
10. References 7. References
10.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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. [min_ref] authSurName, authInitials, "Minimal Reference", 2006.
10.2. Informative References 7.2. Informative References
Dulaunoy & Kaplan info [Page 5]
Internet-Draft Abbreviated Title October 2011
[DOMINATION] [DOMINATION]
Mad Dominators, Inc., "Ultimate Plan for Taking Over the Mad Dominators, Inc., "Ultimate Plan for Taking Over the
@ -328,8 +210,8 @@ Authors' Addresses
Alexandre Dulaunoy Alexandre Dulaunoy
CIRCL CIRCL
6, rue de l'Etang 41, avenue de la gare
Contern, L-5326 Luxembourg, L-1611
LU LU
Phone: (+352) 247 88444 Phone: (+352) 247 88444
@ -355,8 +237,4 @@ Authors' Addresses
Dulaunoy & Kaplan info [Page 4]
Dulaunoy & Kaplan info [Page 6]

225
i-d/pdns-qof.xml
View file

@ -45,16 +45,16 @@
<!-- ***** FRONT MATTER ***** --> <!-- ***** FRONT MATTER ***** -->
<front> <front>
<title abbrev="Abbreviated Title">Passive DNS - qos</title> <title abbrev="Abbreviated Title">Passive DNS - Common Output Format</title>
<author fullname="Alexandre Dulaunoy" initials="A.D." <author fullname="Alexandre Dulaunoy" initials="A.D."
surname="Dulaunoy"> surname="Dulaunoy">
<organization>CIRCL</organization> <organization>CIRCL</organization>
<address> <address>
<postal> <postal>
<street>6, rue de l'Etang</street> <street>41, avenue de la gare</street>
<city>Contern</city> <city>Luxembourg</city>
<region></region> <region></region>
<code>L-5326</code> <code>L-1611</code>
<country>LU</country> <country>LU</country>
</postal> </postal>
<phone>(+352) 247 88444</phone> <phone>(+352) 247 88444</phone>
@ -81,13 +81,13 @@
<uri>http://www.cert.at/</uri> <uri>http://www.cert.at/</uri>
</address> </address>
</author> </author>
<date month="October" year="2011" /> <date month="January" year="2013" />
<area>General</area> <area>General</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>Internet Engineering Task Force</workgroup>
<keyword>template</keyword> <keyword>dns</keyword>
<abstract> <abstract>
@ -97,7 +97,18 @@
<middle> <middle>
<section title="Introduction"> <section title="Introduction">
<t>Passive DNS is a technique described by Florian Weimer in 2005 in Passive DNS replication, F Weimer - 17th Annual FIRST Conference on Computer Security. </t> <t>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.</t>
<t>
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.
</t>
<section title="Requirements Language"> <section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@ -107,188 +118,48 @@
</section> </section>
</section> </section>
<section anchor="simple_list" title="Simple List"> <section title="Mandatory Fields">
<t>List styles: 'empty', 'symbols', 'letters', 'numbers', 'hanging', <t>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.</t>
'format'.</t>
<t><list style="symbols"> <section title="first_seen">
<t>First bullet</t> <t>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.</t>
</section>
<section title="last_seen">
<t>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.</t>
</section>
<section title="rrtype">
<t>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.
<t>Second bullet</t> 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).
</list> You can write text here as well.</t> </t>
</section>
<section title="rrname">
<t>This field returns the name of the queried resource.</t>
</section>
</section>
<section title="Optional Fields">
<section title="sensor_id">
</section>
<section title="count">
<t>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.</t>
</section>
<section title="ttl">
</section>
<section title="bailiwick">
</section>
</section> </section>
<section title="Figures"> <section title="Extended Fields">
<t>Figures should not exceed 69 characters wide to allow for the indent <t>A x- prefixed key means that is an extension and a non-standard field defined by the implementation of the passive DNS.</t>
of sections.</t>
<figure align="center" anchor="xml_happy">
<preamble>Preamble text - can be omitted or empty.</preamble>
<artwork align="left"><![CDATA[
+-----------------------+
| Use XML, be Happy :-) |
|_______________________|
]]></artwork>
<postamble>Cross-references allowed in pre- and postamble. <xref
target="min_ref" />.</postamble>
</figure>
<t>The CDATA means you don't need to escape meta-characters (especially
&lt;&nbsp;(&amp;lt;) and &amp;&nbsp;(&amp;amp;)) but is not essential.
Figures may also have a title attribute but it won't be displayed unless
there is also an anchor. White space, both horizontal and vertical, is
significant in figures even if you don't use CDATA.</t>
</section> </section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. --> <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?> <?rfc needLines="8" ?>
<section title="Subsections and Tables">
<section title="A Subsection">
<t>By default 3 levels of nesting show in table of contents but that
can be adjusted with the value of the "tocdepth" processing
instruction.</t>
</section>
<section title="Tables">
<t>.. are very similar to figures:</t>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c>
<c>c #2</c>
<c>c #3</c>
<c>c #4</c>
<c>c #5</c>
<c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
</section>
</section>
<section anchor="nested_lists" title="More about Lists">
<t>Lists with 'hanging labels': the list item is indented the amount of
the hangIndent: <list hangIndent="8" style="hanging">
<t hangText="short">With a label shorter than the hangIndent.</t>
<t hangText="fantastically long label">With a label longer than the
hangIndent.</t>
<t hangText="vspace_trick"><vspace blankLines="0" />Forces the new
item to start on a new line.</t>
</list></t>
<!-- It would be nice to see the next piece (12 lines) all on one page. -->
<?rfc needLines="12" ?>
<t>Simulating more than one paragraph in a list item using
&lt;vspace&gt;: <list style="letters">
<t>First, a short item.</t>
<t>Second, a longer list item.<vspace blankLines="1" /> And
something that looks like a separate pararaph..</t>
</list></t>
<t>Simple indented paragraph using the "empty" style: <list
hangIndent="10" style="empty">
<t>The quick, brown fox jumped over the lazy dog and lived to fool
many another hunter in the great wood in the west.</t>
</list></t>
<section title="Numbering Lists across Lists and Sections">
<t>Numbering items continuously although they are in separate
&lt;list&gt; elements, maybe in separate sections using the "format"
style and a "counter" variable.</t>
<t>First list: <list counter="reqs" hangIndent="4" style="format R%d">
<t>#1</t>
<t>#2</t>
<t>#3</t>
</list> Specify the indent explicitly so that all the items line up
nicely.</t>
<t>Second list: <list counter="reqs" hangIndent="4" style="format R%d">
<t>#4</t>
<t>#5</t>
<t>#6</t>
</list></t>
</section>
<section title="Where the List Numbering Continues">
<t>List continues here.</t>
<t>Third list: <list counter="reqs" hangIndent="4" style="format R%d">
<t>#7</t>
<t>#8</t>
<t>#9</t>
<t>#10</t>
</list> The end of the list.</t>
</section>
</section>
<section anchor="codeExample"
title="Example of Code or MIB Module To Be Extracted">
<figure>
<preamble>The &lt;artwork&gt; element has a number of extra attributes
that can be used to substitute a more aesthetically pleasing rendition
into HTML output while continuing to use the ASCII art version in the
text and nroff outputs (see the xml2rfc README for details). It also
has a "type" attribute. This is currently ignored except in the case
'type="abnf"'. In this case the "artwork" is expected to contain a
piece of valid Augmented Backus-Naur Format (ABNF) grammar. This will
be syntax checked by xml2rfc and any errors will cause a fatal error
if the "strict" processing instruction is set to "yes". The ABNF will
also be colorized in HTML output to highlight the syntactic
components. Checking of additional "types" may be provided in future
versions of xml2rfc.</preamble>
<artwork><![CDATA[
/**** an example C program */
#include <stdio.h>
void
main(int argc, char *argv[])
{
int i;
printf("program arguments are:\n");
for (i = 0; i < argc; i++) {
printf("%d: \"%s\"\n", i, argv[i]);
}
exit(0);
} /* main */
/* end of file */
]]></artwork>
</figure>
</section>
<section anchor="Acknowledgements" title="Acknowledgements"> <section anchor="Acknowledgements" title="Acknowledgements">
<t>This template was derived from an initial version written by Pekka <t>This template was derived from an initial version written by Pekka