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

add: clarification that the document is covering current best practices

Browse source 
and a simple explanation of the GDPR aspect
This commit is contained in:
Alexandre Dulaunoy 2018-06-20 21:54:52 +02:00
parent 4b045912cd
commit 01778789d6
Signed by: adulau
GPG key ID: 09E2CD4944E6CBCD
1 changed files with 3 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -151,7 +151,7 @@
The benefit of having a consistent Passive DNS output format is that multiple client implementations can query different servers without having to have a separate parser for each The benefit of having a consistent Passive DNS output format is that multiple client implementations can query different servers without having to have a separate parser for each
individual server. <xref target="PDNSCLIENT">passivedns-client</xref> currently implements multiple parsers due to a lack of standardization. individual server. <xref target="PDNSCLIENT">passivedns-client</xref> currently implements multiple parsers due to a lack of standardization.
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. Both of these are separate topics and deserve their own RFC document. 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. Both of these are separate topics and deserve their own RFC document. The document describes the current best practices implemented in various Passive DNS server implementations.
</t> </t>
<section title="Requirements Language"> <section title="Requirements Language">
@ -278,6 +278,7 @@ ws = *(
Nevertheless, the authors strongly encourage Passive DNS implementors to take special care of privacy issues. bortzmeyer-dnsop-dns-privacy is an excellent starting point for this. Nevertheless, the authors strongly encourage Passive DNS implementors to take special care of privacy issues. 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> 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>
<t>In the scope of the General Data Protection Regulation (GDPR - Directive 95/46/EC), operators of Passive DNS Server needs to ensure the legal ground and lawfulness of its operation.</t>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" title="Security Considerations">
<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> <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>