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

References added and clarification regarding RFC3597

Browse source
This commit is contained in:
Alexandre Dulaunoy 2013-04-02 18:20:38 +02:00
parent 4f56b5e285
commit bddb878456
1 changed files with 9 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -12,6 +12,8 @@
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC4627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627.xml">
<!ENTITY RFC5001 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5001.xml">
<!ENTITY RFC3597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3597.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
@ -178,24 +180,22 @@ The document does not describe the protocol (e.g. whois, HTTP REST or XMPP) used
</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. If the value cannot be interpreted the
decimal value is returned.
decimal value is returned following the principle of transparency as described in <xref target="RFC3597">RFC 3597</xref>.
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
</t>
</section>
<section title="rdata">
<t>This 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 <xref target="RFC1035">RFC 1035</xref> and <xref target="RFC1034">RFC 1034</xref>.
XXX reference to RFC 3597.XXX</t>
<t>This 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 <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>. (binary stream if any? base64?)
</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 ascii) since 1st of January 1970 (unix timestamp). The time zone MUST be UTC.</t>
</section>
<section title="time_last">
<t>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.</t>
<t>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..</t>
</section>
</section>
<section title="Optional Fields">
@ -211,7 +211,7 @@ The document does not describe the protocol (e.g. whois, HTTP REST or XMPP) used
<section title="Additional Fields">
<t>Implementations MAY support the following fields:</t>
<section title="x-sensor_id">
<t>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))</t>
<t>This field returns the sensor information where the record was seen. The sensor_id is an opaque byte string as defined by <xref target="RFC5001"> RFC 5001 in section 2.3</xref>.</t>
</section>
</section>
@ -261,6 +261,8 @@ The document does not describe the protocol (e.g. whois, HTTP REST or XMPP) used
&RFC1035;
&RFC1034;
&RFC4627;
&RFC5001;
&RFC3597;
<reference anchor="min_ref">
<!-- the following is the minimum to make xml2rfc happy -->