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 Engineering Task Force A. Dulaunoy
Internet-Draft CIRCL Internet-Draft CIRCL
Intended status: Informational A. Kaplan Intended status: Informational A. Kaplan
Expires: August 31, 2014 CERT.at Expires: September 1, 2014 CERT.at
P. Vixie P. Vixie
H. Stern H. Stern
Farsight Security, Inc. Farsight Security, Inc.
February 27, 2014 February 28, 2014
Passive DNS - Common Output Format Passive DNS - Common Output Format
@ -39,7 +39,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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 Internet-Draft Passive DNS - Common Output Format February 2014
@ -84,12 +84,12 @@ Table of Contents
3.5. Additional Fields . . . . . . . . . . . . . . . . . . . . 6 3.5. Additional Fields . . . . . . . . . . . . . . . . . . . . 6
3.5.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 6 3.5.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 6
3.5.2. zone_time_first . . . . . . . . . . . . . . . . . . . 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 3.6. Additional Fields Registry . . . . . . . . . . . . . . . 7
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. 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 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 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 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 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 3.5.1. sensor_id
This field returns the sensor information where the record was seen. 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 It is represented as a JSON [RFC4627] string.
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.
3.5.2. zone_time_first 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 timestamp). The time zone MUST be UTC. This field is represented as
a JSON [RFC4627] number. 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 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, This field returns the last time that the unique tuple (rrname,
rrtype, rdata) record has been seen via master file import. The date rrtype, rdata) record has been seen via master file import. The date
is expressed in seconds (decimal) since 1st of January 1970 (Unix 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 phone books - if public DNS records can be compared to phone numbers
- as they often are. Nevertheless, the authors strongly encourage - as they often are. Nevertheless, the authors strongly encourage
Passive DNS implementors to take special care of privacy issues. Passive DNS implementors to take special care of privacy issues.
[draft-bortzmeyer-dnsop-dns-privacy] is an excellent starting point bortzmeyer-dnsop-dns-privacy is an excellent starting point for this.
for this. Finally, the overall recommendations in RFC6973 [RFC6973] Finally, the overall recommendations in RFC6973 [RFC6973] should be
should be taken into consideration when designing any application taken into consideration when designing any application which uses
which uses Passive DNS data. Passive DNS data.
7. Security Considerations
Dulaunoy, et al. Expires September 1, 2014 [Page 7]
Dulaunoy, et al. Expires August 31, 2014 [Page 7]
Internet-Draft Passive DNS - Common Output Format February 2014 Internet-Draft Passive DNS - Common Output Format February 2014
7. Security Considerations
In some cases, Passive DNS output might contain confidential In some cases, Passive DNS output might contain confidential
information and its access might be restricted. When a user is information and its access might be restricted. When a user is
querying multiple Passive DNS and aggregating the data, the 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 8.2. References
[BAILIWICK] [BAILIWICK]
Dulaunoy, et al. Expires August 31, 2014 [Page 8]
Internet-Draft Passive DNS - Common Output Format February 2014
"Passive DNS Hardening", 2010, <https:// "Passive DNS Hardening", 2010, <https://
archive.farsightsecurity.com/Passive_DNS/ archive.farsightsecurity.com/Passive_DNS/
passive_dns_hardening_handout.pdf>. passive_dns_hardening_handout.pdf>.
Dulaunoy, et al. Expires September 1, 2014 [Page 8]
Internet-Draft Passive DNS - Common Output Format February 2014
[CACHEPOISONING] [CACHEPOISONING]
"Black ops 2008: It's the end of the cache as we know "Black ops 2008: It's the end of the cache as we know
it.", 2008, <http://kurser.lobner.dk/dDist/DMK_BO2K8.pdf>. 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 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 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.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' ?> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
@ -234,7 +234,7 @@ ws = *(
<section title="Additional Fields"> <section title="Additional Fields">
<t>Implementations MAY support the following fields:</t> <t>Implementations MAY support the following fields:</t>
<section title="sensor_id"> <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>
<section title="zone_time_first"> <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> <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"> <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. <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> 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>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" title="Security Considerations">