adulau/pdns-qof
1
0
Fork 0
mirror of https://github.com/adulau/pdns-qof.git synced 2024-10-05 22:11:42 +00:00
Code Issues Projects Releases Packages Wiki Activity

Only xmllint fixes

Browse source 
Confirmed by running xml2rfc and checking that the resulting .txt matches the prior version.
This commit is contained in:
Warren Kumari 2024-05-10 18:12:17 -04:00
parent 7863b019e8
commit 14a31f7623
1 changed files with 194 additions and 237 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -4,9 +4,7 @@
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
An alternate method (rfc include) is described in the references. --><!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!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">
@ -17,11 +15,8 @@
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY RFC6973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.draft-bortzmeyer-dnsop-dns-privacy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-bortzmeyer-dnsop-dns-privacy">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
@ -53,19 +48,16 @@
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Passive DNS - Common Output Format">Passive DNS - Common Output Format</title>
<author fullname="Alexandre Dulaunoy" initials="A."
surname="Dulaunoy">
<author fullname="Alexandre Dulaunoy" initials="A." surname="Dulaunoy">
<organization>CIRCL</organization>
<address>
<postal>
<street>122, rue Adolphe Fischer</street>
<city>Luxembourg</city>
<region></region>
<region/>
<code>L-1521</code>
<country>Luxembourg</country>
</postal>
@ -75,28 +67,23 @@
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="L. Aaron Kaplan" initials="A."
surname="Kaplan">
<organization></organization>
<author fullname="L. Aaron Kaplan" initials="A." surname="Kaplan">
<organization/>
<address>
<postal>
<street>
</street>
<city>Vienna</city>
<region></region>
<region/>
<code>A-1170</code>
<country>Austria</country>
</postal>
<phone></phone>
<phone/>
<email>aaron@lo-res.org</email>
<uri></uri>
<uri/>
</address>
</author>
<author fullname="Paul Vixie" initials="P."
surname="Vixie">
<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Farsight Security, Inc.</organization>
<address>
<postal>
@ -106,12 +93,11 @@
<code>94062</code>
<country>USA</country>
</postal>
<phone></phone>
<phone/>
<email>paul@redbarn.org</email>
<uri>https://www.farsightsecurity.com/</uri>
</address>
</author>
<author fullname="Henry Stern" initials="H." surname="Stern">
<organization>Farsight Security, Inc.</organization>
<address>
@ -127,27 +113,20 @@
<uri>https://www.farsightsecurity.com/</uri>
</address>
</author>
<author initials="W." surname="Kumari" fullname="Warren Kumari">
<organization>Google</organization>
<address>
<email>warren@kumari.net</email>
</address>
</author>
<date day="27" month="April" year="2024" />
<date day="27" month="April" year="2024"/>
<area>General</area>
<workgroup>Domain Name System Operations</workgroup>
<keyword>dns</keyword>
<abstract>
<t>This document describes a common output format of Passive DNS Servers that clients can query. The output format description also includes a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Passive DNS is a technique described by Florian Weimer in 2005 in <xref target="WEIMERPDNS">Passive DNS replication, F Weimer - 17th Annual FIRST Conference on Computer Security</xref>. Since then, multiple Passive DNS implementations were created and have evolved over time. Users of these Passive DNS servers may query a server (often via <xref target="RFC3912">WHOIS</xref> or HTTP <xref target="REST">REST</xref>), parse the results, and process them in other applications.</t>
@ -160,15 +139,12 @@ individual server. <xref target="PDNSCLIENT">passivedns-client</xref> currently
The document does not describe the protocol (e.g. <xref target="RFC3912">WHOIS</xref>, HTTP <xref target="REST">REST</xref>) nor the query format used to query the Passive DNS. Neither does this document describe "pre-recursor" Passive DNS Systems. Each of these are separate topics and deserve their own RFC documents. This document describes the current best practices implemented in various Passive DNS server implementations.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Limitation">
<t> As Passive DNS servers 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 criteria. The <xref target="BAILIWICK">bailiwick algorithm</xref> protects the Passive DNS Database from <xref target="CACHEPOISONING">cache poisoning attacks</xref>.
@ -178,11 +154,14 @@ The document does not describe the protocol (e.g. <xref target="RFC3912">WHOIS</
<section title="Common Output Format">
<section title="Overview">
<t>The formatting of the answer follows the <xref target="RFC4627">JSON</xref> format. In fact, it is a subset of the full JSON language. Notable differences are the modified definition of whitespace ("ws"). The order of the fields is not significant for the same resource type. </t>
<t>The intent of this output format is to be easily parsable by scripts. Each JSON object is expressed on a single line to be processed by the client line-by-line. Every implementation MUST support the JSON output format.</t> <!-- note: it is "parsable" if you want to be really nit-picking. See: https://en.wiktionary.org/wiki/parsable -->
<t>The intent of this output format is to be easily parsable by scripts. Each JSON object is expressed on a single line to be processed by the client line-by-line. Every implementation MUST support the JSON output format.</t>
<!-- note: it is "parsable" if you want to be really nit-picking. See: https://en.wiktionary.org/wiki/parsable -->
<t><xref target="app-additional">Examples of JSON</xref> output are in the appendix.</t>
</section>
<section title="ABNF grammar">
<figure><preamble>Formal grammar as defined in <xref target="RFC2234">ABNF</xref></preamble><artwork><![CDATA[
<figure>
<preamble>Formal grammar as defined in <xref target="RFC2234">ABNF</xref></preamble>
<artwork><![CDATA[
answer = entries
entries = * ( entry newline )
entry = ws "{" ws keyvallist ws "}" ws
@ -205,7 +184,8 @@ ws = *(
%x09 ; Horizontal tab
)
]]></artwork></figure>
]]></artwork>
</figure>
<t>Note that value is defined in <xref target="RFC4627">JSON</xref> and has the same specification as there. The same goes for the definition of string. Note the changed definition of ws does not include CR or LF as those are NOT allowed in NDJSON, and thus the definition here MUST be used for other ABNF defitions in <xref target="RFC4627">JSON</xref>.</t>
</section>
<section title="Mandatory Fields">
@ -276,26 +256,15 @@ ws = *(
<t>An implementer of a passive DNS Server SHOULD serve a document in this Common Output Format with a MIME header of "application/x-ndjson".</t>
</section>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to the Passive DNS developers who contributed to the document.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>Passive DNS Servers capture DNS answers from multiple collection points ("sensors") which are located on the Internet-facing side of DNS recursors ("post-recursor passive DNS"). In this process, they intentionally omit the source IP, source port, destination IP and destination port from the captured packets. Since the data is captured "post-recursor", the timing information (who queries what) is lost, since the recursor will cache the results. Furthermore, since multiple sensors feed into a passive DNS server, the resulting data gets mixed together, reducing the likelihood that Passive DNS Servers are able to find out much about the actual person querying the DNS records. In this sense, passive DNS Servers are similar to keeping an archive of all previous phone books - if public DNS records can be compared to phone numbers - as they often are.
@ -307,12 +276,9 @@ ws = *(
<t>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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
@ -323,9 +289,7 @@ ws = *(
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<references title="Normative References"><!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC1035;
&RFC1034;
@ -416,31 +380,27 @@ ws = *(
</front>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- &I-D.narten-iana-considerations-rfc2434bis; -->
<!-- &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 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[
<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[
{"count": 102, "time_first": 1298412391, "rrtype": "AAAA",
"rrname": "www.ietf.org", "rdata": "2001:1890:1112:1::20",
"time_last": 1302506851}
{"count": 59, "time_first": 1384865833, "rrtype": "A",
"rrname": "www.ietf.org", "rdata": "4.31.198.44",
"time_last": 1389022219}
]]>
</artwork></figure>
<t>If you query a passive DNS for the rrname ietf.org, the passive dns common output format can be:</t>
<figure><artwork>
<![CDATA[
]]></artwork>
</figure>
<t>If you query a passive DNS for the rrname ietf.org, the passive dns common output format can be:</t>
<figure>
<artwork><![CDATA[
{"count": 109877, "time_first": 1298398002, "rrtype": "NS",
"rrname": "ietf.org", "rdata": "ns1.yyz1.afilias-nst.info",
"time_last": 1389095375}
@ -450,13 +410,10 @@ ws = *(
{"count": 9, "time_first": 1317037550, "rrtype": "AAAA",
"rrname": "ietf.org", "rdata": "2001:1890:123a::1:1e",
"time_last": 1330209752}
]]>
</artwork></figure>
]]></artwork>
</figure>
<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>
</rfc>