chg: [I-D] regenerated

This commit is contained in:
Alexandre Dulaunoy 2024-08-29 11:31:04 +02:00
parent a96d6e9f87
commit 3c659e9616
Signed by: adulau
GPG key ID: 09E2CD4944E6CBCD
2 changed files with 284 additions and 228 deletions

Binary file not shown.

View file

@ -5,21 +5,21 @@
Domain Name System Operations A. Dulaunoy Domain Name System Operations A. Dulaunoy
Internet-Draft CIRCL Internet-Draft CIRCL
Intended status: Informational A. Kaplan Intended status: Informational A. Kaplan
Expires: 29 October 2024 Expires: 28 February 2025
P. Vixie P. Vixie
H. Stern H. Stern
Farsight Security, Inc. Farsight Security, Inc.
W. Kumari W. Kumari
Google Google
27 April 2024 27 August 2024
Passive DNS - Common Output Format Passive DNS - Common Output Format
draft-dulaunoy-dnsop-passive-dns-cof-11 draft-dulaunoy-dnsop-passive-dns-cof-12
Abstract Abstract
This document describes a common output format of Passive DNS Servers This document describes a common output format of Passive DNS servers
that clients can query. The output format description also includes that clients can query. The output format description also includes
a common semantic for each Passive DNS system. By having multiple a common semantic for each Passive DNS system. By having multiple
Passive DNS Systems adhere to the same output format for queries, Passive DNS Systems adhere to the same output format for queries,
@ -41,7 +41,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 29 October 2024. This Internet-Draft will expire on 28 February 2025.
Copyright Notice Copyright Notice
@ -53,9 +53,9 @@ Copyright Notice
Dulaunoy, et al. Expires 29 October 2024 [Page 1] Dulaunoy, et al. Expires 28 February 2025 [Page 1]
Internet-Draft Passive DNS - Common Output Format April 2024 Internet-Draft Passive DNS - Common Output Format August 2024
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
@ -70,80 +70,114 @@ Internet-Draft Passive DNS - Common Output Format April 2024
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Limitation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Common Output Format . . . . . . . . . . . . . . . . . . . . 4 3. Common Output Format . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. ABNF grammar . . . . . . . . . . . . . . . . . . . . . . 4 3.2. ABNF grammar . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Mandatory Fields . . . . . . . . . . . . . . . . . . . . 5 3.3. Mandatory Fields . . . . . . . . . . . . . . . . . . . . 5
3.3.1. rrname . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. rrname . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . 5 3.3.2. rrtype . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3.3. rdata . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.4. time_first . . . . . . . . . . . . . . . . . . . . . 6 3.3.4. time_first . . . . . . . . . . . . . . . . . . . . . 6
3.3.5. time_last . . . . . . . . . . . . . . . . . . . . . . 6 3.3.5. time_last . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Optional Fields . . . . . . . . . . . . . . . . . . . . . 6 3.4. Optional Fields . . . . . . . . . . . . . . . . . . . . . 7
3.4.1. count . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4.1. count . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . 7 3.4.2. bailiwick . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Additional Fields . . . . . . . . . . . . . . . . . . . . 7 3.5. Additional Fields . . . . . . . . . . . . . . . . . . . . 7
3.5.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 7 3.5.1. sensor_id . . . . . . . . . . . . . . . . . . . . . . 7
3.5.2. zone_time_first . . . . . . . . . . . . . . . . . . . 7 3.5.2. zone_time_first . . . . . . . . . . . . . . . . . . . 7
3.5.3. zone_time_last . . . . . . . . . . . . . . . . . . . 7 3.5.3. zone_time_last . . . . . . . . . . . . . . . . . . . 8
3.5.4. origin . . . . . . . . . . . . . . . . . . . . . . . 7 3.5.4. origin . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.5. time_first_ms . . . . . . . . . . . . . . . . . . . . 7 3.5.5. time_first_ms . . . . . . . . . . . . . . . . . . . . 8
3.5.6. time_last_ms . . . . . . . . . . . . . . . . . . . . 8 3.5.6. time_last_ms . . . . . . . . . . . . . . . . . . . . 8
3.6. Additional Fields Registry . . . . . . . . . . . . . . . 8 3.6. Additional Fields Registry . . . . . . . . . . . . . . . 8
3.7. Additional notes . . . . . . . . . . . . . . . . . . . . 8 3.7. Additional notes . . . . . . . . . . . . . . . . . . . . 8
3.8. Suggested MIME Types . . . . . . . . . . . . . . . . . . 8 3.8. Suggested MIME Types . . . . . . . . . . . . . . . . . . 8
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 11
8.2. References . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Dulaunoy, et al. Expires 29 October 2024 [Page 2]
Dulaunoy, et al. Expires 28 February 2025 [Page 2]
Internet-Draft Passive DNS - Common Output Format April 2024 Internet-Draft Passive DNS - Common Output Format August 2024
1. Introduction 1. Introduction
Passive DNS is a technique described by Florian Weimer in 2005 in Passive DNS is a technique described by Florian Weimer in 2005 in
Passive DNS replication, F Weimer - 17th Annual FIRST Conference on Passive DNS replication, F Weimer - 17th Annual FIRST Conference on
Computer Security [WEIMERPDNS]. Since then, multiple Passive DNS Computer Security [WEIMERPDNS]. It is a mechanism for logging DNS
implementations were created and have evolved over time. Users of answers in a manner intended to minimize the privacy implications to
these Passive DNS servers may query a server (often via WHOIS users, and is widely by security researchers to investigate malware
[RFC3912] or HTTP REST [REST]), parse the results, and process them (for example to discover command and control servers), and other
in other applications. security threats. By capturing only the "cache fill" DNS responses
(responses from authoritative servers in response to queries
performed by a recursive resolver when iteratively resolving a name),
Passive DNS does not have access to the client (users) source IP,
source port, destination IP, or destination port.
There are multiple implementations of Passive DNS software. Users of As these answers are served in response to queries originally
Passive DNS query each implementation and aggregate the results for initiated by user devices, the Passive DNS data can be used to detect
their search. This document describes the output format of four if devices using the resolver are connecting to known malicious
Passive DNS Systems ([DNSDB], [DNSDBQ] , [PDNSCERTAT], [PDNSCIRCL] domains, without identifying the individual users / devices. In
and [PDNSCOF]) that are in use today and that already share a nearly addition, as answers are responses to queries made by the recursive
identical output format. As the format and the meaning of output server itself, Passive DNS records the answers which are ultimately
fields from each Passive DNS need to be consistent, this document served to users. This is important as authoritative servers may
proposes a solution to commonly name each field along with its serve different answers to different query addresses, for example to
corresponding interpretation. The format follows a simple key-value increase performance (e.g Client Subnet in DNS Queries [RFC7871]) or
structure in JSON [RFC4627] format. The benefit of having a to hide malicious behavior when queried from addresses known to be
consistent Passive DNS output format is that multiple client associated with security researchers.
implementations can query different servers without having to have a
separate parser for each individual server. passivedns-client Passive DNS is usually implemented either by capturing DNS response
[PDNSCLIENT] currently implements multiple parsers due to a lack of packets themselves (i.e packets with a destination address of the
standardization. The document does not describe the protocol (e.g. recursive resolver, a source port of 53, and the QR bit set to 1) or
WHOIS [RFC3912], HTTP REST [REST]) nor the query format used to query by having the DNS software itself log these responses. The latter
the Passive DNS. Neither does this document describe "pre-recursor" method is likely to become more common as recursive to authoritative
Passive DNS Systems. Each of these are separate topics and deserve DNS communication becomes encrypted.
their own RFC documents. This document describes the current best
practices implemented in various Passive DNS server implementations. Multiple Passive DNS implementations and services exist. Users of
these Passive DNS services may query a server (often via WHOIS
[RFC3912] or HTTP REST [REST]), parse the results, and process them
in other applications. Users of Passive DNS query each
implementation and aggregate the results for their search. This
document describes the output format of four Passive DNS Systems
([DNSDB], [DNSDBQ] , [PDNSCERTAT], [PDNSCIRCL] and [PDNSCOF]) that
are in use today and that already share a nearly identical output
format. As the format and the meaning of output fields from each
Passive DNS need to be consistent, this document proposes a solution
to commonly name each field along with its corresponding
interpretation. The format follows a simple key-value structure in
JSON [RFC4627] format. 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
Dulaunoy, et al. Expires 28 February 2025 [Page 3]
Internet-Draft Passive DNS - Common Output Format August 2024
individual server. passivedns-client [PDNSCLIENT] currently
implements multiple parsers due to a lack of standardization. The
document does not describe the protocol (e.g. WHOIS [RFC3912], HTTP
REST [REST]) 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.
1.1. Requirements Language 1.1. Requirements Language
@ -151,26 +185,18 @@ Internet-Draft Passive DNS - Common Output Format April 2024
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Limitation 2. Limitations
As Passive DNS servers can include protection mechanisms for their As Passive DNS servers can include protection mechanisms for their
operation, results might be different due to those protection operation, results might be different due to those protection
measures. These mechanisms filter out DNS answers if they fail some measures. These mechanisms filter out DNS answers if they fail some
criteria. The bailiwick algorithm [BAILIWICK] protects the Passive criteria. The bailiwick algorithm [BAILIWICK] protects the Passive
DNS Database from cache poisoning attacks [CACHEPOISONING]. Another DNS Database from cache poisoning attacks. Another limitation that
limitation that clients querying the database need to be aware of is clients querying the database need to be aware of is that each query
that each query simply gets a snapshot-in-time answer at the time of simply gets a snapshot-in-time answer at the time of querying.
querying. Clients MUST NOT rely on existing answers from different Clients MUST NOT rely on existing answers from different Passive DNS
Passive DNS database. Nor should they assume that answers will be database. Nor should they assume that answers will be identical
across multiple Passive DNS servers.
Dulaunoy, et al. Expires 29 October 2024 [Page 3]
Internet-Draft Passive DNS - Common Output Format April 2024
identical across multiple Passive DNS Servers.
3. Common Output Format 3. Common Output Format
@ -192,6 +218,14 @@ Internet-Draft Passive DNS - Common Output Format April 2024
Formal grammar as defined in ABNF [RFC2234] Formal grammar as defined in ABNF [RFC2234]
Dulaunoy, et al. Expires 28 February 2025 [Page 4]
Internet-Draft Passive DNS - Common Output Format August 2024
answer = entries answer = entries
entries = * ( entry newline ) entries = * ( entry newline )
entry = ws "{" ws keyvallist ws "}" ws entry = ws "{" ws keyvallist ws "}" ws
@ -215,16 +249,7 @@ Internet-Draft Passive DNS - Common Output Format April 2024
) )
Figure 1
Dulaunoy, et al. Expires 29 October 2024 [Page 4]
Internet-Draft Passive DNS - Common Output Format April 2024
Note that value is defined in JSON [RFC4627] and has the same Note that value is defined in JSON [RFC4627] and has the same
specification as there. The same goes for the definition of string. specification as there. The same goes for the definition of string.
@ -246,6 +271,17 @@ Internet-Draft Passive DNS - Common Output Format April 2024
Senders SHOULD send an array for rdata, but receivers MUST be able to Senders SHOULD send an array for rdata, but receivers MUST be able to
accept a single-string result for rdata. accept a single-string result for rdata.
Dulaunoy, et al. Expires 28 February 2025 [Page 5]
Internet-Draft Passive DNS - Common Output Format August 2024
3.3.1. rrname 3.3.1. rrname
This field returns the name of the queried resource. Represented as This field returns the name of the queried resource. Represented as
@ -268,20 +304,6 @@ Internet-Draft Passive DNS - Common Output Format April 2024
a decimal value (as mentioned above) answer represented as a JSON a decimal value (as mentioned above) answer represented as a JSON
[RFC4627] number. [RFC4627] number.
Dulaunoy, et al. Expires 29 October 2024 [Page 5]
Internet-Draft Passive DNS - Common Output Format April 2024
3.3.3. rdata 3.3.3. rdata
This field returns the resource records of the queried resource. This field returns the resource records of the queried resource.
@ -306,6 +328,16 @@ Internet-Draft Passive DNS - Common Output Format April 2024
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.
Dulaunoy, et al. Expires 28 February 2025 [Page 6]
Internet-Draft Passive DNS - Common Output Format August 2024
3.3.5. time_last 3.3.5. time_last
This field returns the last time that the unique tuple (rrname, This field returns the last time that the unique tuple (rrname,
@ -321,23 +353,12 @@ Internet-Draft Passive DNS - Common Output Format April 2024
3.4.1. count 3.4.1. count
Specifies how many authoritative DNS answers were received at the Specifies how many authoritative DNS answers were received at the
Passive DNS Server's collectors with exactly the given set of values Passive DNS server's collectors with exactly the given set of values
as answers (i.e. same data in the answer set - compare with the as answers (i.e. same data in the answer set - compare with the
uniqueness property in "Mandatory Fields"). The number of requests uniqueness property in "Mandatory Fields"). The number of requests
is expressed as a decimal value. This field is represented as a JSON is expressed as a decimal value. This field is represented as a JSON
[RFC4627] number. [RFC4627] number.
Dulaunoy, et al. Expires 29 October 2024 [Page 6]
Internet-Draft Passive DNS - Common Output Format April 2024
3.4.2. bailiwick 3.4.2. bailiwick
The bailiwick is the best estimate of the apex of the zone where this The bailiwick is the best estimate of the apex of the zone where this
@ -365,6 +386,14 @@ Internet-Draft Passive DNS - Common Output Format April 2024
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.
Dulaunoy, et al. Expires 28 February 2025 [Page 7]
Internet-Draft Passive DNS - Common Output Format August 2024
3.5.3. zone_time_last 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,
@ -385,15 +414,6 @@ Internet-Draft Passive DNS - Common Output Format April 2024
that the resolution is in milliseconds since 1st of January 1970 that the resolution is in milliseconds since 1st of January 1970
(UTC). (UTC).
Dulaunoy, et al. Expires 29 October 2024 [Page 7]
Internet-Draft Passive DNS - Common Output Format April 2024
3.5.6. time_last_ms 3.5.6. time_last_ms
Same meaning as the field "time_last", with the only difference, that Same meaning as the field "time_last", with the only difference, that
@ -408,7 +428,7 @@ Internet-Draft Passive DNS - Common Output Format April 2024
3.7. Additional notes 3.7. Additional notes
An implementer of a passive DNS Server MAY chose to either return An implementer of a passive DNS server MAY chose to either return
time_first and time_last OR return zone_time_first and time_first and time_last OR return zone_time_first and
zone_time_last. In pseudocode: (time_first AND time_last) OR zone_time_last. In pseudocode: (time_first AND time_last) OR
(zone_time_first AND zone_time_last). In this case, (zone_time_first AND zone_time_last). In this case,
@ -419,10 +439,17 @@ Internet-Draft Passive DNS - Common Output Format April 2024
3.8. Suggested MIME Types 3.8. Suggested MIME Types
An implementer of a passive DNS Server SHOULD serve a document in An implementer of a passive DNS server SHOULD serve a document in
this Common Output Format with a MIME header of "application/ this Common Output Format with a MIME header of "application/
x-ndjson". x-ndjson".
Dulaunoy, et al. Expires 28 February 2025 [Page 8]
Internet-Draft Passive DNS - Common Output Format August 2024
4. Acknowledgements 4. Acknowledgements
Thanks to the Passive DNS developers who contributed to the document. Thanks to the Passive DNS developers who contributed to the document.
@ -433,134 +460,131 @@ Internet-Draft Passive DNS - Common Output Format April 2024
6. Privacy Considerations 6. Privacy Considerations
Passive DNS Servers capture DNS answers from multiple collection Passive DNS servers capture DNS answers from multiple collection
points ("sensors") which are located on the Internet-facing side of points ("sensors") which are located on the Internet-facing side of
DNS recursors ("post-recursor passive DNS"). In this process, they DNS recursors ("post-recursor passive DNS"). In this process, they
intentionally omit the source IP, source port, destination IP and intentionally omit the source IP, source port, destination IP and
destination port from the captured packets. Since the data is destination port from the captured packets. Since the data is
captured "post-recursor", the timing information (who queries what) captured "post-recursor", the timing information (who queries what)
is lost, since the recursor will cache the results. Furthermore, is lost, since the recursor will cache the results. Furthermore,
since multiple sensors feed into a passive DNS server, the resulting since multiple sensors feed into a passive DNS system, the resulting
data gets mixed together, reducing the likelihood that Passive DNS data gets mixed together, reducing the likelihood that Passive DNS
systems are able to find out much about the actual person querying
the DNS records. In this sense, passive DNS systems are similar to
Dulaunoy, et al. Expires 29 October 2024 [Page 8]
Internet-Draft Passive DNS - Common Output Format April 2024
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 keeping an archive of all previous phone books - if public DNS
records can be compared to phone numbers - as they often are. records can be compared to phone numbers - as they often are.
Nevertheless, the authors strongly encourage Passive DNS implementors Nevertheless, the authors strongly encourage Passive DNS implementors
to take special care of privacy issues. bortzmeyer-dnsop-dns-privacy to take special care of privacy issues. Finally, the overall
is an excellent starting point for this. Finally, the overall
recommendations in RFC6973 [RFC6973] should be taken into recommendations in RFC6973 [RFC6973] should be taken into
consideration when designing any application which uses Passive DNS consideration when designing any application which uses Passive DNS
data. data.
Passive DNS attempts to collect information necessary for security
(such as malware protection) in as privacy protecting a manner as
possible, and is intended to be used instead of more invasive
methods. It does this by only collecting DNS cache-fill answers, and
not any information associated with who caused the name to be
resolved, nor why the name was resolved. Nevertheless, it is
possible that this may still lead to privacy concerns - for example,
if Passive DNS records show that a recursive resolver resolved the
name the-mary-and-john-smith-family.example.com, it may be possible
to infer that the Smith family is using that resolver. Operators of
Passive DNS servers should be aware of this and take appropriate
steps to limit access to the data.
Passive DNS operators are encouraged to read and understand RFC7258
[RFC7258]
In the scope of the General Data Protection Regulation (GDPR - In the scope of the General Data Protection Regulation (GDPR -
Directive 95/46/EC), operators of Passive DNS Server needs to ensure Directive 95/46/EC), operators of Passive DNS server needs to ensure
the legal ground and lawfulness of its operation. the legal ground and lawfulness of its operation.
Dulaunoy, et al. Expires 28 February 2025 [Page 9]
Internet-Draft Passive DNS - Common Output Format August 2024
7. Security Considerations 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 should be restricted. When a user is
querying multiple Passive DNS and aggregating the data, the querying multiple Passive DNS and aggregating the data, the
sensitivity of the data must be considered. sensitivity of the data must be considered.
8. References 8. Normative References
8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC1035] Mockapetris, P., "Domain names - implementation and
Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1997, <https://www.rfc-editor.org/info/rfc2234>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>.
Dulaunoy, et al. Expires 29 October 2024 [Page 9]
Internet-Draft Passive DNS - Common Output Format April 2024
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>. <https://www.rfc-editor.org/info/rfc3912>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006, DOI 10.17487/RFC4627, July 2006,
<https://www.rfc-editor.org/info/rfc4627>. <https://www.rfc-editor.org/info/rfc4627>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, Application Protocols", BCP 178, RFC 6648,
DOI 10.17487/RFC6648, June 2012, DOI 10.17487/RFC6648, June 2012,
<https://www.rfc-editor.org/info/rfc6648>. <https://www.rfc-editor.org/info/rfc6648>.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
November 1997, <https://www.rfc-editor.org/info/rfc2234>.
Dulaunoy, et al. Expires 28 February 2025 [Page 10]
Internet-Draft Passive DNS - Common Output Format August 2024
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
8.2. References [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[BAILIWICK] [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Edmonds, R., "Passive DNS Hardening", 2010, Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
<https://archive.farsightsecurity.com/Passive_DNS/ 2014, <https://www.rfc-editor.org/info/rfc7258>.
passive_dns_hardening_handout.pdf>.
[CACHEPOISONING] [WEIMERPDNS]
Kaminsky, D., "Black ops 2008: It's the end of the cache Weimer, F., "Passive DNS Replication", 2005,
as we know it.", 2008, <http://www.enyo.de/fw/software/dnslogger/
<http://kurser.lobner.dk/dDist/DMK_BO2K8.pdf>. first2005-paper.pdf>.
[DNSDB] Security, F., "DNSDB API", 2013,
<https://api.dnsdb.info/>.
[DNSDBQ] Vixie, P., "DNSDB API Client, C Version", 2018,
<https://github.com/dnsdb/dnsdbq>.
Dulaunoy, et al. Expires 29 October 2024 [Page 10]
Internet-Draft Passive DNS - Common Output Format April 2024
[PDNSCOF] Dulaunoy, D. P. A., "Passive DNS server interface using
the common output format", 2019,
<https://github.com/D4-project/analyzer-d4-passivedns/>.
[github_issue_17] [github_issue_17]
et.al, P. V. W. A. K., "Discussion on the existing et.al, P. V. W. A. K., "Discussion on the existing
@ -568,6 +592,39 @@ Internet-Draft Passive DNS - Common Output Format April 2024
OR time_{first,last}", 2020, OR time_{first,last}", 2020,
<https://github.com/adulau/pdns-qof/issues/17>. <https://github.com/adulau/pdns-qof/issues/17>.
9. Informative References
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016,
<https://www.rfc-editor.org/info/rfc7871>.
[BAILIWICK]
Edmonds, R., "Passive DNS Hardening", 2010,
<https://archive.farsightsecurity.com/Passive_DNS/
passive_dns_hardening_handout.pdf>.
[PDNSCLIENT]
Lee, C., "Queries 5 major Passive DNS databases: BFK,
CERTEE, DNSParse, ISC, and VirusTotal.", 2013,
<https://github.com/chrislee35/passivedns-client>.
Dulaunoy, et al. Expires 28 February 2025 [Page 11]
Internet-Draft Passive DNS - Common Output Format August 2024
[REST] Fielding, R. T., "Representational State Transfer (REST)",
2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/
rest_arch_style.htm>.
[DNSDB] Security, F., "DNSDB API", 2013,
<https://api.dnsdb.info/>.
[PDNSCERTAT] [PDNSCERTAT]
CERT.at, "pDNS presentation at 4th Centr R&D workshop CERT.at, "pDNS presentation at 4th Centr R&D workshop
Frankfurt Jun 5th 2012", 2012, Frankfurt Jun 5th 2012", 2012,
@ -578,25 +635,8 @@ Internet-Draft Passive DNS - Common Output Format April 2024
Luxembourg, C. -. I. R. C., "CIRCL Passive DNS", 2012, Luxembourg, C. -. I. R. C., "CIRCL Passive DNS", 2012,
<https://www.circl.lu/services/passive-dns/>. <https://www.circl.lu/services/passive-dns/>.
[PDNSCLIENT] [DNSDBQ] Vixie, P., "DNSDB API Client, C Version", 2018,
Lee, C., "Queries 5 major Passive DNS databases: BFK, <https://github.com/dnsdb/dnsdbq>.
CERTEE, DNSParse, ISC, and VirusTotal.", 2013,
<https://github.com/chrislee35/passivedns-client>.
[PDNSCOF] Dulaunoy, D. P. A., "Passive DNS server interface using
the common output format", 2019,
<https://github.com/D4-project/analyzer-d4-passivedns/>.
[REST] Fielding, R. T., "Representational State Transfer (REST)",
2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/
rest_arch_style.htm>.
[WEIMERPDNS]
Weimer, F., "Passive DNS Replication", 2005,
<http://www.enyo.de/fw/software/dnslogger/
first2005-paper.pdf>.
8.3. Informative References
Appendix A. Examples Appendix A. Examples
@ -606,18 +646,6 @@ Appendix A. Examples
If you query a passive DNS for the rrname www.ietf.org, the passive If you query a passive DNS for the rrname www.ietf.org, the passive
dns common output format can be: dns common output format can be:
Dulaunoy, et al. Expires 29 October 2024 [Page 11]
Internet-Draft Passive DNS - Common Output Format April 2024
{"count": 102, "time_first": 1298412391, "rrtype": "AAAA", {"count": 102, "time_first": 1298412391, "rrtype": "AAAA",
"rrname": "www.ietf.org", "rdata": "2001:1890:1112:1::20", "rrname": "www.ietf.org", "rdata": "2001:1890:1112:1::20",
"time_last": 1302506851} "time_last": 1302506851}
@ -625,9 +653,27 @@ Internet-Draft Passive DNS - Common Output Format April 2024
"rrname": "www.ietf.org", "rdata": "4.31.198.44", "rrname": "www.ietf.org", "rdata": "4.31.198.44",
"time_last": 1389022219} "time_last": 1389022219}
Figure 2
If you query a passive DNS for the rrname ietf.org, the passive dns If you query a passive DNS for the rrname ietf.org, the passive dns
common output format can be: common output format can be:
Dulaunoy, et al. Expires 28 February 2025 [Page 12]
Internet-Draft Passive DNS - Common Output Format August 2024
{"count": 109877, "time_first": 1298398002, "rrtype": "NS", {"count": 109877, "time_first": 1298398002, "rrtype": "NS",
"rrname": "ietf.org", "rdata": "ns1.yyz1.afilias-nst.info", "rrname": "ietf.org", "rdata": "ns1.yyz1.afilias-nst.info",
"time_last": 1389095375} "time_last": 1389095375}
@ -638,6 +684,8 @@ Internet-Draft Passive DNS - Common Output Format April 2024
"rrname": "ietf.org", "rdata": "2001:1890:123a::1:1e", "rrname": "ietf.org", "rdata": "2001:1890:123a::1:1e",
"time_last": 1330209752} "time_last": 1330209752}
Figure 3
Please note that the examples imply that a single query returns a Please note that the examples imply that a single query returns a
single set of JSON objects. For example, two queries were made; one 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 query returned a set of two JSON objects and the other query returned
@ -655,7 +703,7 @@ Authors' Addresses
Alexandre Dulaunoy Alexandre Dulaunoy
CIRCL CIRCL
122, rue Adolphe Fischer 122, rue Adolphe Fischer
L-1521 Luxembourg L-L-1521 Luxembourg
Luxembourg Luxembourg
Phone: (+352) 247 88444 Phone: (+352) 247 88444
Email: alexandre.dulaunoy@circl.lu Email: alexandre.dulaunoy@circl.lu
@ -668,18 +716,20 @@ Authors' Addresses
Email: aaron@lo-res.org Email: aaron@lo-res.org
Dulaunoy, et al. Expires 29 October 2024 [Page 12]
Internet-Draft Passive DNS - Common Output Format April 2024
Paul Vixie Paul Vixie
Farsight Security, Inc. Farsight Security, Inc.
11400 La Honda Road 11400 La Honda Road
Woodside, California 94062 Woodside, California 94062
United States of America United States of America
Email: paul@redbarn.org Email: paul@redbarn.org
Dulaunoy, et al. Expires 28 February 2025 [Page 13]
Internet-Draft Passive DNS - Common Output Format August 2024
URI: https://www.farsightsecurity.com/ URI: https://www.farsightsecurity.com/
@ -725,4 +775,10 @@ Internet-Draft Passive DNS - Common Output Format April 2024
Dulaunoy, et al. Expires 29 October 2024 [Page 13]
Dulaunoy, et al. Expires 28 February 2025 [Page 14]