draft-ietf-dnsop-dns-capture-format-01.txt   draft-ietf-dnsop-dns-capture-format-02.txt 
dnsop J. Dickinson dnsop J. Dickinson
Internet-Draft J. Hague Internet-Draft J. Hague
Intended status: Standards Track S. Dickinson Intended status: Standards Track S. Dickinson
Expires: August 25, 2017 Sinodun IT Expires: October 20, 2017 Sinodun IT
T. Manderson T. Manderson
J. Bond J. Bond
ICANN ICANN
February 21, 2017 April 18, 2017
C-DNS: A DNS Packet Capture Format C-DNS: A DNS Packet Capture Format
draft-ietf-dnsop-dns-capture-format-01 draft-ietf-dnsop-dns-capture-format-02
Abstract Abstract
This document describes a data representation for collections of DNS This document describes a data representation for collections of DNS
messages. The format is designed for efficient storage and messages. The format is designed for efficient storage and
transmission of large packet captures of DNS traffic; it attempts to transmission of large packet captures of DNS traffic; it attempts to
minimize the size of such packet capture files but retain the full minimize the size of such packet capture files but retain the full
DNS message contents along with the most useful transport metadata. DNS message contents along with the most useful transport metadata.
It is intended to assist with the development of DNS traffic It is intended to assist with the development of DNS traffic
monitoring applications. monitoring applications.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
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 25, 2017. This Internet-Draft will expire on October 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
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
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
10.3. Algorithm Parameters . . . . . . . . . . . . . . . . . . 28 10.3. Algorithm Parameters . . . . . . . . . . . . . . . . . . 28
10.4. Algorithm Requirements . . . . . . . . . . . . . . . . . 28 10.4. Algorithm Requirements . . . . . . . . . . . . . . . . . 28
10.5. Algorithm Limitations . . . . . . . . . . . . . . . . . 28 10.5. Algorithm Limitations . . . . . . . . . . . . . . . . . 28
10.6. Workspace . . . . . . . . . . . . . . . . . . . . . . . 28 10.6. Workspace . . . . . . . . . . . . . . . . . . . . . . . 28
10.7. Output . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.7. Output . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.8. Post Processing . . . . . . . . . . . . . . . . . . . . 29 10.8. Post Processing . . . . . . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
15.1. Normative References . . . . . . . . . . . . . . . . . . 30 15.1. Normative References . . . . . . . . . . . . . . . . . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . 31 15.2. Informative References . . . . . . . . . . . . . . . . . 31
15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. CDDL . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix B. DNS Name compression example . . . . . . . . . . . . 39 Appendix B. DNS Name compression example . . . . . . . . . . . . 39
B.1. NSD compression algorithm . . . . . . . . . . . . . . . . 40 B.1. NSD compression algorithm . . . . . . . . . . . . . . . . 40
B.2. Knot Authoritative compression algorithm . . . . . . . . 41 B.2. Knot Authoritative compression algorithm . . . . . . . . 41
B.3. Observed differences . . . . . . . . . . . . . . . . . . 41 B.3. Observed differences . . . . . . . . . . . . . . . . . . 41
Appendix C. Comparison of Binary Formats . . . . . . . . . . . . 41 Appendix C. Comparison of Binary Formats . . . . . . . . . . . . 41
C.1. Comparison with full PCAP files . . . . . . . . . . . . . 44 C.1. Comparison with full PCAP files . . . . . . . . . . . . . 44
C.2. Simple versus block coding . . . . . . . . . . . . . . . 45 C.2. Simple versus block coding . . . . . . . . . . . . . . . 45
skipping to change at page 4, line 44 skipping to change at page 4, line 44
o Some high level implementation considerations for applications o Some high level implementation considerations for applications
designed to produce C-DNS Section 10 designed to produce C-DNS Section 10
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"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 [RFC2119]. document are to be interpreted as described in [RFC2119].
"Packet" refers to individual IPv4 or IPv6 packets. Typically these
are UDP, but may be constructed from a TCP packet. "Message", unless
otherwise qualified, refers to a DNS payload extracted from a UDP or
TCP data stream.
The parts of DNS messages are named as they are in [RFC1035]. In The parts of DNS messages are named as they are in [RFC1035]. In
specific, the DNS message has five sections: Header, Question, specific, the DNS message has five sections: Header, Question,
Answer, Authority, and Additional. Answer, Authority, and Additional.
Pairs of DNS messages are called a Query and a Response. Pairs of DNS messages are called a Query and a Response.
3. Data Collection Use Cases 3. Data Collection Use Cases
In an ideal world, it would be optimal to collect full packet In an ideal world, it would be optimal to collect full packet
captures of all packets going in or out of a name server. However, captures of all packets going in or out of a name server. However,
skipping to change at page 7, line 36 skipping to change at page 7, line 39
responses can be synthesized if there is enough context. responses can be synthesized if there is enough context.
3. Multiple Q/R data items will be collected into blocks in the 3. Multiple Q/R data items will be collected into blocks in the
format. Common data in a block will be abstracted and referenced format. Common data in a block will be abstracted and referenced
from individual Q/R data items by indexing. The maximum number from individual Q/R data items by indexing. The maximum number
of Q/R data items in a block will be configurable. of Q/R data items in a block will be configurable.
* Rationale: This blocking and indexing provides a significant * Rationale: This blocking and indexing provides a significant
reduction in the volume of file data generated. Although this reduction in the volume of file data generated. Although this
introduces complexity, it provides compression of the data introduces complexity, it provides compression of the data
that makes use of knowledge of the DNS packet structure. that makes use of knowledge of the DNS message structure.
* It is anticipated that the files produced can be subject to * It is anticipated that the files produced can be subject to
further compression using general purpose compression tools. further compression using general purpose compression tools.
Measurements show that blocking significantly reduces the CPU Measurements show that blocking significantly reduces the CPU
required to perform such strong compression. See required to perform such strong compression. See
Appendix C.2. Appendix C.2.
* [TODO: Further discussion of commonality between DNS packets * [TODO: Further discussion of commonality between DNS messages
e.g. common query signatures, a finite set of valid responses e.g. common query signatures, a finite set of valid responses
from authoritatives] from authoritatives]
4. Metadata about other packets received can optionally be included 4. Metadata about other packets received can optionally be included
in each block. For example, counts of malformed DNS packets and in each block. For example, counts of malformed DNS packets and
non-DNS packets (e.g. ICMP, TCP resets) sent to the server may non-DNS packets (e.g. ICMP, TCP resets) sent to the server may
be of interest. be of interest.
5. The wire format content of malformed DNS packets can optionally 5. The wire format content of malformed DNS packets can optionally
be recorded. be recorded.
skipping to change at page 11, line 45 skipping to change at page 11, line 45
| | byte | Hint for downstream analysers; | | | byte | Hint for downstream analysers; |
| | strings | does not affect collection. | | | strings | does not affect collection. |
| | | | | | | |
| vlan-ids | Array of | Identifiers of VLANs selected for | | vlan-ids | Array of | Identifiers of VLANs selected for |
| | unsigned | collection. | | | unsigned | collection. |
| | | | | | | |
| filter | Text | 'tcpdump' [pcap] style filter for | | filter | Text | 'tcpdump' [pcap] style filter for |
| | string | input. | | | string | input. |
| | | | | | | |
| query-options | Unsigned | Bit flags indicating sections in | | query-options | Unsigned | Bit flags indicating sections in |
| | | Query packets to be collected. | | | | Query messages to be collected. |
| | | Bit 0. Collect second and | | | | Bit 0. Collect second and |
| | | subsequent question sections. | | | | subsequent Questions in the |
| | | Question section. |
| | | Bit 1. Collect Answer sections. | | | | Bit 1. Collect Answer sections. |
| | | Bit 2. Collect Authority | | | | Bit 2. Collect Authority |
| | | sections. | | | | sections. |
| | | Bit 3. Collection Additional | | | | Bit 3. Collection Additional |
| | | sections. | | | | sections. |
| | | | | | | |
| response-options | Unsigned | Bit flags indicating sections in | | response-options | Unsigned | Bit flags indicating sections in |
| | | Response packets to be collected. | | | | Response messages to be |
| | | collected. |
| | | Bit 0. Collect second and | | | | Bit 0. Collect second and |
| | | subsequent question sections. | | | | subsequent Questions in the |
| | | Question section. |
| | | Bit 1. Collect Answer sections. | | | | Bit 1. Collect Answer sections. |
| | | Bit 2. Collect Authority | | | | Bit 2. Collect Authority |
| | | sections. | | | | sections. |
| | | Bit 3. Collection Additional | | | | Bit 3. Collection Additional |
| | | sections. | | | | sections. |
| | | | | | | |
| accept-rr-types | Array of | A set of RR type names [rrtypes]. | | accept-rr-types | Array of | A set of RR type names [rrtypes]. |
| | text | If not empty, only the nominated | | | text | If not empty, only the nominated |
| | strings | RR types are collected. | | | strings | RR types are collected. |
| | | | | | | |
skipping to change at page 22, line 14 skipping to change at page 22, line 14
The Extended information is a CBOR map as follows. Each item in the The Extended information is a CBOR map as follows. Each item in the
map is present only if collection of the relevant details is map is present only if collection of the relevant details is
configured. Each item in the map has an unsigned value and an configured. Each item in the map has an unsigned value and an
unsigned key. unsigned key.
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| Field | Description | | Field | Description |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
| question-index | The index in the Questions list table of the | | question-index | The index in the Questions list table of the |
| | entry listing the second and subsequent | | | entry listing any second and subsequent |
| | Question sections for the Query or Response. | | | Questions in the Question section for the |
| | Query or Response. |
| | | | | |
| answer-index | The index in the RR list table of the entry | | answer-index | The index in the RR list table of the entry |
| | listing the Answer Resource Record sections | | | listing the Answer Resource Record sections |
| | for the Query or Response. | | | for the Query or Response. |
| | | | | |
| authority-index | The index in the RR list table of the entry | | authority-index | The index in the RR list table of the entry |
| | listing the Authority Resource Record sections | | | listing the Authority Resource Record sections |
| | for the Query or Response. | | | for the Query or Response. |
| | | | | |
| additional-index | The index in the RR list table of the entry | | additional-index | The index in the RR list table of the entry |
skipping to change at page 24, line 21 skipping to change at page 24, line 21
In principle, packets that do not meet these criteria could be In principle, packets that do not meet these criteria could be
classified into two categories: classified into two categories:
o Partially malformed: those packets which can be decoded o Partially malformed: those packets which can be decoded
sufficiently to extract sufficiently to extract
* a DNS header (and therefore a DNS transaction ID) * a DNS header (and therefore a DNS transaction ID)
* a QDCOUNT * a QDCOUNT
* the first question in the QUESTION section if QDCOUNT is * the first Question in the Question section if QDCOUNT is
greater than 0 greater than 0
but suffer other issues while parsing. This is the minimum but suffer other issues while parsing. This is the minimum
information required to attempt packet matching as described in information required to attempt Query/Response matching as
Section 10.1 described in Section 10.1
o Completely malformed: those packets that cannot be decoded to this o Completely malformed: those packets that cannot be decoded to this
extent. extent.
An open question is whether there is value in attempting to process An open question is whether there is value in attempting to process
partially malformed packets in an analogous manner to well formed partially malformed packets in an analogous manner to well formed
packets in terms of attempting to match them with the corresponding packets in terms of attempting to match them with the corresponding
query or response. This could be done by creating 'placeholder' query or response. This could be done by creating 'placeholder'
records during packet matching with just the information extracted as records during Query/Response matching with just the information
above. If the packet were then matched the resulting C-DNS Q/R data extracted as above. If the packet were then matched the resulting
item would include a flag to indicate a malformed record (in addition C-DNS Q/R data item would include a flag to indicate a malformed
to capturing the wire format of the packet). record (in addition to capturing the wire format of the packet).
An advantage of this would be that it would result in more meaningful An advantage of this would be that it would result in more meaningful
statistics about matched packets because, for example, some partially statistics about matched packets because, for example, some partially
malformed queries could be matched to responses. However it would malformed queries could be matched to responses. However it would
only apply to those queries where the first QUESTION is well formed. only apply to those queries where the first Question is well formed.
It could also simplify the downstream analysis of C-DNS files and the It could also simplify the downstream analysis of C-DNS files and the
reconstruction of packet streams from C-DNS. reconstruction of packet streams from C-DNS.
A disadvantage is that this adds complexity to the packet matching A disadvantage is that this adds complexity to the Query/Response
and data representation, could potentially lead to false matches and matching and data representation, could potentially lead to false
some additional statistics would be required (e.g. counts for matches and some additional statistics would be required (e.g. counts
matched-partially-malformed, unmatched-partially-malformed, for matched-partially-malformed, unmatched-partially-malformed,
completely-malformed). completely-malformed).
9. C-DNS to PCAP 9. C-DNS to PCAP
It is possible to re-construct PCAP files from the C-DNS format in a It is possible to re-construct PCAP files from the C-DNS format in a
lossy fashion. Some of the issues with reconstructing both the DNS lossy fashion. Some of the issues with reconstructing both the DNS
payload and the full packet stream are outlined here. payload and the full packet stream are outlined here.
The reconstruction depends on whether or not all the optional The reconstruction depends on whether or not all the optional
sections of both the query and response were captured in the C-DNS sections of both the query and response were captured in the C-DNS
skipping to change at page 26, line 15 skipping to change at page 26, line 15
9.1. Name Compression 9.1. Name Compression
All the names stored in the C-DNS format are full domain names; no All the names stored in the C-DNS format are full domain names; no
DNS style name compression is used on the individual names within the DNS style name compression is used on the individual names within the
format. Therefore when reconstructing a packet, name compression format. Therefore when reconstructing a packet, name compression
must be used in order to reproduce the on the wire representation of must be used in order to reproduce the on the wire representation of
the packet. the packet.
[RFC1035] name compression works by substituting trailing sections of [RFC1035] name compression works by substituting trailing sections of
a name with a reference back to the occurrence of those sections a name with a reference back to the occurrence of those sections
earlier in the packet. Not all name server software uses the same earlier in the message. Not all name server software uses the same
algorithm when compressing domain names within the responses. Some algorithm when compressing domain names within the responses. Some
attempt maximum recompression at the expense of runtime resources, attempt maximum recompression at the expense of runtime resources,
others use heuristics to balance compression and speed and others use others use heuristics to balance compression and speed and others use
different rules for what is a valid compression target. different rules for what is a valid compression target.
This means that responses to the same question from different name This means that responses to the same question from different name
server software which match in terms of DNS payload content (header, server software which match in terms of DNS payload content (header,
counts, RRs with name compression removed) do not necessarily match counts, RRs with name compression removed) do not necessarily match
byte-for-byte on the wire. byte-for-byte on the wire.
skipping to change at page 27, line 9 skipping to change at page 27, line 9
For the purposes of this discussion, it is assumed that the input has For the purposes of this discussion, it is assumed that the input has
been pre-processed such that: been pre-processed such that:
1. All IP fragmentation reassembly, TCP stream reassembly, and so 1. All IP fragmentation reassembly, TCP stream reassembly, and so
on, has already been performed on, has already been performed
2. Each message is associated with transport metadata required to 2. Each message is associated with transport metadata required to
generate the Primary ID (see Section 10.2.1) generate the Primary ID (see Section 10.2.1)
3. Each message has a well-formed DNS header of 12 bytes and (if 3. Each message has a well-formed DNS header of 12 bytes and (if
present) the first RR in the Question section can be parsed to present) the first Question in the Question section can be parsed
generate the Secondary ID (see below). As noted earlier, this to generate the Secondary ID (see below). As noted earlier, this
requirement can result in a malformed query being removed in the requirement can result in a malformed query being removed in the
pre-processing stage, but the correctly formed response with pre-processing stage, but the correctly formed response with
RCODE of FORMERR being present. RCODE of FORMERR being present.
DNS messages are processed in the order they are delivered to the DNS messages are processed in the order they are delivered to the
application. It should be noted that packet capture libraries do not application. It should be noted that packet capture libraries do not
necessary provide packets in strict chronological order. necessary provide packets in strict chronological order.
TODO: Discuss the corner cases resulting from this in more detail. TODO: Discuss the corner cases resulting from this in more detail.
10.1. Matching algorithm 10.1. Matching algorithm
A schematic representation of the algorithm for matching Q/R data A schematic representation of the algorithm for matching Q/R data
items is shown in the following diagram: items is shown in the following diagram:
Figure showing the packet matching algorithm format (PNG) [5] Figure showing the Query/Response matching algorithm format (PNG) [5]
Figure showing the packet matching algorithm format (SVG) [6] Figure showing the Query/Response matching algorithm format (SVG) [6]
Further details of the algorithm are given in the following sections. Further details of the algorithm are given in the following sections.
10.2. Message identifiers 10.2. Message identifiers
10.2.1. Primary ID (required) 10.2.1. Primary ID (required)
A Primary ID is constructed for each message. It is composed of the A Primary ID is constructed for each message. It is composed of the
following data: following data:
skipping to change at page 28, line 7 skipping to change at page 28, line 7
3. Source Port 3. Source Port
4. Destination Port 4. Destination Port
5. Transport 5. Transport
6. DNS Message ID 6. DNS Message ID
10.2.2. Secondary ID (optional) 10.2.2. Secondary ID (optional)
If present, the first question in the Question section is used as a 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 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 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). QDCOUNT of 0 (for example, responses with RCODE=FORMERR or NOTIMP).
In this case the secondary ID is not used in matching. In this case the secondary ID is not used in matching.
10.3. Algorithm Parameters 10.3. Algorithm Parameters
1. Query timeout 1. Query timeout
2. Skew timeout 2. Skew timeout
skipping to change at page 29, line 43 skipping to change at page 29, line 43
matching. Also Jan Vcelak and Wouter Wijngaards for discussions on matching. Also Jan Vcelak and Wouter Wijngaards for discussions on
name compression and Paul Hoffman for a detailed review of the name compression and Paul Hoffman for a detailed review of the
document and the C-DNS CDDL. document and the C-DNS CDDL.
Thanks also to Robert Edmonds and Jerry Lundstroem for review. Thanks also to Robert Edmonds and Jerry Lundstroem for review.
Also, Miek Gieben for mmark [7] Also, Miek Gieben for mmark [7]
14. Changelog 14. Changelog
draft-ietf-dnsop-dns-capture-format-02
o Update qr_data_format.png to match CDDL
o Editorial clarifications and improvements
draft-ietf-dnsop-dns-capture-format-01 draft-ietf-dnsop-dns-capture-format-01
o Many editorial improvements by Paul Hoffman o Many editorial improvements by Paul Hoffman
o Included discussion of malformed packet handling o Included discussion of malformed packet handling
o Improved Appendix C on Comparison of Binary Formats o Improved Appendix C on Comparison of Binary Formats
o Now using C-DNS field names in the tables in section 8 o Now using C-DNS field names in the tables in section 8
o A handful of new fields included (CDDL updated) o A handful of new fields included (CDDL updated)
o Timestamps now include optional picoseconds o Timestamps now include optional picoseconds
o Added details of block statistics o Added details of block statistics
draft-ietf-dnsop-dns-capture-format-00 draft-ietf-dnsop-dns-capture-format-00
o Changed dnstap.io to dnstap.info o Changed dnstap.io to dnstap.info
skipping to change at page 31, line 33 skipping to change at page 31, line 41
[dsc] Wessels, D. and J. Lundstrom, "DSC", 2016, [dsc] Wessels, D. and J. Lundstrom, "DSC", 2016,
<https://www.dns-oarc.net/tools/dsc>. <https://www.dns-oarc.net/tools/dsc>.
[I-D.daley-dnsxml] [I-D.daley-dnsxml]
Daley, J., Morris, S., and J. Dickinson, "dnsxml - A Daley, J., Morris, S., and J. Dickinson, "dnsxml - A
standard XML representation of DNS data", draft-daley- standard XML representation of DNS data", draft-daley-
dnsxml-00 (work in progress), July 2013. dnsxml-00 (work in progress), July 2013.
[I-D.greevenbosch-appsawg-cbor-cddl] [I-D.greevenbosch-appsawg-cbor-cddl]
Vigano, C. and H. Birkholz, "CBOR data definition language Birkholz, H., Vigano, C., and C. Bormann, "CBOR data
(CDDL): a notational convention to express CBOR data definition language (CDDL): a notational convention to
structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work express CBOR data structures", draft-greevenbosch-appsawg-
in progress), September 2016. cbor-cddl-10 (work in progress), March 2017.
[I-D.hoffman-dns-in-json] [I-D.hoffman-dns-in-json]
Hoffman, P., "Representing DNS Messages in JSON", draft- Hoffman, P., "Representing DNS Messages in JSON", draft-
hoffman-dns-in-json-10 (work in progress), October 2016. hoffman-dns-in-json-11 (work in progress), March 2017.
[packetq] .SE - The Internet Infrastructure Foundation, "PacketQ", [packetq] .SE - The Internet Infrastructure Foundation, "PacketQ",
2014, <https://github.com/dotse/PacketQ>. 2014, <https://github.com/dotse/PacketQ>.
[pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>. [pcap] tcpdump.org, "PCAP", 2016, <http://www.tcpdump.org/>.
[pcapng] Tuexen, M., Risso, F., Bongertz, J., Combs, G., and G. [pcapng] Tuexen, M., Risso, F., Bongertz, J., Combs, G., and G.
Harris, "pcap-ng", 2016, <https://github.com/pcapng/ Harris, "pcap-ng", 2016, <https://github.com/pcapng/
pcapng>. pcapng>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <http://www.rfc-editor.org/info/rfc7159>.
[rrtypes] IANA, "RR types", 2016, <http://www.iana.org/assignments/ [rrtypes] IANA, "RR types", 2016, <http://www.iana.org/assignments/
dns-parameters/dns-parameters.xhtml#dns-parameters-4>. dns-parameters/dns-parameters.xhtml#dns-parameters-4>.
15.3. URIs 15.3. URIs
[1] https://github.com/dns-stats/draft-dns-capture- [1] https://github.com/dns-stats/draft-dns-capture-
format/blob/master/cdns_format.png format/blob/master/draft-02/cdns_format.png
[2] https://github.com/dns-stats/draft-dns-capture- [2] https://github.com/dns-stats/draft-dns-capture-
format/blob/master/cdns_format.svg format/blob/master/draft-02/cdns_format.svg
[3] https://github.com/dns-stats/draft-dns-capture- [3] https://github.com/dns-stats/draft-dns-capture-
format/blob/master/qr_data_format.png format/blob/master/draft-02/qr_data_format.png
[4] https://github.com/dns-stats/draft-dns-capture- [4] https://github.com/dns-stats/draft-dns-capture-
format/blob/master/qr_data_format.svg format/blob/master/draft-02/qr_data_format.svg
[5] https://github.com/dns-stats/draft-dns-capture- [5] https://github.com/dns-stats/draft-dns-capture-
format/blob/master/packet_matching.png format/blob/master/draft-02/packet_matching.png
[6] https://github.com/dns-stats/draft-dns-capture- [6] https://github.com/dns-stats/draft-dns-capture-
format/blob/master/packet_matching.svg format/blob/master/draft-02/packet_matching.svg
[7] https://github.com/miekg/mmark [7] https://github.com/miekg/mmark
[8] https://www.nlnetlabs.nl/projects/nsd/ [8] https://www.nlnetlabs.nl/projects/nsd/
[9] https://www.knot-dns.cz/ [9] https://www.knot-dns.cz/
[10] https://avro.apache.org/ [10] https://avro.apache.org/
[11] https://developers.google.com/protocol-buffers/ [11] https://developers.google.com/protocol-buffers/
skipping to change at page 34, line 10 skipping to change at page 34, line 16
? filter => tstr, ? filter => tstr,
? query-options => QRCollectionSections, ? query-options => QRCollectionSections,
? response-options => QRCollectionSections, ? response-options => QRCollectionSections,
? accept-rr-types => [* uint], ? accept-rr-types => [* uint],
? ignore-rr-types => [* uint], ? ignore-rr-types => [* uint],
? max-block-qr-items => uint, ? max-block-qr-items => uint,
? collect-malformed => uint, ? collect-malformed => uint,
} }
QRCollectionSectionValues = &( QRCollectionSectionValues = &(
question : 0, ; Second & subsequent question sections question : 0, ; Second & subsequent questions
answer : 1, answer : 1,
authority : 2, authority : 2,
additional: 3, additional: 3,
) )
QRCollectionSections = uint .bits QRCollectionSectionValues QRCollectionSections = uint .bits QRCollectionSectionValues
query-timeout = 0 query-timeout = 0
skew-timeout = 1 skew-timeout = 1
snaplen = 2 snaplen = 2
promisc = 3 promisc = 3
 End of changes. 35 change blocks. 
45 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/