mirror of
https://github.com/adulau/pdns-qof.git
synced 2024-11-22 10:07:09 +00:00
Sample output added
This commit is contained in:
parent
bddb878456
commit
a1df3604f8
1 changed files with 68 additions and 68 deletions
136
i-d/pdns-qof.txt
136
i-d/pdns-qof.txt
|
|
@ -41,32 +41,31 @@ Table of Contents
|
|||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
|
||||
2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||||
3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||||
3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
3.1. Output Format . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
3.1.1. JSON . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
4. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
4.1. rrname . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
4.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
4.1. rrname . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
4.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
4.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
4.4. time_first . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
4.5. time_last . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
5. Optional Fields . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
5.1. count . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
5.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
5.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
|
||||
Dulaunoy, Kaplan & Vixie info [Page 1]
|
||||
|
||||
Internet-Draft Abbreviated Title January 2013
|
||||
|
||||
6. Additional Fields . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
6. Additional Fields . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
6.1. x-sensor_id . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
7. Extended Fields . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
|
||||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 5
|
||||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
11.1. Normative References . . . . . . . . . . . . . . . . . . 5
|
||||
11.2. Informative References . . . . . . . . . . . . . . . . . 5
|
||||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
|
||||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5
|
||||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
10.1. Normative References . . . . . . . . . . . . . . . . . . 5
|
||||
10.2. Informative References . . . . . . . . . . . . . . . . . 6
|
||||
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 6
|
||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
|
||||
|
|
@ -106,6 +105,20 @@ Internet-Draft Abbreviated Title January 2013
|
|||
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
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Dulaunoy, Kaplan & Vixie info [Page 2]
|
||||
|
||||
Internet-Draft Abbreviated Title January 2013
|
||||
|
||||
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
|
||||
|
|
@ -115,11 +128,6 @@ Internet-Draft Abbreviated Title January 2013
|
|||
|
||||
3. Format
|
||||
|
||||
Dulaunoy, Kaplan & Vixie info [Page 2]
|
||||
|
||||
Internet-Draft Abbreviated Title January 2013
|
||||
|
||||
|
||||
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
|
||||
|
|
@ -167,31 +175,30 @@ Internet-Draft Abbreviated Title January 2013
|
|||
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
|
||||
|
||||
|
||||
|
||||
|
||||
Dulaunoy, Kaplan & Vixie info [Page 3]
|
||||
|
||||
Internet-Draft Abbreviated Title January 2013
|
||||
|
||||
|
||||
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. XXX reference to RFC 3597.XXX
|
||||
returned following the principle of transparency as described in RFC
|
||||
3597 [RFC3597]. 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
|
||||
|
||||
|
|
@ -200,7 +207,10 @@ Internet-Draft Abbreviated Title January 2013
|
|||
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]. XXX reference to RFC 3597.XXX
|
||||
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]. (binary stream if any?
|
||||
base64?)
|
||||
|
||||
4.4. time_first
|
||||
|
||||
|
|
@ -213,7 +223,8 @@ Internet-Draft Abbreviated Title January 2013
|
|||
|
||||
This field returns the last time that the unique tuple (rrname,
|
||||
rrtype, rdata) record has been seen by the passive DNS. The date is
|
||||
XXXX.
|
||||
expressed in seconds (decimal ascii) since 1st of January 1970 (unix
|
||||
timestamp). The time zone MUST be UTC..
|
||||
|
||||
5. Optional Fields
|
||||
|
||||
|
|
@ -225,6 +236,12 @@ Internet-Draft Abbreviated Title January 2013
|
|||
(i.e. same data). The number of requests is expressed as a decimal
|
||||
value.
|
||||
|
||||
|
||||
Dulaunoy, Kaplan & Vixie info [Page 4]
|
||||
|
||||
Internet-Draft Abbreviated Title January 2013
|
||||
|
||||
|
||||
Specifies the number of times this particular event denoted by the
|
||||
other type fields has been seen in the given time interval (between
|
||||
time_last and time_first). Decimal number.
|
||||
|
|
@ -236,51 +253,32 @@ Internet-Draft Abbreviated Title January 2013
|
|||
|
||||
6. Additional Fields
|
||||
|
||||
|
||||
Dulaunoy, Kaplan & Vixie info [Page 4]
|
||||
|
||||
Internet-Draft Abbreviated Title January 2013
|
||||
|
||||
|
||||
Implementations MAY support the following fields:
|
||||
|
||||
6.1. x-sensor_id
|
||||
|
||||
This field returns the sensor information where the record was seen.
|
||||
The sensor_id is an opaque byte string as defined by RFC5001 (XXX
|
||||
ref))
|
||||
The sensor_id is an opaque byte string as defined by RFC 5001 in
|
||||
section 2.3 [RFC5001].
|
||||
|
||||
7. Extended Fields
|
||||
|
||||
An x- prefixed key means that is an extension and a non-standard
|
||||
field defined by the implementation of the passive DNS.
|
||||
|
||||
8. Acknowledgements
|
||||
7. Acknowledgements
|
||||
|
||||
Thanks to the Passive DNS developers who contributed to the document.
|
||||
|
||||
9. IANA Considerations
|
||||
8. IANA Considerations
|
||||
|
||||
This memo includes no request to IANA.
|
||||
|
||||
10. Security Considerations
|
||||
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.
|
||||
10. References
|
||||
|
||||
All drafts are required to have a security considerations section.
|
||||
See RFC 3552 [RFC3552] for a guide.
|
||||
|
||||
11. References
|
||||
|
||||
11.1. Normative References
|
||||
10.1. Normative References
|
||||
|
||||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
||||
STD 13, RFC 1034, November 1987.
|
||||
|
|
@ -291,21 +289,23 @@ Internet-Draft Abbreviated Title January 2013
|
|||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
|
||||
(RR) Types", RFC 3597, September 2003.
|
||||
|
||||
[RFC4627] Crockford, D., "The application/json Media Type for
|
||||
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
|
||||
|
||||
[min_ref] authSurName, authInitials, "Minimal Reference", 2006.
|
||||
|
||||
11.2. Informative References
|
||||
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option",
|
||||
RFC 5001, August 2007.
|
||||
|
||||
Dulaunoy, Kaplan & Vixie info [Page 5]
|
||||
|
||||
Internet-Draft Abbreviated Title January 2013
|
||||
|
||||
|
||||
[DOMINATION]
|
||||
Mad Dominators, Inc., "Ultimate Plan for Taking Over the
|
||||
World", 1984, <http://www.example.com/dominator.html>.
|
||||
[min_ref] authSurName, authInitials, "Minimal Reference", 2006.
|
||||
|
||||
10.2. Informative References
|
||||
|
||||
[I-D.narten-iana-considerations-rfc2434bis]
|
||||
Narten, T and H Alvestrand, "Guidelines for Writing an
|
||||
|
|
@ -352,7 +352,7 @@ Authors' Addresses
|
|||
ISC
|
||||
|
||||
Email: vixie@isc.org
|
||||
URI: http://www.isc.org/
|
||||
URI: /
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue