mirror of
https://github.com/adulau/pdns-qof.git
synced 2024-11-22 01:57:07 +00:00
make things clearer about the grammar
This commit is contained in:
parent
438a202b25
commit
86896da51d
2 changed files with 53 additions and 50 deletions
|
@ -74,15 +74,14 @@ Table of Contents
|
|||
3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3.3. ABNF grammar . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3.4. Mandatory Fields . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3.4.1. General remarks on mandatory fields . . . . . . . . . . 5
|
||||
3.4.2. rrname . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.3. rrtype . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.4. rdata . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.5. time_first . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.6. time_last . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.1. rrname . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.4. time_first . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4.5. time_last . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.5. Optional Fields . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
3.5.1. count . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
3.5.2. Bailiwick . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
3.5.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
3.6. Additional Fields . . . . . . . . . . . . . . . . . . . . . 6
|
||||
3.6.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
3.6.2. zone_time_first . . . . . . . . . . . . . . . . . . . . 6
|
||||
|
@ -108,6 +107,7 @@ Table of Contents
|
|||
|
||||
|
||||
|
||||
|
||||
Dulaunoy, et al. Expires June 28, 2014 [Page 2]
|
||||
|
||||
Internet-Draft Passive DNS - Common Output Format December 2013
|
||||
|
@ -195,20 +195,23 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
|
||||
3.3. ABNF grammar
|
||||
|
||||
ABNF:
|
||||
Formal grammar as defined in ABNF [RFC2234]
|
||||
|
||||
answer = elements
|
||||
elements = * ( element CR)
|
||||
element = "{" keyvallist "}"
|
||||
keyvallist = JSONobject
|
||||
JSONobject = [ member *( value-separator member ) ]
|
||||
member = string name-separator value
|
||||
name-separator = ws %x3A ws ; : colon
|
||||
value = value ; as defined in the JSON RFC
|
||||
answer = entries
|
||||
entries = * ( entry CR)
|
||||
entry = "{" keyvallist "}"
|
||||
keyvallist = [ member *( value-separator member ) ]
|
||||
member = field name-separator value
|
||||
name-separator = ws %x3A ws ; : colon
|
||||
value = value ; as defined in the JSON RFC
|
||||
field = "rrame" | "rrtype" | "rdata" | "time_first" |
|
||||
"time_last" | "count" | "bailiwick" | "sensor_id" |
|
||||
"zone_time_first" | "zone_time_last" | futureField
|
||||
futureField = string
|
||||
CR = %x0D
|
||||
|
||||
Note that value is defined in JSON [RFC4627] and has the exact same
|
||||
specification as there.
|
||||
specification as there. The same goes for the definition of string.
|
||||
|
||||
3.4. Mandatory Fields
|
||||
|
||||
|
@ -217,26 +220,23 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Dulaunoy, et al. Expires June 28, 2014 [Page 4]
|
||||
|
||||
Internet-Draft Passive DNS - Common Output Format December 2013
|
||||
|
||||
|
||||
3.4.1. General remarks on mandatory fields
|
||||
|
||||
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 be an array as defined in JSON [RFC4627]
|
||||
null), rdata MAY be an array as defined in JSON [RFC4627].
|
||||
Implementors of this draft MUST be able to deal with rdata being
|
||||
returned as JSON array or alternatively as a JSON string.
|
||||
|
||||
3.4.2. rrname
|
||||
3.4.1. rrname
|
||||
|
||||
This field returns the name of the queried resource.
|
||||
|
||||
3.4.3. rrtype
|
||||
3.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
|
||||
|
@ -251,7 +251,7 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
addition, a client MUST be able to handle a decimal value (as
|
||||
mentioned above) as answer.
|
||||
|
||||
3.4.4. rdata
|
||||
3.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
|
||||
|
@ -262,14 +262,14 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
unknown DNS resource records, the server must follow the transparency
|
||||
principle as described in RFC 3597 [RFC3597].
|
||||
|
||||
3.4.5. time_first
|
||||
3.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 seconds (decimal ASCII) since 1st of January 1970
|
||||
(Unix timestamp). The time zone MUST be UTC.
|
||||
|
||||
3.4.6. time_last
|
||||
3.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
|
||||
|
@ -298,7 +298,7 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
other type fields has been seen in the given time interval (between
|
||||
time_last and time_first). Decimal number.
|
||||
|
||||
3.5.2. Bailiwick
|
||||
3.5.2. bailiwick
|
||||
|
||||
The bailiwick is the best estimate of the apex of the zone where this
|
||||
data is authoritative. String.
|
||||
|
@ -376,15 +376,15 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
|
||||
Specifications: ABNF", RFC 2234, November 1997.
|
||||
|
||||
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
|
||||
(RR) Types", RFC 3597, September 2003.
|
||||
|
||||
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
|
||||
September 2004.
|
||||
|
||||
[RFC4627] Crockford, D., "The application/json Media Type for
|
||||
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
@ -393,6 +393,9 @@ Dulaunoy, et al. Expires June 28, 2014 [Page 7]
|
|||
Internet-Draft Passive DNS - Common Output Format December 2013
|
||||
|
||||
|
||||
[RFC4627] Crockford, D., "The application/json Media Type for
|
||||
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
|
||||
|
||||
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option",
|
||||
RFC 5001, August 2007.
|
||||
|
||||
|
@ -441,9 +444,6 @@ Internet-Draft Passive DNS - Common Output Format December 2013
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Dulaunoy, et al. Expires June 28, 2014 [Page 8]
|
||||
|
||||
Internet-Draft Passive DNS - Common Output Format December 2013
|
||||
|
|
|
@ -16,6 +16,7 @@
|
|||
<!ENTITY RFC3597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3597.xml">
|
||||
<!ENTITY RFC3912 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">
|
||||
<!ENTITY RFC6648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6648.xml">
|
||||
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
|
||||
|
||||
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
|
||||
]>
|
||||
|
@ -180,24 +181,25 @@ The document does not describe the protocol (e.g. <xref target="RFC3912">WHOIS</
|
|||
]]></artwork></figure>
|
||||
</section>
|
||||
<section title="ABNF grammar">
|
||||
<figure><preamble>ABNF:</preamble><artwork><![CDATA[
|
||||
answer = elements
|
||||
elements = * ( element CR)
|
||||
element = "{" keyvallist "}"
|
||||
keyvallist = JSONobject
|
||||
JSONobject = [ member *( value-separator member ) ]
|
||||
member = string name-separator value
|
||||
name-separator = ws %x3A ws ; : colon
|
||||
value = value ; as defined in the JSON RFC
|
||||
<figure><preamble>Formal grammar as defined in <xref target="RFC2234">ABNF</xref></preamble><artwork><![CDATA[
|
||||
answer = entries
|
||||
entries = * ( entry CR)
|
||||
entry = "{" keyvallist "}"
|
||||
keyvallist = [ member *( value-separator member ) ]
|
||||
member = field name-separator value
|
||||
name-separator = ws %x3A ws ; : colon
|
||||
value = value ; as defined in the JSON RFC
|
||||
field = "rrame" | "rrtype" | "rdata" | "time_first" |
|
||||
"time_last" | "count" | "bailiwick" | "sensor_id" |
|
||||
"zone_time_first" | "zone_time_last" | futureField
|
||||
futureField = string
|
||||
CR = %x0D
|
||||
]]></artwork></figure>
|
||||
<t>Note that value is defined in <xref target="RFC4627">JSON</xref> and has the exact same specification as there.</t>
|
||||
<t>Note that value is defined in <xref target="RFC4627">JSON</xref> and has the exact same specification as there. The same goes for the definition of string.</t>
|
||||
</section>
|
||||
<section title="Mandatory Fields">
|
||||
<t>Implementation MUST support all the mandatory fields.</t>
|
||||
<section title="General remarks on mandatory fields">
|
||||
<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 be an array as defined in <xref target="RFC4627">JSON</xref></t>
|
||||
</section>
|
||||
<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 be an array as defined in <xref target="RFC4627">JSON</xref>. Implementors of this draft MUST be able to deal with rdata being returned as JSON array or alternatively as a JSON string. <!-- MOTE: this is not good --></t>
|
||||
<section title="rrname">
|
||||
<t>This field returns the name of the queried resource.</t>
|
||||
</section>
|
||||
|
@ -226,7 +228,7 @@ CR = %x0D
|
|||
<t>Specifies 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.</t>
|
||||
<t>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.</t>
|
||||
</section>
|
||||
<section title="Bailiwick">
|
||||
<section title="bailiwick">
|
||||
<t>The bailiwick is the best estimate of the apex of the zone where this data is authoritative. String.</t>
|
||||
</section>
|
||||
</section>
|
||||
|
@ -297,6 +299,7 @@ CR = %x0D
|
|||
&RFC5001;
|
||||
&RFC3597;
|
||||
&RFC6648;
|
||||
&RFC2234;
|
||||
</references>
|
||||
<references>
|
||||
<reference anchor="WEINERPDNS" target="http://www.enyo.de/fw/software/dnslogger/first2005-paper.pdf">
|
||||
|
|
Loading…
Reference in a new issue