adulau/pdns-qof
1
0
Fork 0
mirror of https://github.com/adulau/pdns-qof.git synced 2024-12-23 01:05:58 +00:00
Code Issues Projects Releases Packages Wiki Activity

Merge pull request #14 from djw1149/master

Browse source 
Various changes discussed with Authors
This commit is contained in:
Alexandre Dulaunoy 2019-04-08 14:34:24 +02:00 committed by GitHub
commit 53ebe4fda2
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -50,7 +50,7 @@
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-dulaunoy-dnsop-passive-dns-cof-03" ipr="trust200902">
<rfc category="info" docName="draft-dulaunoy-dnsop-passive-dns-cof-05" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
@ -129,7 +129,7 @@
</address>
</author>
<date month="June" year="2017" />
<date month="February" year="2019" />
<area>General</area>
<workgroup>Domain Name System Operations</workgroup>
@ -186,7 +186,8 @@ value = value ; as defined in the JSON RFC
value-separator = ws %x2C ws ; , comma. As defined in JSON
field = "rrname" | "rrtype" | "rdata" | "time_first" |
"time_last" | "count" | "bailiwick" | "sensor_id" |
"zone_time_first" | "zone_time_last" | "origin" | futureField
"zone_time_first" | "zone_time_last" | "origin" |
futureField
futureField = string
CR = %x0D
qm = %x22 ; " a quotation mark
@ -200,20 +201,20 @@ ws = *(
</section>
<section title="Mandatory Fields">
<t>Implementation MUST support all the mandatory fields.</t>
<t>Uniqueness property: the tuple (rrname,rrtype,rdata) will always be unique within one answer per server. While rrname and rrtype are always individual JSON primitive types (strings, numbers, booleans or null), rdata MAY return multiple resource records or a single record. When multiple resource records are returned, rdata MUST be a JSON array. In the case of a single resource record is returned, rdata MUST be a JSON string.</t>
<t>Uniqueness property: the tuple (rrname,rrtype,rdata) will always be unique within one answer per server. While rrname and rrtype are always individual JSON primitive types (strings, numbers, booleans or null), rdata MAY return multiple resource records or a single record. When multiple resource records are returned, rdata MUST be a JSON array. In the case of a single resource record is returned, rdata MUST be a JSON string or a JSON array containing one JSON string. Senders SHOULD send an array for rdata, but receivers MUST be able to accept a single-string result for rdata.</t>
<section title="rrname">
<t>This field returns the name of the queried resource.</t>
</section>
<section title="rrtype">
<t>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 represented as a <xref target="RFC4627">JSON</xref> string. If the value cannot be interpreted the decimal value is returned following the principle of transparency as described in <xref target="RFC3597">RFC 3597</xref>. Then the decimal value is represented as a <xref target="RFC4627">JSON</xref> number.
<t>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 represented as a <xref target="RFC4627">JSON</xref> string. If the value cannot be interpreted, the decimal value is returned following the principle of transparency as described in <xref target="RFC3597">RFC 3597</xref>. Then the decimal value is represented as a <xref target="RFC4627">JSON</xref> number.
The resource record type can be any values as described by IANA in the DNS parameters document in the section 'Resource Record (RR) TYPEs' (http://www.iana.org/assignments/dns-parameters).
Currently known and supported textual descriptions 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 rrtype values represented as a <xref target="RFC4627">JSON</xref> string. In addition, a client MUST be able to handle a decimal value (as mentioned above) as answer represented as a <xref target="RFC4627">JSON</xref> number.
Supported textual descriptions of rrtypes include: A, AAAA, CNAME, etc.
A client MUST be able to understand these textual rrtype values represented as a <xref target="RFC4627">JSON</xref> string. In addition, a client MUST be able to handle a decimal value (as mentioned above) answer represented as a <xref target="RFC4627">JSON</xref> number.
</t>
</section>
<section title="rdata">
<t>This field returns the resource records of the queried resource. When multiple resource records are returned, rdata MUST be a JSON array. In the case of a single resource record is returned, rdata MUST be a JSON string. Each resource record is represented as a <xref target="RFC4627">JSON</xref> string. Each resource record MUST be escaped as defined in section 2.6 of <xref target="RFC4627">RFC4627</xref>. Depending on the rrtype, 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 master file <xref target="RFC1035">RFC 1035</xref> and <xref target="RFC1034">RFC 1034</xref>. If the rdata came from an unknown DNS resource records, the server must follow the transparency principle as described in <xref target="RFC3597">RFC 3597</xref>.</t>
<t>This field returns the resource records of the queried resource. When multiple resource records are returned, rdata MUST be a JSON array containing JSON strings. In the case of a single resource record is returned, rdata MUST be a JSON string or a JSON array containing one JSON string. Each resource record is represented as a <xref target="RFC4627">JSON</xref> string. Each resource record MUST be escaped as defined in section 2.6 of <xref target="RFC4627">RFC4627</xref>. Depending on the rrtype, 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 master file <xref target="RFC1035">RFC 1035</xref> and <xref target="RFC1034">RFC 1034</xref>. If the rdata came from an unknown DNS resource records, the server must follow the transparency principle as described in <xref target="RFC3597">RFC 3597</xref>.</t>
</section>
<section title="time_first">
<t>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) since 1st of January 1970 (Unix timestamp). The time zone MUST be UTC. This field is represented as a <xref target="RFC4627">JSON</xref> number.</t>
@ -325,7 +326,7 @@ ws = *(
</reference>
<reference anchor="CACHEPOISONING" target="http://kurser.lobner.dk/dDist/DMK_BO2K8.pdf">
<front>
<title>Black ops 2008: It&#8217;s the end of the cache as we know it.</title>
<title>Black ops 2008: It's the end of the cache as we know it.</title>
<author fullname="Dan Kaminsky"/>
<date year="2008"/>
</front>
@ -399,7 +400,7 @@ ws = *(
<!-- &I-D.draft-bortzmeyer-dnsop-dns-privacy; -->
</references>
<section anchor="app-additional" title="Examples">
<t>The JSON output are represented on multiple lines for readability but each JSON object should on a single line.</t>
<t>The JSON output are represented on multiple lines for readability but each JSON object should be on a single line.</t>
<t>If you query a passive DNS for the rrname www.ietf.org, the passive dns common output format can be:</t>
<figure><artwork>
<![CDATA[
@ -425,7 +426,8 @@ ws = *(
"time_last": 1330209752}
]]>
</artwork></figure>
<t>Please note that in the examples above, any backslashes "\" can be ignored and are an artefact of the tools which produced this document.</t>
<t>Please note that the examples imply that a single query returns a single set of JSON objects. For example, two queries were made; one query returned a set of two JSON objects and the other query returned a set of three JSON objects. This specification requires each JSON object individually MUST conform to the common output format, but this specification does not require that a query will return a set of JSON objects.</t>
<t>Please note that in the examples above, any backslashes "\" can be ignored and are an artifact of the tools which produced this document.</t>
</section>
</back>