RFC 8618
Compacted-DNS (C-DNS): A Format for DNS Packet Capture
Pages: 79
Proposed Standard
Proposed Standard
Part 3 of 4 – Pages 39 to 57
8. Versioning
The C-DNS File Preamble includes a file Format Version; a major and minor version number are required fields. This document defines version 1.0 of the C-DNS specification. This section describes the intended use of these version numbers in future specifications. It is noted that version 1.0 includes many optional fields; therefore, consumers of version 1.0 should be inherently robust to parsing files with variable data content. Within a major version, a new minor version MUST be a strict superset of the previous minor version, with no semantic changes to existing fields. New keys MAY be added to existing maps, and new maps MAY be added. A consumer capable of reading a particular major.minor version MUST also be capable of reading all previous minor versions of the same major version. It SHOULD also be capable of parsing all subsequent minor versions, ignoring any keys or maps that it does not recognize.
A new major version indicates changes to the format that are not backwards compatible with previous major versions. A consumer capable of only reading a particular major version (greater than 1) is neither required nor expected to be capable of reading a previous major version.9. C-DNS to PCAP
It is usually possible to reconstruct PCAP files from the C-DNS format in a lossy fashion. Some of the issues with reconstructing both the DNS payload and the full packet stream are outlined here. The reconstruction of well-formed DNS messages depends on two factors: 1. Whether or not a particular subset of the optional fields were captured in the C-DNS file, specifically the data fields necessary to reconstruct a valid IP header and DNS payload for both Query and Response (see Appendix D.1). Clearly, if not all these data fields were captured, the reconstruction is likely to be imperfect even if reasonable defaults are provided for the reconstruction. 2. Whether or not at least one field was captured that unambiguously identifies the Query/Response data item as containing just a Query, just a Response, or a Query/Response pair. Obviously, the qr-sig-flags defined in Section 7.3.2.3.2 is such a field; however, this field is optional. For more details, see Appendix D.2. It is noted again that simply having hints that indicate that certain data fields were not omitted does not guarantee that those data fields were actually captured. Therefore, the ability to reconstruct PCAP data (in the absence of defaults) can in principle vary for each record captured in a C-DNS file, and between Blocks that have differing hints. Even if all sections of the Response were captured, one cannot reconstruct the DNS Response payload exactly, due to the fact that some DNS names in the message on the wire may have been compressed. Section 9.1 discusses this in more detail.
Some transport information is not captured in the C-DNS format. For
example, the following aspects of the original packet stream cannot
be reconstructed from the C-DNS format:
o IP fragmentation
o TCP stream information:
* Multiple DNS messages may have been sent in a single TCP
segment
* A DNS payload may have been split across multiple TCP segments
* Multiple DNS messages may have been sent on a single TCP
session
o TLS session information:
* TLS version or cipher suites
* TLS-related features such as TCP Fast Open (TFO) [RFC7413] or
TLS session resumption [RFC5077]
o DNS-over-HTTPS [RFC8484] message details:
* Whether the message used POST or GET
* HTTPS Headers
o Malformed DNS messages if the wire format is not recorded
o Any non-DNS messages that were in the original packet stream,
e.g., ICMP
Simple assumptions can be made on the reconstruction: fragmented and
DNS-over-TCP messages can be reconstructed into single packets, and a
single TCP session can be constructed for each TCP packet.
Additionally, if malformed messages and non-DNS packets are captured
separately, they can be merged with packet captures reconstructed
from C-DNS to produce a more complete packet stream.
9.1. Name Compression
All the names stored in the C-DNS format are full domain names; no name compression (per [RFC1035]) is used on the individual names within the format. Therefore, when reconstructing a packet, name compression must be used in order to reproduce the on-the-wire representation of the packet. Name compression per [RFC1035] works by substituting trailing sections of a name with a reference back to the occurrence of those sections earlier in the message. Not all name server software uses the same algorithm when compressing domain names within the Responses. Some attempt maximum recompression at the expense of runtime resources, others use heuristics to balance compression and speed, and others use different rules for what is a valid compression target. This means that Responses to the same Query from different name server software that match in terms of DNS payload content (header, counts, RRs with name compression removed) do not necessarily match byte for byte on the wire. Therefore, it is not possible to ensure that the DNS Response payload is reconstructed byte for byte from C-DNS data. However, it can at least, in principle, be reconstructed to have the correct payload length (since the original Response length is captured) if there is enough knowledge of the commonly implemented name compression algorithms. For example, a simplistic approach would be to try each algorithm in turn to see if it reproduces the original length, stopping at the first match. This would not guarantee that the correct algorithm has been used, as it is possible to match the length whilst still not matching the on-the-wire bytes; however, without further information added to the C-DNS data, this is the best that can be achieved. Appendix B presents an example of two different compression algorithms used by well-known name server software.10. Data Collection
This section describes a non-normative proposed algorithm for the processing of a captured stream of DNS Queries and Responses and production of a stream of Q/R data items, matching Queries and Responses where possible.
For the purposes of this discussion, it is assumed that the input has
been preprocessed such that:
1. All IP fragmentation reassembly, TCP stream reassembly, and
so on, have already been performed.
2. Each message is associated with transport metadata required to
generate the Primary ID (see Section 10.2.1).
3. Each message has a well-formed DNS Header of 12 bytes, and (if
present) the first Question in the Question section can be parsed
to generate the Secondary ID (see below). As noted earlier, this
requirement can result in a malformed Query being removed in the
preprocessing stage, but the correctly formed Response with RCODE
of FORMERR being present.
DNS messages are processed in the order they are delivered to the
implementation.
It should be noted that packet capture libraries do not necessarily
provide packets in strict chronological order. This can, for
example, arise on multi-core platforms where packets arriving at a
network device are processed by different cores. On systems where
this behavior has been observed, the timestamps associated with each
packet are consistent; Queries always have a timestamp prior to the
Response timestamp. However, the order in which these packets appear
in the packet capture stream is not necessarily strictly
chronological; a Response can appear in the capture stream before the
Query that provoked the Response. For this discussion, this
non-chronological delivery is termed "skew".
In the presence of skew, Response packets can arrive for matching
before the corresponding Query. To avoid generating false instances
of Responses without a matching Query, and Queries without a matching
Response, the matching algorithm must take the possibility of skew
into account.
10.1. Matching Algorithm
A schematic representation of the algorithm for matching Q/R data
items is shown in Figure 3. It takes individual DNS Query or
Response messages as input, and it outputs matched Q/R data items.
The numbers in the figure identify matching operations listed in
Table 1. Specific details of the algorithm -- for example, queues,
timers, and identifiers -- are given in the following sections.
.----------------------.
| Process next message |<------------------+
`----------------------' |
| |
+------------------------------+ |
| Generate message identifiers | |
+------------------------------+ |
| |
Response | Query |
+--------------< >---------------+ |
| | |
+--------------------+ +--------------------+ |
| Find earliest QR | | Create QR item (2) | |
| item in OFIFO (1) | +--------------------+ |
+--------------------+ | |
| +---------------+ |
Match | No match | Append new QR | |
+--------< >------+ | item to OFIFO | |
| | +---------------+ |
+-----------+ +--------+ | |
| Update QR | | Add to | +-------------------+ |
| item (3) | | RFIFO | | Find earliest QR | |
+-----------+ +--------+ | item in RFIFO (1) | |
| | +-------------------+ |
+-----------------+ | |
| | |
| +----------------+ Match | No match |
| | Remove R |-------< >-----+ |
| | from RFIFO (3) | | |
| +----------------+ | |
| | | |
+--------------+-----------------------+ |
| |
+----------------------------------------------+ |
| Update all timed-out (QT) OFIFO QR items (4) | |
+----------------------------------------------+ |
| |
+--------------------------------+ |
| Remove all timed-out (ST) R | |
| from RFIFO, create QR item (5) | |
+--------------------------------+ |
____________________|_______________________ |
/ / |
/ Remove all consecutive done entries from /-------+
/ front of OFIFO for further processing /
/____________________________________________/
OFIFO = output FIFO containing Q/R data items (Section 10.6)
RFIFO = Response FIFO containing unmatched Response items
(Section 10.6)
QT = Query Timeout (Section 10.3)
ST = Skew Timeout (Section 10.3)
Figure 3: Query/Response Matching Algorithm
+-----------+-------------------------------------------+
| Reference | Operation |
+-----------+-------------------------------------------+
| (1) | Find earliest QR item in FIFO where: |
| | * QR.done = false |
| | * QR.Q.PrimaryID == R.PrimaryID |
| | and, if both QR.Q and R have SecondaryID: |
| | * QR.Q.SecondaryID == R.SecondaryID |
| | |
| (2) | Set: |
| | QR.Q := Q |
| | QR.R := nil |
| | QR.done := false |
| | |
| (3) | Set: |
| | QR.R := R |
| | QR.done := true |
| | |
| (4) | Set: |
| | QR.done := true |
| | |
| (5) | Set: |
| | QR.Q := nil |
| | QR.R := R |
| | QR.done := true |
+-----------+-------------------------------------------+
Table 1: Operations Used in the Matching Algorithm
10.2. Message Identifiers
10.2.1. Primary ID (Required)
A Primary ID is constructed for each message. It is composed of the
following data:
1. Source IP Address
2. Destination IP Address
3. Source Port 4. Destination Port 5. Transport 6. DNS Message ID10.2.2. Secondary ID (Optional)
If present, the first Question in the Question section is used as a Secondary ID for each message. Note that there may be well-formed DNS Queries that have a QDCOUNT of 0, and some Responses may have a QDCOUNT of 0 (for example, Responses with RCODE=FORMERR or NOTIMP). In this case, the Secondary ID is not used in matching.10.3. Algorithm Parameters
1. Query Timeout (QT). A Query arrives with timestamp t1. If no Response matching that Query has arrived before other input arrives timestamped later than (t1 + QT), a Q/R data item containing only a Query is recorded. The QT value is typically on the order of 5 seconds. 2. Skew Timeout (ST). A Response arrives with timestamp t2. If a Response has not been matched by a Query before input arrives timestamped later than (t2 + ST), a Q/R data item containing only a Response is recorded. The ST value is typically a few microseconds.10.4. Algorithm Requirements
The algorithm is designed to handle the following input data: 1. Multiple Queries with the same Primary ID (but different Secondary ID) arriving before any Responses for these Queries are seen. 2. Multiple Queries with the same Primary and Secondary ID arriving before any Responses for these Queries are seen. 3. Queries for which no later Response can be found within the specified timeout. 4. Responses for which no previous Query can be found within the specified timeout.
10.5. Algorithm Limitations
For cases 1 and 2 listed in the above requirements, it is not possible to unambiguously match Queries with Responses. This algorithm chooses to match to the earliest Query with the correct Primary and Secondary ID.10.6. Workspace
The algorithm employs two FIFO queues: o OFIFO: an output FIFO containing Q/R data items in chronological order. o RFIFO: a FIFO holding Responses without a matching Query in order of arrival.10.7. Output
The output is a list of Q/R data items. Both the Query and Response elements are optional in these items; therefore, Q/R data items have one of three types of content: 1. A matched pair of Query and Response messages 2. A Query message with no Response 3. A Response message with no Query The timestamp of a list item is that of the Query for cases 1 and 2 and that of the Response for case 3.10.8. Post-Processing
When ending a capture, all items in the RFIFO are timed out immediately, generating Response only entries to the OFIFO. These and all other remaining entries in the OFIFO should be treated as timed-out Queries.11. Implementation Guidance
Whilst this document makes no specific recommendations with respect to "Canonical CBOR" (see Section 3.9 of [RFC7049]), the following guidance may be of use to implementers. Adherence to the first two rules given in Section 3.9 of [RFC7049] will minimize file sizes.
Adherence to the last two rules given in Section 3.9 of [RFC7049] for all maps and arrays would unacceptably constrain implementations -- for example, in the use case of real-time data collection in constrained environments where outputting Block Tables after Q/R data items and allowing indefinite-length maps and arrays could reduce memory requirements. It is recommended that implementations that have fundamental restrictions on what data fields they can collect SHOULD always store hints with the bits unset for those fields, i.e., they unambiguously indicate that those data fields will be omitted from captured C-DNS.11.1. Optional Data
When decoding C-DNS data, some of the items required for a particular function that the consumer wishes to perform may be missing. Consumers should consider providing configurable default values to be used in place of the missing values in their output.11.2. Trailing Bytes
A DNS Query message in a UDP or TCP payload can be followed by some additional (spurious) bytes, which are not stored in C-DNS. When DNS traffic is sent over TCP, each message is prefixed with a two-byte length field, which gives the message length, excluding the two-byte length field. In this context, trailing bytes can occur in two circumstances, with different results: 1. The number of bytes consumed by fully parsing the message is less than the number of bytes given in the length field (i.e., the length field is incorrect and too large). In this case, the surplus bytes are considered trailing bytes in a manner analogous to UDP and recorded as such. If only this case occurs, it is possible to process a packet containing multiple DNS messages where one or more have trailing bytes. 2. There are surplus bytes between the end of a well-formed message and the start of the length field for the next message. In this case, the first of the surplus bytes will be processed as the first byte of the next length field, and parsing will proceed from there, almost certainly leading to the next and any subsequent messages in the packet being considered malformed. This will not generate a trailing-bytes record for the processed well-formed message.
11.3. Limiting Collection of RDATA
Implementations should consider providing a configurable maximum RDATA size for captures -- for example, to avoid memory issues when confronted with large zone transfer records.11.4. Timestamps
The preamble to each block includes a timestamp of the earliest record in the Block. As described in Section 7.3.2.1, the timestamp is an array of two unsigned integers. The first is a POSIX "time_t" [posix-time]. Consumers of C-DNS should be aware of this, as it excludes leap seconds and therefore may cause minor anomalies in the data, e.g., when calculating Query throughput.12. IANA Considerations
IANA has created a registry "C-DNS DNS Capture Format" containing the subregistries defined in Sections 12.1 to 12.4 inclusive. In all cases, new entries may be added to the subregistries by Expert Review as defined in [RFC8126]. Experts are expected to exercise their own expert judgment and should consider the following general guidelines in addition to any provided guidelines that are particular to a subregistry. o There should be a real and compelling use for any new value. o Values assigned should be carefully chosen to minimize storage requirements for common cases.12.1. Transport Types
IANA has created a registry "C-DNS Transports" of C-DNS transport type identifiers. The primary purpose of this registry is to provide unique identifiers for all transports used for DNS Queries. The following note is included in this registry: "In version 1.0 of C-DNS [RFC8618], there is a field to identify the type of DNS transport. This field is 4 bits in size."
The initial contents of the registry are as follows. See Sections 7.3.2.3.2, 7.3.2.3.5, and 7.3.2.5 of this document: +------------+------------------------+-----------+ | Identifier | Name | Reference | +------------+------------------------+-----------+ | 0 | UDP | RFC 8618 | | 1 | TCP | RFC 8618 | | 2 | TLS | RFC 8618 | | 3 | DTLS | RFC 8618 | | 4 | HTTPS | RFC 8618 | | 5-14 | Unassigned | | | 15 | Non-standard transport | RFC 8618 | +------------+------------------------+-----------+ Expert reviewers should take the following point into consideration: Is the requested DNS transport described by a Standards Track RFC?12.2. Data Storage Flags
IANA has created a registry "C-DNS Storage Flags" of C-DNS data storage flags. The primary purpose of this registry is to provide indicators giving hints on processing of the data stored. The following note is included in this registry: "In version 1.0 of C-DNS [RFC8618], there is a field describing attributes of the data recorded. The field is a CBOR [RFC7049] unsigned integer holding bit flags." The initial contents of the registry are as follows. See Section 7.3.1.1.1 of this document: +------+------------------+-----------------------------+-----------+ | Bit | Name | Description | Reference | +------+------------------+-----------------------------+-----------+ | 0 | anonymized-data | The data has been | RFC 8618 | | | | anonymized. | | | | | | | | 1 | sampled-data | The data is sampled data. | RFC 8618 | | | | | | | 2 | normalized-names | Names in the data have been | RFC 8618 | | | | normalized. | | | | | | | | 3-63 | Unassigned | | | +------+------------------+-----------------------------+-----------+
12.3. Response-Processing Flags
IANA has created a registry "C-DNS Response Flags" of C-DNS response- processing flags. The primary purpose of this registry is to provide indicators giving hints on the generation of a particular Response. The following note is included in this registry: "In version 1.0 of C-DNS [RFC8618], there is a field describing attributes of the Responses recorded. The field is a CBOR [RFC7049] unsigned integer holding bit flags." The initial contents of the registry are as follows. See Section 7.3.2.4.1 of this document: +------+------------+-------------------------------+-----------+ | Bit | Name | Description | Reference | +------+------------+-------------------------------+-----------+ | 0 | from-cache | The Response came from cache. | RFC 8618 | | 1-63 | Unassigned | | | +------+------------+-------------------------------+-----------+12.4. AddressEvent Types
IANA has created a registry "C-DNS Address Event Types" of C-DNS AddressEvent types. The primary purpose of this registry is to provide unique identifiers of different types of C-DNS address events and so specify the contents of the optional companion field "ae-code" for each type. The following note is included in this registry: "In version 1.0 of C-DNS [RFC8618], there is a field identifying types of the events related to client addresses. This field is a CBOR [RFC7049] unsigned integer. There is a related optional field "ae-code", which, if present, holds an additional CBOR unsigned integer giving additional information specific to the event type."
The initial contents of the registry are as follows. See Section 7.3.2.5 of this document: +------------------------+---------------+--------------+-----------+ | Identifier | Event Type | ae-code | Reference | | | | Contents | | +------------------------+---------------+--------------+-----------+ | 0 | TCP reset | None | RFC 8618 | | | | | | | 1 | ICMP time | ICMP code | RFC 8618 | | | exceeded | [icmpcodes] | | | | | | | | 2 | ICMP | ICMP code | RFC 8618 | | | destination | [icmpcodes] | | | | unreachable | | | | | | | | | 3 | ICMPv6 time | ICMPv6 code | RFC 8618 | | | exceeded | [icmp6codes] | | | | | | | | 4 | ICMPv6 | ICMPv6 code | RFC 8618 | | | destination | [icmp6codes] | | | | unreachable | | | | | | | | | 5 | ICMPv6 packet | ICMPv6 code | RFC 8618 | | | too big | [icmp6codes] | | | | | | | | 6-18446744073709551615 | Unassigned | | | +------------------------+---------------+--------------+-----------+ Expert reviewers should take the following point into consideration: "ae-code" contents must be defined for a type or, if not appropriate, specified as "None". A specification of "None" requires less storage and is therefore preferred.13. Security Considerations
Any control interface MUST perform authentication and encryption. Any data upload MUST be authenticated and encrypted.14. Privacy Considerations
Storage of DNS traffic by operators in PCAP and other formats is a long-standing and widespread practice. Section 2.5 of [DNS-Priv-Cons] provides an analysis of the risks to Internet users regarding the storage of DNS traffic data in servers (recursive resolvers, authoritative servers, and rogue servers).
Section 5.2 of [DNS-Priv-Svc] describes mitigations for those risks for data stored on recursive resolvers (but that could by extension apply to authoritative servers). These include data-handling practices and methods for data minimization, IP address pseudonymization, and anonymization. Appendix C of [DNS-Priv-Svc] presents an analysis of seven published anonymization processes. In addition, the ICANN Root Server System Advisory Committee (RSSAC) have recently published [RSSAC04] ("Recommendations on Anonymization Processes for Source IP Addresses Submitted for Future Analysis"). The above analyses consider full data capture (e.g., using PCAP) as a baseline for privacy considerations; therefore, this format specification introduces no new user privacy issues beyond those of full data capture (which are quite severe). It does provide mechanisms to selectively record only certain fields at the time of data capture, to improve user privacy and to explicitly indicate that data is sampled, anonymized, or both. It also provides flags to indicate if data normalization has been performed; data normalization increases user privacy by reducing the potential for fingerprinting individuals. However, a trade-off is the potential reduction of the capacity to identify attack traffic via Query name signatures. Operators should carefully consider their operational requirements and privacy policies and SHOULD capture at the source the minimum user data required to meet their needs.15. References
15.1. Normative References
[pcap-filter] tcpdump.org, "Manpage of PCAP-FILTER", November 2017, <https://www.tcpdump.org/manpages/pcap-filter.7.html>. [pcap-options] tcpdump.org, "Manpage of PCAP", July 2018, <https://www.tcpdump.org/manpages/pcap.3pcap.html>. [posix-time] The Open Group, "IEEE Standard for Information Technology--Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7", IEEE Standard 1003.1-2017, Section 4.16, DOI 10.1109/IEEESTD.2018.8277153. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[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 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [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>. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>. [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>. [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>. [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>. [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.15.2. Informative References
[Avro] The Apache Software Foundation, "Apache Avro(TM)", 2019, <https://avro.apache.org/>. [ditl] DNS-OARC, "DITL", 2018, <https://www.dns-oarc.net/oarc/data/ditl>. [DNS-Priv-Cons] Bortzmeyer, S. and S. Dickinson, "DNS Privacy Considerations", Work in Progress, draft-ietf-dprive-rfc7626-bis-00, July 2019. [DNS-Priv-Svc] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and A. Mankin, "Recommendations for DNS Privacy Service Operators", Work in Progress, draft-ietf-dprive-bcp-op-03, July 2019. [dnscap] DNS-OARC, "DNSCAP", 2018, <https://www.dns-oarc.net/tools/dnscap>. [dnstap] "dnstap", 2016, <https://dnstap.info/>. [dnstap-schema] "dnstap schema", commit d860ec1, November 2016, <https://github.com/dnstap/dnstap.pb/blob/master/ dnstap.proto>. [dnsxml] Daley, J., Ed., Morris, S., and J. Dickinson, "dnsxml - A standard XML representation of DNS data", Work in Progress, draft-daley-dnsxml-00, July 2013. [dsc] Wessels, D. and J. Lundstrom, "DSC", 2016, <https://www.dns-oarc.net/tools/dsc>. [gzip] "gzip", <https://www.gzip.org/>.
[icmp6codes] IANA, "ICMPv6 "Code" Fields", <https://www.iana.org/assignments/icmpv6-parameters/>. [icmpcodes] IANA, "Code Fields", <https://www.iana.org/assignments/icmp-parameters/>. [IEEE802.1Q] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks", IEEE Standard 802.1Q. [Knot] "Knot DNS", <https://www.knot-dns.cz/>. [lz4] "LZ4", <https://lz4.github.io/lz4/>. [mmark] Gieben, M., "mmark", commit de69698, May 2019, <https://github.com/mmarkdown/mmark>. [NSD] NLnet Labs, "NSD", 2019, <https://www.nlnetlabs.nl/projects/nsd/about/>. [opcodes] IANA, "DNS OpCodes", <https://www.iana.org/assignments/dns-parameters/>. [packetq] .SE - The Internet Infrastructure Foundation, "PacketQ", commit c9b2e89, February 2019, <https://github.com/DNS-OARC/PacketQ>. [pcap] "PCAP", 2019, <https://www.tcpdump.org/>. [pcapng] "pcapng: PCAP next generation file format specification", commit 3c35b6a, March 2019, <https://github.com/pcapng/pcapng>. [Protocol-Buffers] Google LLC, "Protocol Buffers", <https://developers.google.com/protocol-buffers/>. [rcodes] IANA, "DNS RCODEs", <https://www.iana.org/assignments/dns-parameters/>. [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>. [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>. [RFC8427] Hoffman, P., "Representing DNS Messages in JSON", RFC 8427, DOI 10.17487/RFC8427, July 2018, <https://www.rfc-editor.org/info/rfc8427>. [rrclasses] IANA, "DNS CLASSes", <https://www.iana.org/assignments/dns-parameters/>. [rrtypes] IANA, "Resource Record (RR) TYPEs", <https://www.iana.org/assignments/dns-parameters/>. [RSSAC04] ICANN, "Recommendations on Anonymization Processes for Source IP Addresses Submitted for Future Analysis", August 2018, <https://www.icann.org/en/system/files/files/ rssac-040-07aug18-en.pdf>. [snappy] "snappy", <https://google.github.io/snappy/>. [snzip] "Snzip, a compression/decompression tool based on snappy", commit 809c6f2, October 2018, <https://github.com/kubo/snzip>. [xz] "XZ Utils", <https://tukaani.org/xz/>. [zstd] "Zstandard - Real-time data compression algorithm", <https://facebook.github.io/zstd/>.
(next page on part 4)