diff --git a/TODO.md b/TODO.md new file mode 100644 index 0000000..dd3944b --- /dev/null +++ b/TODO.md @@ -0,0 +1,12 @@ + +TODO +===== + + * get an updated address of Henry + * formal grammar (ABNF) for the output format + * create query API RFC + * move samples to a separate section + * cross check out work with http://tools.ietf.org/id/draft-bortzmeyer-dnsop-dns-privacy-01.txt + * Submit to dns-op IETF WG + + diff --git a/i-d/.gitignore b/i-d/.gitignore new file mode 100644 index 0000000..9918fa5 --- /dev/null +++ b/i-d/.gitignore @@ -0,0 +1,7 @@ +pdns-qof.html +[._]*.s[a-w][a-z] +[._]s[a-w][a-z] +*.un~ +Session.vim +.netrwhist +*~ diff --git a/i-d/pdns-qof.xml b/i-d/pdns-qof.xml index d031535..4229aa7 100644 --- a/i-d/pdns-qof.xml +++ b/i-d/pdns-qof.xml @@ -63,7 +63,7 @@ Luxembourg L-1611 - LU + Luxembourg (+352) 247 88444 alexandre.dulaunoy@circl.lu @@ -82,7 +82,7 @@ Vienna A-1010 - AT + Austria +43 1 5056416 78 kaplan@cert.at @@ -95,20 +95,20 @@ Farsight Security, Inc.
- - - - - + 11400 La Honda Road + Woodside + California + 94062 + U.S.A. paul@redbarn.org - / + https://www.farsightsecurity.com/
- Cisco + Farsight Security, Inc.
1741 Brunswick Street, Suite 500 @@ -164,9 +164,11 @@ The document does not describe the protocol (e.g. WHOIS
+
The formatting of the answer follows the JSON format. The order of the fields is not significant for the same resource type. That means, the same name tuple plus timing information identifies a unique answer per server. -
- The intent of this output format is to be easily parseable by scripts. Every implementation MUST support the JSON output format. + The intent of this output format is to be easily parsable by scripts. Every implementation MUST support the JSON output format. +
+
A sample output using the JSON format:WHOISThis 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 value which is legal as the right hand side in a DNS zone file RFC 1035 and RFC 1034. If the rdata came from an unknown DNS resource records, the server must follow the transparency principle as described in RFC 3597.
- 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 seconds (decimal ascii) since 1st of January 1970 (unix timestamp). The time zone MUST be UTC. + 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 seconds (decimal ASCII) since 1st of January 1970 (Unix timestamp). The time zone MUST be UTC.
- 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 seconds (decimal ascii) since 1st of January 1970 (unix timestamp). The time zone MUST be UTC. + 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 seconds (decimal ASCII) since 1st of January 1970 (Unix timestamp). The time zone MUST be UTC.
@@ -208,7 +210,7 @@ The document does not describe the protocol (e.g. WHOISSpecifies how many authoritative DNS answers were received at the Passive DNS Server's collectors with the set of answers (i.e. same data). The number of requests is expressed as a decimal value. 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.
-
+
The bailiwick is the best estimate of the apex of the zone where this data is authoritative. String.
@@ -218,10 +220,10 @@ The document does not describe the protocol (e.g. WHOISThis field returns the sensor information where the record was seen. The sensor_id is an opaque byte string as defined by RFC 5001 in section 2.3.
- This field returns the first time that the unique tuple (rrname, rrtype, rdata) record has been seen via zone file import. The date is expressed in seconds (decimal ascii) since 1st of January 1970 (unix timestamp). The time zone MUST be UTC. + This field returns the first time that the unique tuple (rrname, rrtype, rdata) record has been seen via zone file import. The date is expressed in seconds (decimal ASCII) since 1st of January 1970 (Unix timestamp). The time zone MUST be UTC.
- This field returns the last time that the unique tuple (rrname, rrtype, rdata) record has been seen via zone file import. The date is expressed in seconds (decimal ascii) since 1st of January 1970 (unix timestamp). The time zone MUST be UTC. + This field returns the last time that the unique tuple (rrname, rrtype, rdata) record has been seen via zone file import. The date is expressed in seconds (decimal ASCII) since 1st of January 1970 (Unix timestamp). The time zone MUST be UTC.
@@ -249,7 +251,7 @@ The document does not describe the protocol (e.g. WHOIS
- 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. + In some cases, Passive DNS output might contain confidential information and its access might be restricted. When a user is querying multiple Passive DNS and aggregating the data, the sensitivity of the data must be considered.
diff --git a/meeting/notes-20130402.txt b/meeting/notes-20130402.txt index 68061bd..f390cfb 100644 --- a/meeting/notes-20130402.txt +++ b/meeting/notes-20130402.txt @@ -1,41 +1,45 @@ -https://dnsdb-api.isc.org +old: https://dnsdb-api.isc.org +new: https://api.dnsdb.info -keep output format and query format separated in two different documents -we should not specify which rtypes MUST be supported. It is only an output format spec - rrtype should be mnemonic that is supported by IANA - rfc 3597 unknown record type -> reference this rfc for arbitrary rrtypes - same as for RDATA (if it can not format it correctly, it should be formated as in rfc3597 +[X] keep output format and query format separated in two different documents +[X] we should not specify which rtypes MUST be supported. It is only an output format spec +[X] rrtype should be mnemonic that is supported by IANA +[X] rfc 3597 unknown record type -> reference this rfc for arbitrary rrtypes +[X] same as for RDATA (if it can not format it correctly, it should be formated as in rfc3597 -optional: x-more-data-coming: 50 (for Cisco) +[x] optional: x-more-data-coming: 50 (for Cisco) --> nope... Cisco has a different (pre-recursor ) system. Not part of this draft. -we define the record format, any extensions should be specified in an RFC describing how the protocol works ---> specify the control packets in a separate RFC ---> Paul will ask Robert. +[ ] we define the record format, any extensions should be specified in an RFC describing how the protocol works +[ ] --> specify the control packets in a separate RFC +[ ] --> Paul will ask Robert. + +Discussion about Cisco's "more data coming" extension: fearful of breaking existing programs by adding a bookend Idea: if you can add &show_progress=1 to ReST GET request, then we can add the fields If a given implementation supports bookends, progress bars, then these have to be optional and they should be signalled via HTTP GET ¶meter Extension to the record format must be x-* (for exaple x-query-id) + --> we decided against that because of http://tools.ietf.org/search/rfc6648 + Instead we created a registry in the github wiki -Samples are OK! But move them to a separate section! +[ ] Samples are OK! But move them to a separate section! dnstap -> get mail from paul -in google protocol bufs -will tap any part of a nameserver. + in google protocol bufs + will tap any part of a nameserver (code). next steps: * private circulation with robert edmonds, bfk, auckland, cert.ee - -virustotal (?) -> later + * virustotal (?) -> later submission: - the dns-op still exists! So pdns-qof should be submitted to dns-op +[ ] the dns-op still exists! So pdns-qof should be submitted to dns-op