Internet Engineering Task Force (IETF)                      J. Dickinson
Request for Comments: 8618                                      J. Hague
Category: Standards Track                                   S. Dickinson
ISSN: 2070-1721                                               Sinodun IT
                                                            T. Manderson
                                                                   ICANN
                                                                 J. Bond
                                              Wikimedia Foundation, Inc.
                                                          September 2019
        
Internet Engineering Task Force (IETF)                      J. Dickinson
Request for Comments: 8618                                      J. Hague
Category: Standards Track                                   S. Dickinson
ISSN: 2070-1721                                               Sinodun IT
                                                            T. Manderson
                                                                   ICANN
                                                                 J. Bond
                                              Wikimedia Foundation, Inc.
                                                          September 2019
        

Compacted-DNS (C-DNS): A Format for DNS Packet Capture

压缩DNS(C-DNS):用于DNS数据包捕获的格式

Abstract

摘要

This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the full DNS message contents along with the most useful transport metadata. It is intended to assist with the development of DNS traffic-monitoring applications.

本文档描述DNS消息集合的数据表示。该格式设计用于高效存储和传输DNS流量的大数据包捕获;它试图最小化此类数据包捕获文件的大小,但保留完整的DNS消息内容以及最有用的传输元数据。它旨在帮助开发DNS流量监控应用程序。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 7841第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8618.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问https://www.rfc-editor.org/info/rfc8618.

Copyright Notice

版权公告

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

版权(c)2019 IETF信托基金和被确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Data Collection Use Cases . . . . . . . . . . . . . . . . . .   5
   4.  Design Considerations . . . . . . . . . . . . . . . . . . . .   8
   5.  Choice of CBOR  . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  C-DNS Format Conceptual Overview  . . . . . . . . . . . . . .  10
     6.1.  Block Parameters  . . . . . . . . . . . . . . . . . . . .  14
     6.2.  Storage Parameters  . . . . . . . . . . . . . . . . . . .  14
       6.2.1.  Optional Data Items . . . . . . . . . . . . . . . . .  15
       6.2.2.  Optional RRs and OPCODEs  . . . . . . . . . . . . . .  16
       6.2.3.  Storage Flags . . . . . . . . . . . . . . . . . . . .  17
       6.2.4.  IP Address Storage  . . . . . . . . . . . . . . . . .  17
   7.  C-DNS Format Detailed Description . . . . . . . . . . . . . .  18
     7.1.  Map Quantities and Indexes  . . . . . . . . . . . . . . .  18
     7.2.  Tabular Representation  . . . . . . . . . . . . . . . . .  18
     7.3.  "File"  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       7.3.1.  "FilePreamble"  . . . . . . . . . . . . . . . . . . .  20
         7.3.1.1.  "BlockParameters" . . . . . . . . . . . . . . . .  20
           7.3.1.1.1.  "StorageParameters" . . . . . . . . . . . . .  21
             7.3.1.1.1.1.  "StorageHints"  . . . . . . . . . . . . .  22
           7.3.1.1.2.  "CollectionParameters"  . . . . . . . . . . .  24
       7.3.2.  "Block" . . . . . . . . . . . . . . . . . . . . . . .  25
         7.3.2.1.  "BlockPreamble" . . . . . . . . . . . . . . . . .  26
         7.3.2.2.  "BlockStatistics" . . . . . . . . . . . . . . . .  27
         7.3.2.3.  "BlockTables" . . . . . . . . . . . . . . . . . .  28
           7.3.2.3.1.  "ClassType" . . . . . . . . . . . . . . . . .  29
           7.3.2.3.2.  "QueryResponseSignature"  . . . . . . . . . .  30
           7.3.2.3.3.  "Question"  . . . . . . . . . . . . . . . . .  33
           7.3.2.3.4.  "RR"  . . . . . . . . . . . . . . . . . . . .  34
           7.3.2.3.5.  "MalformedMessageData"  . . . . . . . . . . .  34
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Data Collection Use Cases . . . . . . . . . . . . . . . . . .   5
   4.  Design Considerations . . . . . . . . . . . . . . . . . . . .   8
   5.  Choice of CBOR  . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  C-DNS Format Conceptual Overview  . . . . . . . . . . . . . .  10
     6.1.  Block Parameters  . . . . . . . . . . . . . . . . . . . .  14
     6.2.  Storage Parameters  . . . . . . . . . . . . . . . . . . .  14
       6.2.1.  Optional Data Items . . . . . . . . . . . . . . . . .  15
       6.2.2.  Optional RRs and OPCODEs  . . . . . . . . . . . . . .  16
       6.2.3.  Storage Flags . . . . . . . . . . . . . . . . . . . .  17
       6.2.4.  IP Address Storage  . . . . . . . . . . . . . . . . .  17
   7.  C-DNS Format Detailed Description . . . . . . . . . . . . . .  18
     7.1.  Map Quantities and Indexes  . . . . . . . . . . . . . . .  18
     7.2.  Tabular Representation  . . . . . . . . . . . . . . . . .  18
     7.3.  "File"  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       7.3.1.  "FilePreamble"  . . . . . . . . . . . . . . . . . . .  20
         7.3.1.1.  "BlockParameters" . . . . . . . . . . . . . . . .  20
           7.3.1.1.1.  "StorageParameters" . . . . . . . . . . . . .  21
             7.3.1.1.1.1.  "StorageHints"  . . . . . . . . . . . . .  22
           7.3.1.1.2.  "CollectionParameters"  . . . . . . . . . . .  24
       7.3.2.  "Block" . . . . . . . . . . . . . . . . . . . . . . .  25
         7.3.2.1.  "BlockPreamble" . . . . . . . . . . . . . . . . .  26
         7.3.2.2.  "BlockStatistics" . . . . . . . . . . . . . . . .  27
         7.3.2.3.  "BlockTables" . . . . . . . . . . . . . . . . . .  28
           7.3.2.3.1.  "ClassType" . . . . . . . . . . . . . . . . .  29
           7.3.2.3.2.  "QueryResponseSignature"  . . . . . . . . . .  30
           7.3.2.3.3.  "Question"  . . . . . . . . . . . . . . . . .  33
           7.3.2.3.4.  "RR"  . . . . . . . . . . . . . . . . . . . .  34
           7.3.2.3.5.  "MalformedMessageData"  . . . . . . . . . . .  34
        
         7.3.2.4.  "QueryResponse" . . . . . . . . . . . . . . . . .  35
           7.3.2.4.1.  "ResponseProcessingData"  . . . . . . . . . .  36
           7.3.2.4.2.  "QueryResponseExtended" . . . . . . . . . . .  37
         7.3.2.5.  "AddressEventCount" . . . . . . . . . . . . . . .  38
         7.3.2.6.  "MalformedMessage"  . . . . . . . . . . . . . . .  39
   8.  Versioning  . . . . . . . . . . . . . . . . . . . . . . . . .  39
   9.  C-DNS to PCAP . . . . . . . . . . . . . . . . . . . . . . . .  40
     9.1.  Name Compression  . . . . . . . . . . . . . . . . . . . .  42
   10. Data Collection . . . . . . . . . . . . . . . . . . . . . . .  42
     10.1.  Matching Algorithm . . . . . . . . . . . . . . . . . . .  43
     10.2.  Message Identifiers  . . . . . . . . . . . . . . . . . .  45
       10.2.1.  Primary ID (Required)  . . . . . . . . . . . . . . .  45
       10.2.2.  Secondary ID (Optional)  . . . . . . . . . . . . . .  46
     10.3.  Algorithm Parameters . . . . . . . . . . . . . . . . . .  46
     10.4.  Algorithm Requirements . . . . . . . . . . . . . . . . .  46
     10.5.  Algorithm Limitations  . . . . . . . . . . . . . . . . .  47
     10.6.  Workspace  . . . . . . . . . . . . . . . . . . . . . . .  47
     10.7.  Output . . . . . . . . . . . . . . . . . . . . . . . . .  47
     10.8.  Post-Processing  . . . . . . . . . . . . . . . . . . . .  47
   11. Implementation Guidance . . . . . . . . . . . . . . . . . . .  47
     11.1.  Optional Data  . . . . . . . . . . . . . . . . . . . . .  48
     11.2.  Trailing Bytes . . . . . . . . . . . . . . . . . . . . .  48
     11.3.  Limiting Collection of RDATA . . . . . . . . . . . . . .  49
     11.4.  Timestamps . . . . . . . . . . . . . . . . . . . . . . .  49
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  49
     12.1.  Transport Types  . . . . . . . . . . . . . . . . . . . .  49
     12.2.  Data Storage Flags . . . . . . . . . . . . . . . . . . .  50
     12.3.  Response-Processing Flags  . . . . . . . . . . . . . . .  51
     12.4.  AddressEvent Types . . . . . . . . . . . . . . . . . . .  51
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  52
   14. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  52
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  53
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  53
     15.2.  Informative References . . . . . . . . . . . . . . . . .  55
   Appendix A.  CDDL . . . . . . . . . . . . . . . . . . . . . . . .  58
   Appendix B.  DNS Name Compression Example . . . . . . . . . . . .  69
     B.1.  NSD Compression Algorithm . . . . . . . . . . . . . . . .  70
     B.2.  Knot Authoritative Compression Algorithm  . . . . . . . .  70
     B.3.  Observed Differences  . . . . . . . . . . . . . . . . . .  71
   Appendix C.  Comparison of Binary Formats . . . . . . . . . . . .  71
     C.1.  Comparison with Full PCAP Files . . . . . . . . . . . . .  74
     C.2.  Simple versus Block Coding  . . . . . . . . . . . . . . .  74
     C.3.  Binary versus Text Formats  . . . . . . . . . . . . . . .  75
     C.4.  Performance . . . . . . . . . . . . . . . . . . . . . . .  75
     C.5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . .  75
     C.6.  Block Size Choice . . . . . . . . . . . . . . . . . . . .  76
        
         7.3.2.4.  "QueryResponse" . . . . . . . . . . . . . . . . .  35
           7.3.2.4.1.  "ResponseProcessingData"  . . . . . . . . . .  36
           7.3.2.4.2.  "QueryResponseExtended" . . . . . . . . . . .  37
         7.3.2.5.  "AddressEventCount" . . . . . . . . . . . . . . .  38
         7.3.2.6.  "MalformedMessage"  . . . . . . . . . . . . . . .  39
   8.  Versioning  . . . . . . . . . . . . . . . . . . . . . . . . .  39
   9.  C-DNS to PCAP . . . . . . . . . . . . . . . . . . . . . . . .  40
     9.1.  Name Compression  . . . . . . . . . . . . . . . . . . . .  42
   10. Data Collection . . . . . . . . . . . . . . . . . . . . . . .  42
     10.1.  Matching Algorithm . . . . . . . . . . . . . . . . . . .  43
     10.2.  Message Identifiers  . . . . . . . . . . . . . . . . . .  45
       10.2.1.  Primary ID (Required)  . . . . . . . . . . . . . . .  45
       10.2.2.  Secondary ID (Optional)  . . . . . . . . . . . . . .  46
     10.3.  Algorithm Parameters . . . . . . . . . . . . . . . . . .  46
     10.4.  Algorithm Requirements . . . . . . . . . . . . . . . . .  46
     10.5.  Algorithm Limitations  . . . . . . . . . . . . . . . . .  47
     10.6.  Workspace  . . . . . . . . . . . . . . . . . . . . . . .  47
     10.7.  Output . . . . . . . . . . . . . . . . . . . . . . . . .  47
     10.8.  Post-Processing  . . . . . . . . . . . . . . . . . . . .  47
   11. Implementation Guidance . . . . . . . . . . . . . . . . . . .  47
     11.1.  Optional Data  . . . . . . . . . . . . . . . . . . . . .  48
     11.2.  Trailing Bytes . . . . . . . . . . . . . . . . . . . . .  48
     11.3.  Limiting Collection of RDATA . . . . . . . . . . . . . .  49
     11.4.  Timestamps . . . . . . . . . . . . . . . . . . . . . . .  49
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  49
     12.1.  Transport Types  . . . . . . . . . . . . . . . . . . . .  49
     12.2.  Data Storage Flags . . . . . . . . . . . . . . . . . . .  50
     12.3.  Response-Processing Flags  . . . . . . . . . . . . . . .  51
     12.4.  AddressEvent Types . . . . . . . . . . . . . . . . . . .  51
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  52
   14. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  52
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  53
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  53
     15.2.  Informative References . . . . . . . . . . . . . . . . .  55
   Appendix A.  CDDL . . . . . . . . . . . . . . . . . . . . . . . .  58
   Appendix B.  DNS Name Compression Example . . . . . . . . . . . .  69
     B.1.  NSD Compression Algorithm . . . . . . . . . . . . . . . .  70
     B.2.  Knot Authoritative Compression Algorithm  . . . . . . . .  70
     B.3.  Observed Differences  . . . . . . . . . . . . . . . . . .  71
   Appendix C.  Comparison of Binary Formats . . . . . . . . . . . .  71
     C.1.  Comparison with Full PCAP Files . . . . . . . . . . . . .  74
     C.2.  Simple versus Block Coding  . . . . . . . . . . . . . . .  74
     C.3.  Binary versus Text Formats  . . . . . . . . . . . . . . .  75
     C.4.  Performance . . . . . . . . . . . . . . . . . . . . . . .  75
     C.5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . .  75
     C.6.  Block Size Choice . . . . . . . . . . . . . . . . . . . .  76
        
   Appendix D.  Data Fields for Traffic Regeneration . . . . . . . .  77
     D.1.  Recommended Fields for Traffic Regeneration . . . . . . .  77
     D.2.  Issues with Small Data Captures . . . . . . . . . . . . .  77
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  78
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  79
        
   Appendix D.  Data Fields for Traffic Regeneration . . . . . . . .  77
     D.1.  Recommended Fields for Traffic Regeneration . . . . . . .  77
     D.2.  Issues with Small Data Captures . . . . . . . . . . . . .  77
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  78
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  79
        
1. Introduction
1. 介绍

There has long been a need for server operators to collect DNS Queries and Responses on authoritative and recursive name servers for monitoring and analysis. This data is used in a number of ways, including traffic monitoring, analyzing network attacks, and "day in the life" (DITL) [ditl] analysis.

长期以来,服务器运营商需要在权威和递归名称服务器上收集DNS查询和响应,以便进行监视和分析。这些数据有多种用途,包括流量监测、分析网络攻击和“日常生活”(DITL)[DITL]分析。

A wide variety of tools already exist that facilitate the collection of DNS traffic data, such as the DNS Statistics Collector (DSC) [dsc], packetq [packetq], dnscap [dnscap], and dnstap [dnstap]. However, there is no standard exchange format for large DNS packet captures. The PCAP ("packet capture") [pcap] format or the PCAP Next Generation (PCAP-NG) [pcapng] format is typically used in practice for packet captures, but these file formats can contain a great deal of additional information that is not directly pertinent to DNS traffic analysis and thus unnecessarily increases the capture file size. Additionally, these tools and formats typically have no filter mechanism to selectively record only certain fields at capture time, requiring post-processing for anonymization or pseudonymization of data to protect user privacy.

已经存在各种各样的工具来促进DNS流量数据的收集,例如DNS统计收集器(DSC)[DSC]、packetq[packetq]、dnscap[dnscap]和dnstap[dnstap]。但是,没有用于大型DNS数据包捕获的标准交换格式。PCAP(“数据包捕获”)[PCAP]格式或PCAP下一代(PCAP-NG)[pcapng]格式通常在实践中用于数据包捕获,但这些文件格式可能包含大量与DNS流量分析不直接相关的附加信息,因此不必要地增加捕获文件的大小。此外,这些工具和格式通常没有过滤机制,在捕获时仅选择性地记录某些字段,需要对数据进行匿名或假名化后处理,以保护用户隐私。

There has also been work on using text-based formats to describe DNS packets (for example, see [dnsxml] and [RFC8427]), but this work is largely aimed at producing convenient representations of single messages.

也有关于使用基于文本的格式来描述DNS数据包的工作(例如,请参见[dnsxml]和[RFC8427]),但这项工作主要是为了方便地表示单个消息。

Many DNS operators may receive hundreds of thousands of Queries per second on a single name server instance, so a mechanism to minimize the storage and transmission size (and therefore upload overhead) of the data collected is highly desirable.

许多DNS运营商每秒可能会在单个名称服务器实例上接收数十万个查询,因此非常需要一种机制来最小化所收集数据的存储和传输大小(从而减少上传开销)。

The format described in this document, C-DNS (Compacted-DNS), focuses on the problem of capturing and storing large packet capture files of DNS traffic with the following goals in mind:

本文档中描述的格式C-DNS(压缩DNS)侧重于捕获和存储DNS流量的大型数据包捕获文件的问题,并牢记以下目标:

o Minimize the file size for storage and transmission.

o 最小化存储和传输的文件大小。

o Minimize the overhead of producing the packet capture file and the cost of any further (general-purpose) compression of the file.

o 将生成数据包捕获文件的开销和进一步(通用)压缩文件的成本降至最低。

This document contains:

本文件包括:

o A discussion of some common use cases in which DNS data is collected; see Section 3.

o 讨论收集DNS数据的一些常见用例;见第3节。

o A discussion of the major design considerations in developing an efficient data representation for collections of DNS messages; see Section 4.

o 讨论为DNS消息集合开发有效数据表示时的主要设计考虑事项;见第4节。

o A description of why the Concise Binary Object Representation (CBOR) [RFC7049] was chosen for this format; see Section 5.

o 说明为何为该格式选择简明二进制对象表示法(CBOR)[RFC7049];见第5节。

o A conceptual overview of the C-DNS format; see Section 6.

o C-DNS格式的概念概述;见第6节。

o The definition of the C-DNS format for the collection of DNS messages; see Section 7.

o 用于收集DNS消息的C-DNS格式的定义;见第7节。

o Notes on converting C-DNS data to PCAP format; see Section 9.

o 关于将C-DNS数据转换为PCAP格式的说明;见第9节。

o Some high-level implementation considerations for applications designed to produce C-DNS; see Section 10.

o 设计用于产生C-DNS的应用程序的一些高级实现注意事项;见第10节。

2. Terminology
2. 术语

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时(如图所示)应按照BCP 14[RFC2119][RFC8174]所述进行解释。

"Packet" refers to an individual IPv4 or IPv6 packet. Typically, packets are UDP datagrams, but such packets may also be part of a TCP data stream. "Message", unless otherwise qualified, refers to a DNS payload extracted from a UDP datagram or a TCP data stream.

“数据包”指单个IPv4或IPv6数据包。通常,数据包是UDP数据报,但此类数据包也可能是TCP数据流的一部分。除非另有限定,“消息”是指从UDP数据报或TCP数据流提取的DNS有效负载。

The parts of DNS messages are named as they are in [RFC1035]. Specifically, the DNS message has five sections: Header, Question, Answer, Authority, and Additional.

DNS消息的部分按[RFC1035]中的名称命名。具体来说,DNS消息有五个部分:标题、问题、答案、权限和附加信息。

3. Data Collection Use Cases
3. 数据收集用例

From a purely server operator perspective, collecting full packet captures of all packets going into or out of a name server provides the most comprehensive picture of network activity. However, there are several design choices or other limitations that are common to many DNS installations and operators.

从纯服务器运营商的角度来看,收集进入或离开名称服务器的所有数据包的完整数据包捕获提供了最全面的网络活动图片。但是,许多DNS安装和运营商都有一些设计选择或其他限制。

o DNS servers are hosted in a variety of situations:

o DNS服务器托管在多种情况下:

* Self-hosted servers

* 自托管服务器

* Third-party hosting (including multiple third parties)

* 第三方托管(包括多个第三方)

* Third-party hardware (including multiple third parties)

* 第三方硬件(包括多个第三方)

o Data is collected under different conditions:

o 在不同条件下收集数据:

* On well-provisioned servers running in a steady state

* 在配置良好的服务器上以稳定状态运行

* On heavily loaded servers

* 在负载沉重的服务器上

* On virtualized servers

* 在虚拟化服务器上

* On servers that are under DoS attack

* 在受到DoS攻击的服务器上

* On servers that are unwitting intermediaries in DoS attacks

* 在DoS攻击中作为不知情中介的服务器上

o Traffic can be collected via a variety of mechanisms:

o 可以通过多种机制收集流量:

* Within the name server implementation itself

* 在名称服务器实现本身中

* On the same hardware as the name server itself

* 在与名称服务器本身相同的硬件上

* Using a network tap on an adjacent host to listen to DNS traffic

* 在相邻主机上使用网络点击监听DNS流量

* Using port mirroring to listen from another host

* 使用端口镜像从另一台主机侦听

o The capabilities of data collection (and upload) networks vary:

o 数据收集(和上传)网络的功能各不相同:

* Out-of-band networks with the same capacity as the in-band network

* 与带内网络容量相同的带外网络

* Out-of-band networks with less capacity than the in-band network

* 容量小于带内网络的带外网络

* Everything being on the in-band network

* 一切都在带内网络上

Thus, there is a wide range of use cases, from very limited data collection environments (third-party hardware, servers that are under attack, packet capture on the name server itself and no out-of-band network) to "limitless" environments (self-hosted, well-provisioned servers, using a network tap or port mirroring with out-of-band networks with the same capacity as the in-band network). In the

因此,从非常有限的数据收集环境(第三方硬件、受到攻击的服务器、名称服务器本身上的数据包捕获以及没有带外网络)到“无限”环境,存在着广泛的用例(自托管、资源调配良好的服务器,使用网络分接或端口镜像,带外网络的容量与带内网络的容量相同)

former case, it is infeasible to reliably collect full packet captures, especially if the server is under attack. In the latter case, collection of full packet captures may be reasonable.

在前一种情况下,可靠地收集完整的数据包捕获是不可行的,尤其是当服务器受到攻击时。在后一种情况下,收集完整数据包捕获可能是合理的。

As a result of these restrictions, the C-DNS data format is designed with the most limited use case in mind, such that:

由于这些限制,C-DNS数据格式的设计考虑了最有限的用例,例如:

o Data collection will occur on the same hardware as the name server itself

o 数据收集将在与名称服务器本身相同的硬件上进行

o Collected data will be stored on the same hardware as the name server itself, at least temporarily

o 收集的数据将与名称服务器本身存储在同一硬件上,至少是暂时存储

o Collected data being returned to some central analysis system will use the same network interface as the DNS Queries and Responses

o 返回到某个中央分析系统的收集数据将使用与DNS查询和响应相同的网络接口

o There can be multiple third-party servers involved

o 可能涉及多个第三方服务器

Because of these considerations, a major factor in the design of the format is minimal storage size of the capture files.

由于这些考虑,格式设计中的一个主要因素是捕获文件的最小存储大小。

Another significant consideration for any application that records DNS traffic is that the running of the name server software and the transmission of DNS Queries and Responses are the most important jobs of a name server; capturing data is not. Any data collection system co-located with the name server needs to be intelligent enough to carefully manage its CPU, disk, memory, and network utilization. This leads to designing a format that requires a relatively low overhead to produce and minimizes the requirement for further potentially costly compression.

记录DNS流量的任何应用程序的另一个重要考虑因素是名称服务器软件的运行以及DNS查询和响应的传输是名称服务器最重要的工作;捕获数据并非易事。任何与名称服务器共存的数据采集系统都需要足够智能,以便仔细管理其CPU、磁盘、内存和网络利用率。这将导致设计一种格式,该格式需要相对较低的开销来生成,并最大限度地减少对进一步的潜在昂贵压缩的需求。

However, it is also essential that interoperability with less restricted infrastructure is maintained. In particular, it is highly desirable that the collection format should facilitate the re-creation of common formats (such as PCAP) that are as close to the original as is realistic, given the restrictions above.

然而,保持与限制较少的基础设施的互操作性也是至关重要的。特别是,考虑到上述限制,收集格式应该有助于重新创建尽可能接近原始格式的通用格式(如PCAP)。

4. Design Considerations
4. 设计考虑

This section presents some of the major design considerations used in the development of the C-DNS format.

本节介绍了C-DNS格式开发中使用的一些主要设计注意事项。

1. The basic unit of data is a combined DNS Query and the associated Response (a "Query/Response (Q/R) data item"). The same structure will be used for unmatched Queries and Responses. Queries without Responses will be captured omitting the Response data. Responses without Queries will be captured omitting the Query data (but using the Question section from the Response, if present, as an identifying QNAME).

1. 数据的基本单位是一个组合的DNS查询和相关的响应(“查询/响应(Q/R)数据项”)。相同的结构将用于不匹配的查询和响应。将捕获没有响应的查询,而忽略响应数据。将捕获不带查询的响应,忽略查询数据(但使用响应中的问题部分(如果存在)作为标识QNAME)。

* Rationale: A Query and the associated Response represent the basic level of a client's interaction with the server. Also, combining the Query and Response into one item often reduces storage requirements due to commonality in the data of the two messages.

* 理由:查询和相关响应表示客户端与服务器交互的基本级别。此外,由于两条消息的数据具有共性,因此将查询和响应组合到一个项目中通常会减少存储需求。

In the context of generating a C-DNS file, it is assumed that only those DNS payloads that can be parsed to produce a well-formed DNS message are stored in the structured Query/ Response data items of the C-DNS format and that all other messages will (optionally) be recorded as separate malformed messages. Parsing a well-formed message means, at a minimum, the following:

在生成C-DNS文件的上下文中,假设只有那些可被解析以生成格式良好的DNS消息的DNS有效负载存储在C-DNS格式的结构化查询/响应数据项中,并且所有其他消息(可选)将被记录为单独的格式错误的消息。解析格式良好的消息至少意味着:

* The packet has a well-formed 12-byte DNS Header with a recognized OPCODE.

* 该数据包具有格式良好的12字节DNS报头,带有可识别的操作码。

* The section counts are consistent with the section contents.

* 章节数量与章节内容一致。

* All of the Resource Records (RRs) can be fully parsed.

* 所有资源记录(RRs)都可以完全解析。

2. All top-level fields in each Query/Response data item will be optional.

2. 每个查询/响应数据项中的所有顶级字段都是可选的。

* Rationale: Different operators will have different requirements for data to be available for analysis. Operators with minimal requirements should not have to pay the cost of recording full data, though this will limit the ability to perform certain kinds of data analysis and also to reconstruct packet captures. For example, omitting the RRs from a Response will reduce the C-DNS file size; in principle, Responses can be synthesized if there is enough context. Operators may have different policies for collecting user data and can choose to omit or anonymize certain fields at capture time, e.g., client address.

* 理由:不同的操作员对可用于分析的数据有不同的要求。具有最低要求的操作员不必支付记录完整数据的成本,尽管这将限制执行某些类型的数据分析以及重构数据包捕获的能力。例如,从响应中省略RRs将减小C-DNS文件的大小;原则上,如果有足够的上下文,可以合成响应。运营商可能有不同的收集用户数据的策略,并且可以选择在捕获时省略或匿名某些字段,例如客户端地址。

3. Multiple Query/Response data items will be collected into blocks in the format. Common data in a block will be abstracted and referenced from individual Query/Response data items by indexing. The maximum number of Query/Response data items in a block will be configurable.

3. 多个查询/响应数据项将按以下格式收集到块中。块中的公共数据将通过索引从单个查询/响应数据项中提取和引用。可配置块中查询/响应数据项的最大数量。

* Rationale: This blocking and indexing action provides a significant reduction in the volume of file data generated. Although this introduces complexity, it provides compression of the data that makes use of knowledge of the DNS message structure.

* 理由:这种阻塞和索引操作大大减少了生成的文件数据量。尽管这引入了复杂性,但它利用DNS消息结构的知识提供了数据压缩。

* It is anticipated that the files produced can be subject to further compression using general-purpose compression tools. Measurements show that blocking significantly reduces the CPU required to perform such strong compression. See Appendix C.2.

* 预计生成的文件可以使用通用压缩工具进行进一步压缩。测量结果表明,阻塞显著减少了执行这种强压缩所需的CPU。见附录C.2。

* Examples of commonality between DNS messages are that in most cases the QUESTION RR is the same in the Query and Response and that there is a finite set of Query "signatures" (based on a subset of attributes). For many authoritative servers, there is very likely to be a finite set of Responses that are generated, of which a large number are NXDOMAIN.

* DNS消息之间的共性示例是,在大多数情况下,问题RR在查询和响应中是相同的,并且存在一组有限的查询“签名”(基于属性子集)。对于许多权威服务器,很可能会生成有限的响应集,其中大量响应是在域中生成的。

4. Traffic metadata can optionally be included in each block. Specifically, counts of some types of non-DNS packets (e.g., ICMP, TCP resets) sent to the server may be of interest.

4. 流量元数据可以选择性地包含在每个块中。具体地说,发送到服务器的某些类型的非DNS数据包(例如,ICMP、TCP重置)的计数可能是令人感兴趣的。

5. The wire-format content of malformed DNS messages may optionally be recorded.

5. 可以选择性地记录格式错误的DNS消息的有线格式内容。

* Rationale: Any structured capture format that does not capture the DNS payload byte for byte will be limited to some extent in that it cannot represent malformed DNS messages. Only those messages that can be fully parsed and transformed into the structured format can be fully represented. Note, however, that this can result in rather misleading statistics. For example, a malformed Query that cannot be represented in the C-DNS format will lead to the (well-formed) DNS Response with error code FORMERR appearing as "unmatched". Therefore, it can greatly aid downstream analysis to have the wire format of the malformed DNS messages available directly in the C-DNS file.

* 理由:任何不逐字节捕获DNS有效负载的结构化捕获格式都会受到一定程度的限制,因为它不能表示格式错误的DNS消息。只有那些可以完全解析并转换为结构化格式的消息才能完全表示。然而,请注意,这可能会导致误导性的统计数据。例如,无法以C-DNS格式表示的格式错误的查询将导致(格式正确的)DNS响应,错误代码FORMERR显示为“不匹配”。因此,在C-DNS文件中直接提供格式错误的DNS消息的有线格式可以极大地帮助下游分析。

5. Choice of CBOR
5. CBOR的选择

This document presents a detailed format description for C-DNS. The format uses CBOR [RFC7049].

本文档提供了C-DNS的详细格式说明。该格式使用CBOR[RFC7049]。

The choice of CBOR was made taking a number of factors into account.

CBOR的选择考虑了许多因素。

o CBOR is a binary representation and thus is economical in storage space.

o CBOR是一种二进制表示,因此在存储空间上是经济的。

o Other binary representations were investigated, and whilst all had attractive features, none had a significant advantage over CBOR. See Appendix C for some discussion of this.

o 研究了其他二进制表示法,虽然所有表示法都具有吸引人的特征,但没有一种表示法比CBOR具有显著优势。有关这方面的一些讨论,请参见附录C。

o CBOR is an IETF specification and is familiar to IETF participants. It is based on the now-common ideas of lists and objects and thus requires very little familiarization for those in the wider industry.

o CBOR是IETF规范,IETF参与者熟悉。它是基于现在对列表和对象的常见想法,因此对更广泛行业的人来说几乎不需要熟悉。

o CBOR is a simple format and can easily be implemented from scratch if necessary. Formats that are more complex require library support, which may present problems on unusual platforms.

o CBOR是一种简单的格式,如果需要,可以很容易地从头开始实现。更复杂的格式需要库支持,这在不寻常的平台上可能会出现问题。

o CBOR can also be easily converted to text formats such as JSON [RFC8259] for debugging and other human inspection requirements.

o CBOR还可以轻松转换为JSON[RFC8259]等文本格式,用于调试和其他人工检查需求。

o CBOR data schemas can be described using the Concise Data Definition Language (CDDL) [RFC8610].

o CBOR数据模式可以使用简明数据定义语言(CDDL)[RFC8610]来描述。

6. C-DNS Format Conceptual Overview
6. C-DNS格式概念概述

The following figures show purely schematic representations of the C-DNS format to convey the high-level structure of the C-DNS format. Section 7 provides a detailed discussion of the CBOR representation and individual elements.

下图显示了C-DNS格式的纯示意图,以传达C-DNS格式的高级结构。第7节详细讨论了CBOR表示和各个要素。

Figure 1 shows the C-DNS format at the top level, including the file header and data blocks. The Query/Response data items, Address/Event Count data items, and Malformed Message data items link to various Block Tables.

图1显示了顶层的C-DNS格式,包括文件头和数据块。查询/响应数据项、地址/事件计数数据项和格式错误的消息数据项链接到各种块表。

                   +-------+
                   + C-DNS |
                   +-------+--------------------------+
                   | File Type Identifier             |
                   +----------------------------------+
                   | File Preamble                    |
                   | +--------------------------------+
                   | | Format Version                 |
                   | +--------------------------------+
                   | | Block Parameters               |
                   +-+--------------------------------+
                   | Block                            |
                   | +--------------------------------+
                   | | Block Preamble                 |
                   | +--------------------------------+
                   | | Block Statistics               |
                   | +--------------------------------+
                   | | Block Tables                   |
                   | +--------------------------------+
                   | | Query/Response data items      |
                   | +--------------------------------+
                   | | Address/Event Count data items |
                   | +--------------------------------+
                   | | Malformed Message data items   |
                   +-+--------------------------------+
                   | Block                            |
                   | +--------------------------------+
                   | | Block Preamble                 |
                   | +--------------------------------+
                   | | Block Statistics               |
                   | +--------------------------------+
                   | | Block Tables                   |
                   | +--------------------------------+
                   | | Query/Response data items      |
                   | +--------------------------------+
                   | | Address/Event Count data items |
                   | +--------------------------------+
                   | | Malformed Message data items   |
                   +-+--------------------------------+
                   | Further Blocks...                |
                   +----------------------------------+
        
                   +-------+
                   + C-DNS |
                   +-------+--------------------------+
                   | File Type Identifier             |
                   +----------------------------------+
                   | File Preamble                    |
                   | +--------------------------------+
                   | | Format Version                 |
                   | +--------------------------------+
                   | | Block Parameters               |
                   +-+--------------------------------+
                   | Block                            |
                   | +--------------------------------+
                   | | Block Preamble                 |
                   | +--------------------------------+
                   | | Block Statistics               |
                   | +--------------------------------+
                   | | Block Tables                   |
                   | +--------------------------------+
                   | | Query/Response data items      |
                   | +--------------------------------+
                   | | Address/Event Count data items |
                   | +--------------------------------+
                   | | Malformed Message data items   |
                   +-+--------------------------------+
                   | Block                            |
                   | +--------------------------------+
                   | | Block Preamble                 |
                   | +--------------------------------+
                   | | Block Statistics               |
                   | +--------------------------------+
                   | | Block Tables                   |
                   | +--------------------------------+
                   | | Query/Response data items      |
                   | +--------------------------------+
                   | | Address/Event Count data items |
                   | +--------------------------------+
                   | | Malformed Message data items   |
                   +-+--------------------------------+
                   | Further Blocks...                |
                   +----------------------------------+
        

Figure 1: The C-DNS Format

图1:C-DNS格式

Figure 2 shows some more-detailed relationships within each Block, specifically those between the Query/Response data item and the relevant Block Tables. Some fields have been omitted for clarity.

图2显示了每个块内的一些更详细的关系,特别是查询/响应数据项和相关块表之间的关系。为了清楚起见,省略了一些字段。

   +----------------+
   | Query/Response |
   +-------------------------+
   | Time Offset             |
   +-------------------------+            +------------------+
   | Client Address          |---------+->| IP Address array |
   +-------------------------+         |  +------------------+
   | Client Port             |         |
   +-------------------------+         |  +------------------+
   | Transaction ID          |     +---)->| Name/RDATA array |<--------+
   +-------------------------+     |   |  +------------------+         |
   | Query Signature         |--+  |   |                               |
   +-------------------------+  |  |   |  +-----------------+          |
   | Client Hoplimit (q)     |  +--)---)->| Query Signature |          |
   +-------------------------+     |   |  +-----------------+-------+  |
   | Response Delay (r)      |     |   +--| Server Address          |  |
   +-------------------------+     |      +-------------------------+  |
   | Query Name              |--+--+      | Server Port             |  |
   +-------------------------+  |         +-------------------------+  |
   | Query Size (q)          |  |         | Transport Flags         |  |
   +-------------------------+  |         +-------------------------+  |
   | Response Size (r)       |  |         | QR Type                 |  |
   +-------------------------+  |         +-------------------------+  |
   | Response Processing (r) |  |         | QR Signature Flags      |  |
   | +-----------------------+  |         +-------------------------+  |
   | | Bailiwick             |--+         | Query OPCODE (q)        |  |
   | +-----------------------+            +-------------------------+  |
   | | Flags                 |            | QR DNS Flags            |  |
   +-+-----------------------+            +-------------------------+  |
   | Extra Query Info (q)    |            | Query RCODE (q)         |  |
   | +-----------------------+            +-------------------------+  |
   | | Question              |--+---+  +--+-Query Class/Type (q)    |  |
   | +-----------------------+      |  |  +-------------------------+  |
   | | Answer                |--+   |  |  | Query QDCOUNT (q)       |  |
   | +-----------------------+  |   |  |  +-------------------------+  |
   | | Authority             |--+   |  |  | Query ANCOUNT (q)       |  |
   | +-----------------------+  |   |  |  +-------------------------+  |
   | | Additional            |--+   |  |  | Query NSCOUNT (q)       |  |
        
   +----------------+
   | Query/Response |
   +-------------------------+
   | Time Offset             |
   +-------------------------+            +------------------+
   | Client Address          |---------+->| IP Address array |
   +-------------------------+         |  +------------------+
   | Client Port             |         |
   +-------------------------+         |  +------------------+
   | Transaction ID          |     +---)->| Name/RDATA array |<--------+
   +-------------------------+     |   |  +------------------+         |
   | Query Signature         |--+  |   |                               |
   +-------------------------+  |  |   |  +-----------------+          |
   | Client Hoplimit (q)     |  +--)---)->| Query Signature |          |
   +-------------------------+     |   |  +-----------------+-------+  |
   | Response Delay (r)      |     |   +--| Server Address          |  |
   +-------------------------+     |      +-------------------------+  |
   | Query Name              |--+--+      | Server Port             |  |
   +-------------------------+  |         +-------------------------+  |
   | Query Size (q)          |  |         | Transport Flags         |  |
   +-------------------------+  |         +-------------------------+  |
   | Response Size (r)       |  |         | QR Type                 |  |
   +-------------------------+  |         +-------------------------+  |
   | Response Processing (r) |  |         | QR Signature Flags      |  |
   | +-----------------------+  |         +-------------------------+  |
   | | Bailiwick             |--+         | Query OPCODE (q)        |  |
   | +-----------------------+            +-------------------------+  |
   | | Flags                 |            | QR DNS Flags            |  |
   +-+-----------------------+            +-------------------------+  |
   | Extra Query Info (q)    |            | Query RCODE (q)         |  |
   | +-----------------------+            +-------------------------+  |
   | | Question              |--+---+  +--+-Query Class/Type (q)    |  |
   | +-----------------------+      |  |  +-------------------------+  |
   | | Answer                |--+   |  |  | Query QDCOUNT (q)       |  |
   | +-----------------------+  |   |  |  +-------------------------+  |
   | | Authority             |--+   |  |  | Query ANCOUNT (q)       |  |
   | +-----------------------+  |   |  |  +-------------------------+  |
   | | Additional            |--+   |  |  | Query NSCOUNT (q)       |  |
        
   +-+-----------------------+  |   |  |  +-------------------------+  |
   | Extra Response Info (r) |  |-+ |  |  | Query ARCOUNT (q)       |  |
   | +-----------------------+  | | |  |  +-------------------------+  |
   | | Answer                |--+ | |  |  | Query EDNS version (q)  |  |
   | +-----------------------+  | | |  |  +-------------------------+  |
   | | Authority             |--+ | |  |  | Query EDNS UDP Size (q) |  |
   | +-----------------------+  | | |  |  +-------------------------+  |
   | | Additional            |--+ | |  |  | Query OPT RDATA (q)     |--+
   +-+-----------------------+    | |  |  +-------------------------+  |
                                  | |  |  | Response RCODE (r)      |  |
                                  | |  |  +-------------------------+  |
   + -----------------------------+ |  +----------+                    |
   |                                |             |                    |
   | + -----------------------------+             |                    |
   | |  +---------------+  +----------+           |                    |
   | +->| Question List |->| Question |           |                    |
   |    | array         |  | array    |           |                    |
   |    +---------------+  +----------+--+        |                    |
   |                       | Name        |--+-----)--------------------+
   |                       +-------------+  |     |  +------------+
   |                       | Class/Type  |--)---+-+->| Class/Type |
   |                       +-------------+  |   |    | array      |
   |                                        |   |    +------------+--+
   |                                        |   |    | CLASS         |
   |    +---------------+  +----------+     |   |    +---------------+
   +--->| RR List array |->| RR array |     |   |    | TYPE          |
        +---------+-----+  +----------+--+  |   |    +---------------+
                           | Name        |--+   |
                           +-------------+      |
                           | Class/Type  |------+
                           +-------------+
        
   +-+-----------------------+  |   |  |  +-------------------------+  |
   | Extra Response Info (r) |  |-+ |  |  | Query ARCOUNT (q)       |  |
   | +-----------------------+  | | |  |  +-------------------------+  |
   | | Answer                |--+ | |  |  | Query EDNS version (q)  |  |
   | +-----------------------+  | | |  |  +-------------------------+  |
   | | Authority             |--+ | |  |  | Query EDNS UDP Size (q) |  |
   | +-----------------------+  | | |  |  +-------------------------+  |
   | | Additional            |--+ | |  |  | Query OPT RDATA (q)     |--+
   +-+-----------------------+    | |  |  +-------------------------+  |
                                  | |  |  | Response RCODE (r)      |  |
                                  | |  |  +-------------------------+  |
   + -----------------------------+ |  +----------+                    |
   |                                |             |                    |
   | + -----------------------------+             |                    |
   | |  +---------------+  +----------+           |                    |
   | +->| Question List |->| Question |           |                    |
   |    | array         |  | array    |           |                    |
   |    +---------------+  +----------+--+        |                    |
   |                       | Name        |--+-----)--------------------+
   |                       +-------------+  |     |  +------------+
   |                       | Class/Type  |--)---+-+->| Class/Type |
   |                       +-------------+  |   |    | array      |
   |                                        |   |    +------------+--+
   |                                        |   |    | CLASS         |
   |    +---------------+  +----------+     |   |    +---------------+
   +--->| RR List array |->| RR array |     |   |    | TYPE          |
        +---------+-----+  +----------+--+  |   |    +---------------+
                           | Name        |--+   |
                           +-------------+      |
                           | Class/Type  |------+
                           +-------------+
        

Figure 2: The Query/Response Data Item and Subsidiary Tables

图2:查询/响应数据项和子表

In Figure 2, data items annotated (q) are only present when a Query/Response has a Query, and those annotated (r) are only present when a Query/Response Response is present.

在图2中,注释(q)的数据项仅在查询/响应有查询时出现,注释(r)的数据项仅在查询/响应出现时出现。

A C-DNS file begins with a file header containing a File Type Identifier and a File Preamble. The File Preamble contains information on the file Format Version and an array of Block Parameters items (the contents of which include Collection and Storage Parameters used for one or more Blocks).

C-DNS文件以包含文件类型标识符和文件前导的文件头开始。文件序言包含有关文件格式版本的信息和块参数项数组(其内容包括用于一个或多个块的收集和存储参数)。

The file header is followed by a series of Blocks.

文件头后面跟着一系列块。

A Block consists of a Block Preamble item, some Block Statistics for the traffic stored within the Block, and then various arrays of common data collectively called the Block Tables. This is then followed by an array of the Query/Response data items detailing the Queries and Responses stored within the Block. The array of Query/Response data items is in turn followed by the Address/Event Count data items (an array of per-client counts of particular IP events) and then Malformed Message data items (an array of malformed messages that are stored in the Block).

一个块由一个块前导项、存储在该块中的流量的一些块统计信息,以及各种公共数据数组(统称为块表)组成。然后是查询/响应数据项数组,详细说明块中存储的查询和响应。查询/响应数据项的数组依次是地址/事件计数数据项(特定IP事件的每个客户端计数的数组)和格式错误的消息数据项(存储在块中的格式错误的消息数组)。

The exact nature of the DNS data will affect what Block size is the best fit; however, sample data for a root server indicated that Block sizes up to 10,000 Query/Response data items give good results. See Appendix C.6 for more details.

DNS数据的确切性质将影响最适合的块大小;但是,根服务器的示例数据表明,块大小高达10000个查询/响应数据项可以提供良好的结果。详见附录C.6。

This design exploits data commonality and block-based storage to minimize the C-DNS file size. As a result, C-DNS cannot be streamed below the level of a Block.

此设计利用数据通用性和基于块的存储来最小化C-DNS文件大小。因此,C-DNS不能在块级别以下进行流式传输。

6.1. Block Parameters
6.1. 块参数

The details of the Block Parameters items are not shown in the diagrams but are discussed here for context.

图中未显示块参数项的详细信息,但此处将根据上下文进行讨论。

An array of Block Parameters items is stored in the File Preamble (with a minimum of one item at index 0); a Block Parameters item consists of a collection of Storage and Collection Parameters that applies to any given Block. An array is used in order to support use cases such as wanting to merge C-DNS files from different sources. The Block Preamble item then contains an optional index for the Block Parameters item that applies for that Block; if not present, the index defaults to 0. Hence, in effect, a global Block Parameters item is defined that can then be overridden per Block.

块参数项的数组存储在文件前导中(索引0处至少有一项);块参数项由应用于任何给定块的存储参数和集合参数的集合组成。阵列用于支持用例,例如希望合并来自不同来源的C-DNS文件。然后,块前导项包含适用于该块的块参数项的可选索引;如果不存在,则索引默认为0。因此,实际上,定义了一个全局块参数项,然后可以在每个块上覆盖该项。

6.2. Storage Parameters
6.2. 存储参数

The Block Parameters item includes a Storage Parameters item -- this contains information about the specific data fields stored in the C-DNS file.

块参数项包括存储参数项——它包含有关存储在C-DNS文件中的特定数据字段的信息。

These parameters include:

这些参数包括:

o The sub-second timing resolution used by the data.

o 数据使用的次秒计时分辨率。

o Information (hints) on which optional data are omitted. See Section 6.2.1.

o 省略可选数据的信息(提示)。见第6.2.1节。

o Recorded OPCODES [opcodes] and RR TYPEs [rrtypes]. See Section 6.2.2.

o 记录的操作码[操作码]和RR类型[rrtypes]。见第6.2.2节。

o Flags indicating, for example, whether the data is sampled or anonymized. See Sections 6.2.3 and 14.

o 例如,指示数据是采样还是匿名的标志。见第6.2.3和14节。

o Client and server IPv4 and IPv6 address prefixes. See Section 6.2.4.

o 客户端和服务器IPv4和IPv6地址前缀。见第6.2.4节。

6.2.1. Optional Data Items
6.2.1. 可选数据项

To enable implementations to store data to their precise requirements in as space-efficient a manner as possible, all fields in the following arrays are optional:

为了使实现能够以尽可能节省空间的方式存储符合其精确要求的数据,以下阵列中的所有字段都是可选的:

o Query/Response

o 查询/答复

o Query Signature

o 查询签名

o Malformed Messages

o 格式错误的消息

In other words, an implementation can choose to omit any data item that is not required for its use case (whilst observing the restrictions relating to IP address storage described in Section 6.2.4). In addition, implementations may be configured to not record all RRs or to only record messages with certain OPCODES.

换句话说,实现可以选择省略其用例不需要的任何数据项(同时遵守第6.2.4节中描述的与IP地址存储相关的限制)。此外,可以将实现配置为不记录所有rr或仅记录具有特定操作码的消息。

This does, however, mean that a consumer of a C-DNS file faces two problems:

然而,这确实意味着C-DNS文件的使用者面临两个问题:

1. How can it quickly determine if a file definitely does not contain the data items it requires to complete a particular task (e.g., reconstructing DNS traffic or performing a specific piece of data analysis)?

1. 它如何快速确定文件是否确实不包含完成特定任务所需的数据项(例如,重建DNS流量或执行特定的数据分析)?

2. How can it determine whether a data item is not present because it was (1) explicitly not recorded or (2) not available/present?

2. 它如何确定某个数据项是否不存在,因为它(1)明确未记录或(2)不可用/存在?

For example, capturing C-DNS data from within a name server implementation makes it unlikely that the Client Hoplimit can be recorded. Or, if there is no Query ARCOUNT recorded and no Query OPT RDATA [RFC6891] recorded, is that because no Query contained an OPT RR, or because that data was not stored?

例如,从名称服务器实现中捕获C-DNS数据使得不太可能记录客户端跃点限制。或者,如果没有记录查询ARCOUNT,也没有记录查询OPT RDATA[RFC6891],是因为没有查询包含OPT RR,还是因为没有存储该数据?

The Storage Parameters item therefore also contains a Storage Hints item, which specifies which items the encoder of the file omits from the stored data and will therefore never be present. (This approach is taken because a flag that indicated which items were included for

因此,存储参数项还包含一个存储提示项,该项指定文件的编码器从存储的数据中忽略了哪些项,因此这些项永远不会出现。(之所以采用这种方法,是因为有一个标志指示哪些项目包括在

collection would not guarantee that the item was present -- only that it might be.) An implementation decoding that file can then use these flags to quickly determine whether the input data is not rich enough for its needs.

集合不能保证该项存在——只能保证它可能存在。)解码该文件的实现然后可以使用这些标志快速确定输入数据是否不够丰富,无法满足其需要。

One scenario where this may be particularly important is the case of regenerating traffic. It is possible to collect such a small set of data items that an implementation decoding the file cannot determine if a given Query/Response data item was generated from just a Query, just a Response, or a Query/Response pair. This makes it impossible to reconstruct DNS traffic even if sensible defaults are provided for the missing data items. This is discussed in more detail in Section 9.

这可能特别重要的一个场景是重新生成流量的情况。可以收集如此小的数据项集,以至于解码文件的实现无法确定给定的查询/响应数据项是仅从查询、响应还是查询/响应对生成的。这使得即使为丢失的数据项提供了合理的默认值,也无法重建DNS流量。第9节对此进行了更详细的讨论。

6.2.2. Optional RRs and OPCODEs
6.2.2. 可选RRs和操作码

Also included in the Storage Parameters item are explicit arrays listing the RR TYPEs and the OPCODEs to be recorded. These arrays remove any ambiguity over whether, for example, messages containing particular OPCODEs are not present because (1) certain OPCODEs did not occur or (2) the implementation is not configured to record them.

存储参数项中还包括显式数组,其中列出了要记录的RR类型和操作码。例如,由于(1)某些操作码未出现或(2)实现未配置为记录它们,这些数组消除了关于是否不存在包含特定操作码的消息的任何歧义。

In the case of OPCODEs, for a message to be fully parsable, the OPCODE must be known to the collecting implementation. Any message with an OPCODE unknown to the collecting implementation cannot be validated as correctly formed and so must be treated as malformed. Messages with OPCODES known to the recording application but not listed in the Storage Parameters item are discarded by the recording application during C-DNS capture (regardless of whether they are malformed or not).

对于操作码,要使消息完全可解析,收集实现必须知道操作码。任何带有收集实现未知操作码的消息都无法验证为格式正确,因此必须视为格式错误。在C-DNS捕获期间,记录应用程序将丢弃操作码为记录应用程序已知但未在存储参数项中列出的消息(无论其格式是否错误)。

In the case of RRs, each record in a message must be fully parsable, including parsing the record RDATA, as otherwise the message cannot be validated as correctly formed. Any RR with an RR TYPE not known to the collecting implementation cannot be validated as correctly formed and so must be treated as malformed.

对于RRs,消息中的每个记录都必须是完全可解析的,包括解析记录RDATA,否则无法验证消息的格式是否正确。收集实现不知道RR类型的任何RR都无法验证为正确格式,因此必须视为格式不正确。

Once a message is correctly parsed, an implementation is free to record only a subset of the RRs present.

一旦消息被正确解析,实现就可以自由地只记录当前RRs的一个子集。

6.2.3. Storage Flags
6.2.3. 存储标志

The Storage Parameters item contains flags that can be used to indicate if:

存储参数项包含可用于指示以下情况的标志:

o the data is anonymized,

o 数据是匿名的,

o the data is produced from sample data, or

o 数据由样本数据生成,或

o names in the data have been normalized (converted to uniform case).

o 数据中的名称已规范化(转换为统一大小写)。

The Storage Parameters item also contains optional fields holding details of the sampling method used and the anonymization method used. It is RECOMMENDED that these fields contain URIs [RFC3986] pointing to resources describing the methods used. See Section 14 for further discussion of anonymization and normalization.

存储参数项还包含可选字段,其中包含所用采样方法和匿名方法的详细信息。建议这些字段包含指向描述所用方法的资源的URI[RFC3986]。有关匿名化和规范化的进一步讨论,请参见第14节。

6.2.4. IP Address Storage
6.2.4. IP地址存储器

The format can store either full IP addresses or just IP prefixes; the Storage Parameters item contains fields to indicate if only IP prefixes were stored.

该格式可以存储完整的IP地址,也可以只存储IP前缀;存储参数项包含用于指示是否仅存储IP前缀的字段。

If the IP address prefixes are absent, then full addresses are stored. In this case, the IP version can be directly inferred from the stored address length and the fields "qr-transport-flags" in QueryResponseSignature, "ae-transport-flags" in AddressEventCount, and "mm-transport-flags" in MalformedMessageData (which contain the IP version bit) are optional.

如果没有IP地址前缀,则存储完整地址。在这种情况下,可以从存储的地址长度直接推断IP版本,QueryResponseSignature中的字段“qr transport flags”、“AddressEventCount中的ae transport flags”和MalformedMessageData中的字段“mm transport flags”(包含IP版本位)是可选的。

If IP address prefixes are given, only the prefix bits of addresses are stored. In this case, in order to determine the IP version, the fields "qr-transport-flags" in QueryResponseSignature, "ae-transport-flags" in AddressEventCount, and "mm-transport-flags" in MalformedMessageData MUST be present. See Sections 7.3.2.3.2 and 7.3.2.3.5.

如果给定IP地址前缀,则只存储地址的前缀位。在这种情况下,为了确定IP版本,QueryResponseSignature中的字段“qr传输标志”、AddressEventCount中的“ae传输标志”和MalformedMessageData中的“mm传输标志”必须存在。见第7.3.2.3.2节和第7.3.2.3.5节。

As an example of storing only IP prefixes, if a client IPv6 prefix of 48 is specified, a client address of 2001:db8:85a3::8a2e:370:7334 will be stored as 0x20010db885a3, reducing address storage space requirements. Similarly, if a client IPv4 prefix of 16 is specified, a client address of 192.0.2.1 will be stored as 0xc000 (192.0).

作为仅存储IP前缀的示例,如果指定了客户端IPv6前缀48,则2001:db8:85a3::8a2e:370:7334的客户端地址将存储为0x20010db885a3,从而减少地址存储空间需求。类似地,如果指定了客户端IPv4前缀16,则192.0.2.1的客户端地址将存储为0xc000(192.0)。

7. C-DNS Format Detailed Description
7. C-DNS格式详细说明

The CDDL definition for the C-DNS format is given in Appendix A.

附录A中给出了C-DNS格式的CDDL定义。

7.1. Map Quantities and Indexes
7.1. 地图数量和索引

All map keys are integers with values specified in the CDDL. String keys would significantly bloat the file size.

所有映射键都是CDDL中指定值的整数。字符串键会显著增大文件大小。

All key values specified are positive integers under 24, so their CBOR representation is a single byte. Positive integer values not currently used as keys in a map are reserved for use in future standard extensions.

所有指定的键值都是24以下的正整数,因此它们的CBOR表示为单字节。当前未在映射中用作键的正整数值保留在将来的标准扩展中使用。

Implementations may choose to add additional implementation-specific entries to any map. Negative integer map keys are reserved for these values. Key values from -1 to -24 also have a single-byte CBOR representation, so such implementation-specific extensions are not at any space efficiency disadvantage.

实现可以选择向任何映射添加其他特定于实现的条目。为这些值保留负整数映射键。从-1到-24的键值也有一个单字节CBOR表示,因此这种特定于实现的扩展不存在任何空间效率的缺点。

An item described as an index is the index of the data item in the referenced array. Indexes are 0-based.

描述为索引的项是引用数组中数据项的索引。索引是基于0的。

7.2. Tabular Representation
7.2. 表格表示法

The following sections present the C-DNS specification in tabular format with a detailed description of each item.

以下各节以表格形式呈现了C-DNS规范,并对每个项目进行了详细说明。

In all quantities that contain bit flags, bit 0 indicates the least significant bit, i.e., flag "n" in quantity "q" is on if "(q & (1 << n)) != 0".

在包含位标志的所有量中,位0表示最低有效位,即,如果(q&(1<<n))!=0,则数量“q”中的标志“n”处于打开状态。

For the sake of readability, all type and field names defined in the CDDL definition are shown in double quotes. Type names are by convention camel case (e.g., "BlockTables"), and field names are lowercase with hyphens (e.g., "block-tables").

为了可读性,CDDL定义中定义的所有类型和字段名都用双引号表示。按照惯例,类型名是大小写(例如“块表”),字段名是小写加连字符(例如“块表”)。

For the sake of brevity, the following conventions are used in the tables:

为简洁起见,表中使用了以下约定:

o The column M marks whether items in a map are mandatory.

o M列标记地图中的项目是否为必填项。

* X - Mandatory items.

* X-强制性项目。

* C - Conditionally mandatory items. Such items are usually optional but may be mandatory in some configurations.

* C-有条件的强制性项目。这些项目通常是可选的,但在某些配置中可能是强制性的。

* If the column is empty, the item is optional.

* 如果列为空,则该项为可选项。

o The column T gives the CBOR datatype of the item.

o 列T给出了该项的CBOR数据类型。

* U - Unsigned integer.

* U-无符号整数。

* I - Signed integer (i.e., either a CBOR unsigned integer or a CBOR negative integer).

* I-有符号整数(即,CBOR无符号整数或CBOR负整数)。

* B - Boolean.

* B-布尔型。

* S - Byte string.

* S字节字符串。

* T - Text string.

* T-文本字符串。

* M - Map.

* M-地图。

* A - Array.

* A-数组。

In the case of maps and arrays, more information on the type of each value, including the CDDL definition name if applicable, is given in the description.

对于映射和数组,描述中给出了关于每个值类型的更多信息,包括CDDL定义名称(如果适用)。

7.3. "File"
7.3. “文件”

A C-DNS file has an outer structure "File", an array that contains the following:

C-DNS文件具有外部结构“文件”,即包含以下内容的数组:

   +---------------+---+---+-------------------------------------------+
   | Field         | M | T | Description                               |
   +---------------+---+---+-------------------------------------------+
   | file-type-id  | X | T | String "C-DNS" identifying the file type. |
   |               |   |   |                                           |
   | file-preamble | X | M | Version and parameter information for the |
   |               |   |   | whole file.  Map of type "FilePreamble";  |
   |               |   |   | see Section 7.3.1.                        |
   |               |   |   |                                           |
   | file-blocks   | X | A | Array of items of type "Block"; see       |
   |               |   |   | Section 7.3.2.  The array may be empty if |
   |               |   |   | the file contains no data.                |
   +---------------+---+---+-------------------------------------------+
        
   +---------------+---+---+-------------------------------------------+
   | Field         | M | T | Description                               |
   +---------------+---+---+-------------------------------------------+
   | file-type-id  | X | T | String "C-DNS" identifying the file type. |
   |               |   |   |                                           |
   | file-preamble | X | M | Version and parameter information for the |
   |               |   |   | whole file.  Map of type "FilePreamble";  |
   |               |   |   | see Section 7.3.1.                        |
   |               |   |   |                                           |
   | file-blocks   | X | A | Array of items of type "Block"; see       |
   |               |   |   | Section 7.3.2.  The array may be empty if |
   |               |   |   | the file contains no data.                |
   +---------------+---+---+-------------------------------------------+
        
7.3.1. "FilePreamble"
7.3.1. “文件序言”

Information about data in the file. A map containing the following:

有关文件中数据的信息。包含以下内容的地图:

   +----------------------+---+---+------------------------------------+
   | Field                | M | T | Description                        |
   +----------------------+---+---+------------------------------------+
   | major-format-version | X | U | Unsigned integer "1".  The major   |
   |                      |   |   | version of the format used in the  |
   |                      |   |   | file.  See Section 8.              |
   |                      |   |   |                                    |
   | minor-format-version | X | U | Unsigned integer "0".  The minor   |
   |                      |   |   | version of the format used in the  |
   |                      |   |   | file.  See Section 8.              |
   |                      |   |   |                                    |
   | private-version      |   | U | Version indicator available for    |
   |                      |   |   | private use by implementations.    |
   |                      |   |   |                                    |
   | block-parameters     | X | A | Array of items of type             |
   |                      |   |   | "BlockParameters".  See Section    |
   |                      |   |   | 7.3.1.1.  The array must contain   |
   |                      |   |   | at least one entry.  (The          |
   |                      |   |   | "block-parameters-index" item in   |
   |                      |   |   | each "BlockPreamble" indicates     |
   |                      |   |   | which array entry applies to that  |
   |                      |   |   | "Block".)                          |
   +----------------------+---+---+------------------------------------+
        
   +----------------------+---+---+------------------------------------+
   | Field                | M | T | Description                        |
   +----------------------+---+---+------------------------------------+
   | major-format-version | X | U | Unsigned integer "1".  The major   |
   |                      |   |   | version of the format used in the  |
   |                      |   |   | file.  See Section 8.              |
   |                      |   |   |                                    |
   | minor-format-version | X | U | Unsigned integer "0".  The minor   |
   |                      |   |   | version of the format used in the  |
   |                      |   |   | file.  See Section 8.              |
   |                      |   |   |                                    |
   | private-version      |   | U | Version indicator available for    |
   |                      |   |   | private use by implementations.    |
   |                      |   |   |                                    |
   | block-parameters     | X | A | Array of items of type             |
   |                      |   |   | "BlockParameters".  See Section    |
   |                      |   |   | 7.3.1.1.  The array must contain   |
   |                      |   |   | at least one entry.  (The          |
   |                      |   |   | "block-parameters-index" item in   |
   |                      |   |   | each "BlockPreamble" indicates     |
   |                      |   |   | which array entry applies to that  |
   |                      |   |   | "Block".)                          |
   +----------------------+---+---+------------------------------------+
        
7.3.1.1. "BlockParameters"
7.3.1.1. “块参数”

Parameters relating to data storage and collection that apply to one or more items of type "Block". A map containing the following:

适用于一个或多个“块”类型项的与数据存储和收集相关的参数。包含以下内容的地图:

   +-----------------------+---+---+-----------------------------------+
   | Field                 | M | T | Description                       |
   +-----------------------+---+---+-----------------------------------+
   | storage-parameters    | X | M | Parameters relating to data       |
   |                       |   |   | storage in a "Block" item.  Map   |
   |                       |   |   | of type "StorageParameters"; see  |
   |                       |   |   | Section 7.3.1.1.1.                |
   |                       |   |   |                                   |
   | collection-parameters |   | M | Parameters relating to collection |
   |                       |   |   | of the data in a "Block" item.    |
   |                       |   |   | Map of type                       |
   |                       |   |   | "CollectionParameters"; see       |
   |                       |   |   | Section 7.3.1.1.2.                |
   +-----------------------+---+---+-----------------------------------+
        
   +-----------------------+---+---+-----------------------------------+
   | Field                 | M | T | Description                       |
   +-----------------------+---+---+-----------------------------------+
   | storage-parameters    | X | M | Parameters relating to data       |
   |                       |   |   | storage in a "Block" item.  Map   |
   |                       |   |   | of type "StorageParameters"; see  |
   |                       |   |   | Section 7.3.1.1.1.                |
   |                       |   |   |                                   |
   | collection-parameters |   | M | Parameters relating to collection |
   |                       |   |   | of the data in a "Block" item.    |
   |                       |   |   | Map of type                       |
   |                       |   |   | "CollectionParameters"; see       |
   |                       |   |   | Section 7.3.1.1.2.                |
   +-----------------------+---+---+-----------------------------------+
        
7.3.1.1.1. "StorageParameters"
7.3.1.1.1. “存储参数”

Parameters relating to how data is stored in the items of type "Block". A map containing the following:

与数据如何存储在“块”类型项中有关的参数。包含以下内容的地图:

   +------------------+---+---+----------------------------------------+
   | Field            | M | T | Description                            |
   +------------------+---+---+----------------------------------------+
   | ticks-per-second | X | U | Sub-second timing is recorded in       |
   |                  |   |   | ticks.  This specifies the number of   |
   |                  |   |   | ticks in a second.                     |
   |                  |   |   |                                        |
   | max-block-items  | X | U | The maximum number of items stored in  |
   |                  |   |   | any of the arrays in a "Block" item    |
   |                  |   |   | (Q/R, Address/Event Count, or          |
   |                  |   |   | Malformed Message data items).  An     |
   |                  |   |   | indication to a decoder of the         |
   |                  |   |   | resources needed to process the file.  |
   |                  |   |   |                                        |
   | storage-hints    | X | M | Collection of hints as to which fields |
   |                  |   |   | are omitted in the arrays that have    |
   |                  |   |   | optional fields.  Map of type          |
   |                  |   |   | "StorageHints".  See Section           |
   |                  |   |   | 7.3.1.1.1.1.                           |
   |                  |   |   |                                        |
   | opcodes          | X | A | Array of OPCODES [opcodes] (unsigned   |
   |                  |   |   | integers, each in the range 0 to 15    |
   |                  |   |   | inclusive) recorded by the collecting  |
   |                  |   |   | implementation.  See Section 6.2.2.    |
   |                  |   |   |                                        |
   | rr-types         | X | A | Array of RR TYPEs [rrtypes] (unsigned  |
   |                  |   |   | integers, each in the range 0 to 65535 |
   |                  |   |   | inclusive) recorded by the collecting  |
   |                  |   |   | implementation.  See Section 6.2.2.    |
   |                  |   |   |                                        |
   | storage-flags    |   | U | Bit flags indicating attributes of     |
   |                  |   |   | stored data.                           |
   |                  |   |   | Bit 0.  1 if the data has been         |
   |                  |   |   | anonymized.                            |
   |                  |   |   | Bit 1.  1 if the data is sampled data. |
   |                  |   |   | Bit 2.  1 if the names have been       |
   |                  |   |   | normalized (converted to uniform       |
   |                  |   |   | case).                                 |
   |                  |   |   |                                        |
   | client-address   |   | U | IPv4 client address prefix length, in  |
   | -prefix-ipv4     |   |   | the range 1 to 32 inclusive.  If       |
   |                  |   |   | specified, only the address prefix     |
   |                  |   |   | bits are stored.                       |
        
   +------------------+---+---+----------------------------------------+
   | Field            | M | T | Description                            |
   +------------------+---+---+----------------------------------------+
   | ticks-per-second | X | U | Sub-second timing is recorded in       |
   |                  |   |   | ticks.  This specifies the number of   |
   |                  |   |   | ticks in a second.                     |
   |                  |   |   |                                        |
   | max-block-items  | X | U | The maximum number of items stored in  |
   |                  |   |   | any of the arrays in a "Block" item    |
   |                  |   |   | (Q/R, Address/Event Count, or          |
   |                  |   |   | Malformed Message data items).  An     |
   |                  |   |   | indication to a decoder of the         |
   |                  |   |   | resources needed to process the file.  |
   |                  |   |   |                                        |
   | storage-hints    | X | M | Collection of hints as to which fields |
   |                  |   |   | are omitted in the arrays that have    |
   |                  |   |   | optional fields.  Map of type          |
   |                  |   |   | "StorageHints".  See Section           |
   |                  |   |   | 7.3.1.1.1.1.                           |
   |                  |   |   |                                        |
   | opcodes          | X | A | Array of OPCODES [opcodes] (unsigned   |
   |                  |   |   | integers, each in the range 0 to 15    |
   |                  |   |   | inclusive) recorded by the collecting  |
   |                  |   |   | implementation.  See Section 6.2.2.    |
   |                  |   |   |                                        |
   | rr-types         | X | A | Array of RR TYPEs [rrtypes] (unsigned  |
   |                  |   |   | integers, each in the range 0 to 65535 |
   |                  |   |   | inclusive) recorded by the collecting  |
   |                  |   |   | implementation.  See Section 6.2.2.    |
   |                  |   |   |                                        |
   | storage-flags    |   | U | Bit flags indicating attributes of     |
   |                  |   |   | stored data.                           |
   |                  |   |   | Bit 0.  1 if the data has been         |
   |                  |   |   | anonymized.                            |
   |                  |   |   | Bit 1.  1 if the data is sampled data. |
   |                  |   |   | Bit 2.  1 if the names have been       |
   |                  |   |   | normalized (converted to uniform       |
   |                  |   |   | case).                                 |
   |                  |   |   |                                        |
   | client-address   |   | U | IPv4 client address prefix length, in  |
   | -prefix-ipv4     |   |   | the range 1 to 32 inclusive.  If       |
   |                  |   |   | specified, only the address prefix     |
   |                  |   |   | bits are stored.                       |
        
   |                  |   |   |                                        |
   | client-address   |   | U | IPv6 client address prefix length, in  |
   | -prefix-ipv6     |   |   | the range 1 to 128 inclusive.  If      |
   |                  |   |   | specified, only the address prefix     |
   |                  |   |   | bits are stored.                       |
   |                  |   |   |                                        |
   | server-address   |   | U | IPv4 server address prefix length, in  |
   | -prefix-ipv4     |   |   | the range 1 to 32 inclusive.  If       |
   |                  |   |   | specified, only the address prefix     |
   |                  |   |   | bits are stored.                       |
   |                  |   |   |                                        |
   | server-address   |   | U | IPv6 server address prefix length, in  |
   | -prefix-ipv6     |   |   | the range 1 to 128 inclusive.  If      |
   |                  |   |   | specified, only the address prefix     |
   |                  |   |   | bits are stored.                       |
   |                  |   |   |                                        |
   | sampling-method  |   | T | Information on the sampling method     |
   |                  |   |   | used.  See Section 6.2.3.              |
   |                  |   |   |                                        |
   | anonymization    |   | T | Information on the anonymization       |
   | -method          |   |   | method used.  See Section 6.2.3.       |
   +------------------+---+---+----------------------------------------+
        
   |                  |   |   |                                        |
   | client-address   |   | U | IPv6 client address prefix length, in  |
   | -prefix-ipv6     |   |   | the range 1 to 128 inclusive.  If      |
   |                  |   |   | specified, only the address prefix     |
   |                  |   |   | bits are stored.                       |
   |                  |   |   |                                        |
   | server-address   |   | U | IPv4 server address prefix length, in  |
   | -prefix-ipv4     |   |   | the range 1 to 32 inclusive.  If       |
   |                  |   |   | specified, only the address prefix     |
   |                  |   |   | bits are stored.                       |
   |                  |   |   |                                        |
   | server-address   |   | U | IPv6 server address prefix length, in  |
   | -prefix-ipv6     |   |   | the range 1 to 128 inclusive.  If      |
   |                  |   |   | specified, only the address prefix     |
   |                  |   |   | bits are stored.                       |
   |                  |   |   |                                        |
   | sampling-method  |   | T | Information on the sampling method     |
   |                  |   |   | used.  See Section 6.2.3.              |
   |                  |   |   |                                        |
   | anonymization    |   | T | Information on the anonymization       |
   | -method          |   |   | method used.  See Section 6.2.3.       |
   +------------------+---+---+----------------------------------------+
        
7.3.1.1.1.1. "StorageHints"
7.3.1.1.1.1. “存储提示”

An indicator of which fields the collecting implementation omits in the maps with optional fields. Note that hints have a top-down precedence. In other words, where a map contains another map, the hint on the containing map overrides any hints in the contained map and the contained map is omitted. A map containing the following:

在带有可选字段的映射中,收集实现忽略哪些字段的指示符。请注意,提示具有自上而下的优先级。换句话说,当一个映射包含另一个映射时,包含映射上的提示将覆盖包含映射中的任何提示,并且忽略包含映射。包含以下内容的地图:

   +------------------+---+---+----------------------------------------+
   | Field            | M | T | Description                            |
   +------------------+---+---+----------------------------------------+
   | query-response   | X | U | Hints indicating which "QueryResponse" |
   | -hints           |   |   | fields are omitted; see Section        |
   |                  |   |   | 7.3.2.4.  If a bit is unset, the field |
   |                  |   |   | is omitted from the capture.           |
   |                  |   |   | Bit 0.  time-offset                    |
   |                  |   |   | Bit 1.  client-address-index           |
   |                  |   |   | Bit 2.  client-port                    |
   |                  |   |   | Bit 3.  transaction-id                 |
   |                  |   |   | Bit 4.  qr-signature-index             |
   |                  |   |   | Bit 5.  client-hoplimit                |
   |                  |   |   | Bit 6.  response-delay                 |
   |                  |   |   | Bit 7.  query-name-index               |
   |                  |   |   | Bit 8.  query-size                     |
   |                  |   |   | Bit 9.  response-size                  |
        
   +------------------+---+---+----------------------------------------+
   | Field            | M | T | Description                            |
   +------------------+---+---+----------------------------------------+
   | query-response   | X | U | Hints indicating which "QueryResponse" |
   | -hints           |   |   | fields are omitted; see Section        |
   |                  |   |   | 7.3.2.4.  If a bit is unset, the field |
   |                  |   |   | is omitted from the capture.           |
   |                  |   |   | Bit 0.  time-offset                    |
   |                  |   |   | Bit 1.  client-address-index           |
   |                  |   |   | Bit 2.  client-port                    |
   |                  |   |   | Bit 3.  transaction-id                 |
   |                  |   |   | Bit 4.  qr-signature-index             |
   |                  |   |   | Bit 5.  client-hoplimit                |
   |                  |   |   | Bit 6.  response-delay                 |
   |                  |   |   | Bit 7.  query-name-index               |
   |                  |   |   | Bit 8.  query-size                     |
   |                  |   |   | Bit 9.  response-size                  |
        
   |                  |   |   | Bit 10.  response-processing-data      |
   |                  |   |   | Bit 11.  query-question-sections       |
   |                  |   |   | Bit 12.  query-answer-sections         |
   |                  |   |   | Bit 13.  query-authority-sections      |
   |                  |   |   | Bit 14.  query-additional-sections     |
   |                  |   |   | Bit 15.  response-answer-sections      |
   |                  |   |   | Bit 16.  response-authority-sections   |
   |                  |   |   | Bit 17.  response-additional-sections  |
   |                  |   |   |                                        |
   | query-response   | X | U | Hints indicating which                 |
   | -signature-hints |   |   | "QueryResponseSignature" fields are    |
   |                  |   |   | omitted; see Section 7.3.2.3.2.  If a  |
   |                  |   |   | bit is unset, the field is omitted     |
   |                  |   |   | from the capture.                      |
   |                  |   |   | Bit 0.  server-address-index           |
   |                  |   |   | Bit 1.  server-port                    |
   |                  |   |   | Bit 2.  qr-transport-flags             |
   |                  |   |   | Bit 3.  qr-type                        |
   |                  |   |   | Bit 4.  qr-sig-flags                   |
   |                  |   |   | Bit 5.  query-opcode                   |
   |                  |   |   | Bit 6.  qr-dns-flags                   |
   |                  |   |   | Bit 7.  query-rcode                    |
   |                  |   |   | Bit 8.  query-classtype-index          |
   |                  |   |   | Bit 9.  query-qdcount                  |
   |                  |   |   | Bit 10.  query-ancount                 |
   |                  |   |   | Bit 11.  query-nscount                 |
   |                  |   |   | Bit 12.  query-arcount                 |
   |                  |   |   | Bit 13.  query-edns-version            |
   |                  |   |   | Bit 14.  query-udp-size                |
   |                  |   |   | Bit 15.  query-opt-rdata-index         |
   |                  |   |   | Bit 16.  response-rcode                |
   |                  |   |   |                                        |
   | rr-hints         | X | U | Hints indicating which optional "RR"   |
   |                  |   |   | fields are omitted; see Section        |
   |                  |   |   | 7.3.2.3.4.  If a bit is unset, the     |
   |                  |   |   | field is omitted from the capture.     |
   |                  |   |   | Bit 0.  ttl                            |
   |                  |   |   | Bit 1.  rdata-index                    |
   | other-data-hints | X | U | Hints indicating which other datatypes |
   |                  |   |   | are omitted.  If a bit is unset, the   |
   |                  |   |   | datatype is omitted from the capture.  |
   |                  |   |   | Bit 0.  malformed-messages             |
   |                  |   |   | Bit 1.  address-event-counts           |
   +------------------+---+---+----------------------------------------+
        
   |                  |   |   | Bit 10.  response-processing-data      |
   |                  |   |   | Bit 11.  query-question-sections       |
   |                  |   |   | Bit 12.  query-answer-sections         |
   |                  |   |   | Bit 13.  query-authority-sections      |
   |                  |   |   | Bit 14.  query-additional-sections     |
   |                  |   |   | Bit 15.  response-answer-sections      |
   |                  |   |   | Bit 16.  response-authority-sections   |
   |                  |   |   | Bit 17.  response-additional-sections  |
   |                  |   |   |                                        |
   | query-response   | X | U | Hints indicating which                 |
   | -signature-hints |   |   | "QueryResponseSignature" fields are    |
   |                  |   |   | omitted; see Section 7.3.2.3.2.  If a  |
   |                  |   |   | bit is unset, the field is omitted     |
   |                  |   |   | from the capture.                      |
   |                  |   |   | Bit 0.  server-address-index           |
   |                  |   |   | Bit 1.  server-port                    |
   |                  |   |   | Bit 2.  qr-transport-flags             |
   |                  |   |   | Bit 3.  qr-type                        |
   |                  |   |   | Bit 4.  qr-sig-flags                   |
   |                  |   |   | Bit 5.  query-opcode                   |
   |                  |   |   | Bit 6.  qr-dns-flags                   |
   |                  |   |   | Bit 7.  query-rcode                    |
   |                  |   |   | Bit 8.  query-classtype-index          |
   |                  |   |   | Bit 9.  query-qdcount                  |
   |                  |   |   | Bit 10.  query-ancount                 |
   |                  |   |   | Bit 11.  query-nscount                 |
   |                  |   |   | Bit 12.  query-arcount                 |
   |                  |   |   | Bit 13.  query-edns-version            |
   |                  |   |   | Bit 14.  query-udp-size                |
   |                  |   |   | Bit 15.  query-opt-rdata-index         |
   |                  |   |   | Bit 16.  response-rcode                |
   |                  |   |   |                                        |
   | rr-hints         | X | U | Hints indicating which optional "RR"   |
   |                  |   |   | fields are omitted; see Section        |
   |                  |   |   | 7.3.2.3.4.  If a bit is unset, the     |
   |                  |   |   | field is omitted from the capture.     |
   |                  |   |   | Bit 0.  ttl                            |
   |                  |   |   | Bit 1.  rdata-index                    |
   | other-data-hints | X | U | Hints indicating which other datatypes |
   |                  |   |   | are omitted.  If a bit is unset, the   |
   |                  |   |   | datatype is omitted from the capture.  |
   |                  |   |   | Bit 0.  malformed-messages             |
   |                  |   |   | Bit 1.  address-event-counts           |
   +------------------+---+---+----------------------------------------+
        
7.3.1.1.2. "CollectionParameters"
7.3.1.1.2. “收集参数”

Parameters providing information regarding how data in the file was collected (applicable for some, but not all, collection environments). The values are informational only and serve as metadata to downstream analyzers as to the configuration of a collecting implementation. They can provide context when interpreting what data is present/absent from the capture but cannot necessarily be validated against the data captured.

提供有关如何收集文件中数据的信息的参数(适用于某些收集环境,但不适用于所有收集环境)。这些值仅供参考,并作为下游分析器关于收集实现配置的元数据。它们可以在解释捕获中存在/不存在的数据时提供上下文,但不一定能够根据捕获的数据进行验证。

These parameters have no default. If they do not appear, nothing can be inferred about their value.

这些参数没有默认值。如果它们不出现,则无法推断其值。

A map containing the following items:

包含以下项目的地图:

   +------------------+---+---+----------------------------------------+
   | Field            | M | T | Description                            |
   +------------------+---+---+----------------------------------------+
   | query-timeout    |   | U | To be matched with a Query, a Response |
   |                  |   |   | must arrive within this number of      |
   |                  |   |   | milliseconds.                          |
   |                  |   |   |                                        |
   | skew-timeout     |   | U | The network stack may report a         |
   |                  |   |   | Response before the corresponding      |
   |                  |   |   | Query.  A Response is not considered   |
   |                  |   |   | to be missing a Query until after this |
   |                  |   |   | many microseconds.                     |
   |                  |   |   |                                        |
   | snaplen          |   | U | Collect up to this many bytes per      |
   |                  |   |   | packet.                                |
   |                  |   |   |                                        |
   | promisc          |   | B | "true" if promiscuous mode             |
   |                  |   |   | [pcap-options] was enabled on the      |
   |                  |   |   | interface, "false" otherwise.          |
   |                  |   |   |                                        |
   | interfaces       |   | A | Array of identifiers (of type text     |
   |                  |   |   | string) of the interfaces used for     |
   |                  |   |   | collection.                            |
   |                  |   |   |                                        |
   | server-addresses |   | A | Array of server collection IP          |
   |                  |   |   | addresses (of type byte string).       |
   |                  |   |   | Metadata for downstream analyzers;     |
   |                  |   |   | does not affect collection.            |
   |                  |   |   |                                        |
        
   +------------------+---+---+----------------------------------------+
   | Field            | M | T | Description                            |
   +------------------+---+---+----------------------------------------+
   | query-timeout    |   | U | To be matched with a Query, a Response |
   |                  |   |   | must arrive within this number of      |
   |                  |   |   | milliseconds.                          |
   |                  |   |   |                                        |
   | skew-timeout     |   | U | The network stack may report a         |
   |                  |   |   | Response before the corresponding      |
   |                  |   |   | Query.  A Response is not considered   |
   |                  |   |   | to be missing a Query until after this |
   |                  |   |   | many microseconds.                     |
   |                  |   |   |                                        |
   | snaplen          |   | U | Collect up to this many bytes per      |
   |                  |   |   | packet.                                |
   |                  |   |   |                                        |
   | promisc          |   | B | "true" if promiscuous mode             |
   |                  |   |   | [pcap-options] was enabled on the      |
   |                  |   |   | interface, "false" otherwise.          |
   |                  |   |   |                                        |
   | interfaces       |   | A | Array of identifiers (of type text     |
   |                  |   |   | string) of the interfaces used for     |
   |                  |   |   | collection.                            |
   |                  |   |   |                                        |
   | server-addresses |   | A | Array of server collection IP          |
   |                  |   |   | addresses (of type byte string).       |
   |                  |   |   | Metadata for downstream analyzers;     |
   |                  |   |   | does not affect collection.            |
   |                  |   |   |                                        |
        
   | vlan-ids         |   | A | Array of identifiers (of type unsigned |
   |                  |   |   | integer, each in the range 1 to 4094   |
   |                  |   |   | inclusive) of VLANs [IEEE802.1Q]       |
   |                  |   |   | selected for collection.  VLAN IDs are |
   |                  |   |   | unique only within an administrative   |
   |                  |   |   | domain.                                |
   |                  |   |   |                                        |
   | filter           |   | T | Filter for input, in "tcpdump"         |
   |                  |   |   | [pcap-filter] style.                   |
   |                  |   |   |                                        |
   | generator-id     |   | T | Implementation-specific human-readable |
   |                  |   |   | string identifying the collection      |
   |                  |   |   | method.                                |
   |                  |   |   |                                        |
   | host-id          |   | T | String identifying the collecting      |
   |                  |   |   | host.                                  |
   +------------------+---+---+----------------------------------------+
        
   | vlan-ids         |   | A | Array of identifiers (of type unsigned |
   |                  |   |   | integer, each in the range 1 to 4094   |
   |                  |   |   | inclusive) of VLANs [IEEE802.1Q]       |
   |                  |   |   | selected for collection.  VLAN IDs are |
   |                  |   |   | unique only within an administrative   |
   |                  |   |   | domain.                                |
   |                  |   |   |                                        |
   | filter           |   | T | Filter for input, in "tcpdump"         |
   |                  |   |   | [pcap-filter] style.                   |
   |                  |   |   |                                        |
   | generator-id     |   | T | Implementation-specific human-readable |
   |                  |   |   | string identifying the collection      |
   |                  |   |   | method.                                |
   |                  |   |   |                                        |
   | host-id          |   | T | String identifying the collecting      |
   |                  |   |   | host.                                  |
   +------------------+---+---+----------------------------------------+
        
7.3.2. "Block"
7.3.2. “块”

Container for data with common collection and storage parameters. A map containing the following:

具有公共收集和存储参数的数据容器。包含以下内容的地图:

   +--------------------+---+---+--------------------------------------+
   | Field              | M | T | Description                          |
   +--------------------+---+---+--------------------------------------+
   | block-preamble     | X | M | Overall information for the "Block"  |
   |                    |   |   | item.  Map of type "BlockPreamble";  |
   |                    |   |   | see Section 7.3.2.1.                 |
   |                    |   |   |                                      |
   | block-statistics   |   | M | Statistics about the "Block" item.   |
   |                    |   |   | Map of type "BlockStatistics"; see   |
   |                    |   |   | Section 7.3.2.2.                     |
   |                    |   |   |                                      |
   | block-tables       |   | M | The arrays containing data           |
   |                    |   |   | referenced by individual             |
   |                    |   |   | "QueryResponse" or                   |
   |                    |   |   | "MalformedMessage" items.  Map of    |
   |                    |   |   | type "BlockTables"; see Section      |
   |                    |   |   | 7.3.2.3.                             |
   |                    |   |   |                                      |
   | query-responses    |   | A | Details of individual C-DNS Q/R data |
   |                    |   |   | items.