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

Draft draft-bortzmeyer-dnsop-dns-privacy reference added

Browse source 
As bibxml3 is missing the draft, it's still a comment.
This commit is contained in:
Alexandre Dulaunoy 2013-12-27 09:46:30 +01:00
parent 8b08446d47
commit e4b9e14ae1
1 changed files with 6 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -20,6 +20,9 @@
<!ENTITY RFC6973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.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"> TO ENABLE when bibxml3 is back to normal -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
@ -209,7 +212,7 @@ CR = %x0D
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 descriptions of rrtypes are: A, AAAA, CNAME, PTR, SOA, TXT, DNAME, NS, SRV, RP, NAPTR, HINFO, A6.
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 rtype values. In addition, a client MUST be able to handle a decimal value (as mentioned above) as answer.
</t>
</section>
@ -272,8 +275,7 @@ CR = %x0D
<section anchor="Privacy" title="Privacy Considerations">
<t>Passive DNS Servers collect DNS answers from multiple collecting points ("sensors") which are located on the Internet-facing side of DNS recursors. In this process, they intentionally omit the source IP, source port, destination IP and destination port. 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 nor who actually sent the query. 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.
Nevertheless, the authors encourage Passive DNS implementors to take special care of privacy issues. <!-- FIXME: add reference / link --> draft-bortzmeyer-dnsop-dns-privacy-01.txt is an excellent starting point for this.
Nevertheless, the authors encourage Passive DNS implementors to take special care of privacy issues. [draft-bortzmeyer-dnsop-dns-privacy] is an excellent starting point for this.
Finally, the overall recommendations in <xref target="RFC6973">RFC6973</xref> should be taken into consideration when designing any application which uses Passive DNS data.</t>
</section>
<section anchor="Security" title="Security Considerations">
@ -384,6 +386,7 @@ CR = %x0D
&I-D.narten-iana-considerations-rfc2434bis;
<!-- &I-D.draft-bortzmeyer-dnsop-dns-privacy; -->
</references>
</back>