Regenerated including update for sensor_id

This commit is contained in:
Alexandre Dulaunoy 2014-02-28 06:53:48 +01:00
parent e3d8f07fbc
commit 5fac85e4a5
2 changed files with 42 additions and 42 deletions

View file

@ -5,11 +5,11 @@
Internet Engineering Task Force A. Dulaunoy
Internet-Draft CIRCL
Intended status: Informational A. Kaplan
Expires: August 31, 2014 CERT.at
Expires: September 1, 2014 CERT.at
P. Vixie
H. Stern
Farsight Security, Inc.
February 27, 2014
February 28, 2014
Passive DNS - Common Output Format
@ -39,7 +39,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 31, 2014.
This Internet-Draft will expire on September 1, 2014.
Copyright Notice
@ -53,7 +53,7 @@ Copyright Notice
Dulaunoy, et al. Expires August 31, 2014 [Page 1]
Dulaunoy, et al. Expires September 1, 2014 [Page 1]
Internet-Draft Passive DNS - Common Output Format February 2014
@ -84,12 +84,12 @@ Table of Contents
3.5. Additional Fields . . . . . . . . . . . . . . . . . . . . 6
3.5.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 6
3.5.2. zone_time_first . . . . . . . . . . . . . . . . . . . 6
3.5.3. zone_time_last . . . . . . . . . . . . . . . . . . . 6
3.5.3. zone_time_last . . . . . . . . . . . . . . . . . . . 7
3.6. Additional Fields Registry . . . . . . . . . . . . . . . 7
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. References . . . . . . . . . . . . . . . . . . . . . . . 8
@ -109,7 +109,7 @@ Table of Contents
Dulaunoy, et al. Expires August 31, 2014 [Page 2]
Dulaunoy, et al. Expires September 1, 2014 [Page 2]
Internet-Draft Passive DNS - Common Output Format February 2014
@ -165,7 +165,7 @@ Internet-Draft Passive DNS - Common Output Format February 2014
Dulaunoy, et al. Expires August 31, 2014 [Page 3]
Dulaunoy, et al. Expires September 1, 2014 [Page 3]
Internet-Draft Passive DNS - Common Output Format February 2014
@ -221,7 +221,7 @@ Internet-Draft Passive DNS - Common Output Format February 2014
Dulaunoy, et al. Expires August 31, 2014 [Page 4]
Dulaunoy, et al. Expires September 1, 2014 [Page 4]
Internet-Draft Passive DNS - Common Output Format February 2014
@ -277,7 +277,7 @@ Internet-Draft Passive DNS - Common Output Format February 2014
Dulaunoy, et al. Expires August 31, 2014 [Page 5]
Dulaunoy, et al. Expires September 1, 2014 [Page 5]
Internet-Draft Passive DNS - Common Output Format February 2014
@ -315,10 +315,7 @@ Internet-Draft Passive DNS - Common Output Format February 2014
3.5.1. sensor_id
This field returns the sensor information where the record was seen.
The sensor_id is an opaque byte string as defined by RFC 5001 in
section 2.3 [RFC5001]. The sensor_id MUST be escaped as defined in
section 2.6 of RFC4627 [RFC4627]. This field is represented as a
JSON [RFC4627] string.
It is represented as a JSON [RFC4627] string.
3.5.2. zone_time_first
@ -328,16 +325,21 @@ Internet-Draft Passive DNS - Common Output Format February 2014
timestamp). The time zone MUST be UTC. This field is represented as
a JSON [RFC4627] number.
3.5.3. zone_time_last
Dulaunoy, et al. Expires August 31, 2014 [Page 6]
Dulaunoy, et al. Expires September 1, 2014 [Page 6]
Internet-Draft Passive DNS - Common Output Format February 2014
3.5.3. zone_time_last
This field returns the last time that the unique tuple (rrname,
rrtype, rdata) record has been seen via master file import. The date
is expressed in seconds (decimal) since 1st of January 1970 (Unix
@ -376,26 +378,22 @@ Internet-Draft Passive DNS - Common Output Format February 2014
phone books - if public DNS records can be compared to phone numbers
- as they often are. Nevertheless, the authors strongly 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 RFC6973 [RFC6973]
should be taken into consideration when designing any application
which uses Passive DNS data.
bortzmeyer-dnsop-dns-privacy is an excellent starting point for this.
Finally, the overall recommendations in RFC6973 [RFC6973] should be
taken into consideration when designing any application which uses
Passive DNS data.
7. Security Considerations
Dulaunoy, et al. Expires August 31, 2014 [Page 7]
Dulaunoy, et al. Expires September 1, 2014 [Page 7]
Internet-Draft Passive DNS - Common Output Format February 2014
7. Security Considerations
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
@ -441,19 +439,17 @@ Internet-Draft Passive DNS - Common Output Format February 2014
8.2. References
[BAILIWICK]
Dulaunoy, et al. Expires August 31, 2014 [Page 8]
Internet-Draft Passive DNS - Common Output Format February 2014
"Passive DNS Hardening", 2010, <https://
archive.farsightsecurity.com/Passive_DNS/
passive_dns_hardening_handout.pdf>.
Dulaunoy, et al. Expires September 1, 2014 [Page 8]
Internet-Draft Passive DNS - Common Output Format February 2014
[CACHEPOISONING]
"Black ops 2008: It's the end of the cache as we know
it.", 2008, <http://kurser.lobner.dk/dDist/DMK_BO2K8.pdf>.
@ -501,7 +497,11 @@ Internet-Draft Passive DNS - Common Output Format February 2014
Dulaunoy, et al. Expires August 31, 2014 [Page 9]
Dulaunoy, et al. Expires September 1, 2014 [Page 9]
Internet-Draft Passive DNS - Common Output Format February 2014
@ -557,7 +557,7 @@ Authors' Addresses
Dulaunoy, et al. Expires August 31, 2014 [Page 10]
Dulaunoy, et al. Expires September 1, 2014 [Page 10]
Internet-Draft Passive DNS - Common Output Format February 2014
@ -613,4 +613,4 @@ Internet-Draft Passive DNS - Common Output Format February 2014
Dulaunoy, et al. Expires August 31, 2014 [Page 11]
Dulaunoy, et al. Expires September 1, 2014 [Page 11]

View file

@ -21,7 +21,7 @@
<!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 -->
<!-- <!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' ?>
@ -234,7 +234,7 @@ ws = *(
<section title="Additional Fields">
<t>Implementations MAY support the following fields:</t>
<section title="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 <xref target="RFC5001"> RFC 5001 in section 2.3</xref>. The sensor_id MUST be escaped as defined in section 2.6 of <xref target="RFC4627">RFC4627</xref>. This field is represented as a <xref target="RFC4627">JSON</xref> string.</t>
<t>This field returns the sensor information where the record was seen. It is represented as a <xref target="RFC4627">JSON</xref> string.</t>
</section>
<section title="zone_time_first">
<t>This field returns the first time that the unique tuple (rrname, rrtype, rdata) record has been seen via master file import. The date is expressed in seconds (decimal) since 1st of January 1970 (Unix timestamp). The time zone MUST be UTC. This field is represented as a <xref target="RFC4627">JSON</xref> number.</t>
@ -270,7 +270,7 @@ ws = *(
<section anchor="Privacy" title="Privacy Considerations">
<t>Passive DNS Servers capture DNS answers from multiple collecting 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 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 strongly encourage Passive DNS implementors to take special care of privacy issues. [draft-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>
</section>
<section anchor="Security" title="Security Considerations">