Created
March 19, 2019 10:52
-
-
Save jelu/46d780709047c9c756dba3c5785e7820 to your computer and use it in GitHub Desktop.
DNSTAP using CBOR
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
; Taken from https://github.com/dnstap/dnstap.pb | |
; Changes: | |
; - rename Message.Type to message-type/MessageType since it collides with Dnstap.Type | |
Dnstap = { | |
; DNS server identity. | |
; If enabled, this is the identity string of the DNS server which generated | |
; this message. Typically this would be the same string as returned by an | |
; "NSID" (RFC 5001) query. | |
? identity => bstr, | |
; DNS server version. | |
; If enabled, this is the version string of the DNS server which generated | |
; this message. Typically this would be the same string as returned by a | |
; "version.bind" query. | |
? version => bstr, | |
; Extra data for this payload. | |
; This field can be used for adding an arbitrary byte-string annotation to | |
; the payload. No encoding or interpretation is applied or enforced. | |
? extra => bstr, | |
; Identifies which field below is filled in. | |
type => Type, | |
; One of the following will be filled in. | |
? message => Message, | |
} | |
identity = 1 | |
version = 2 | |
extra = 3 | |
type = 15 | |
message = 14 | |
Type = &( | |
MESSAGE : 1, | |
) | |
; SocketFamily: the network protocol family of a socket. This specifies how | |
; to interpret "network address" fields. | |
SocketFamily = &( | |
INET : 1, ; IPv4 (RFC 791) | |
INET6 : 2, ; IPv6 (RFC 2460) | |
) | |
; SocketProtocol: the transport protocol of a socket. This specifies how to | |
; interpret "transport port" fields. | |
SocketProtocol = &( | |
UDP : 1, ; User Datagram Protocol (RFC 768) | |
TCP : 2, ; Transmission Control Protocol (RFC 793) | |
) | |
; There are eight types of "Message" defined that correspond to the | |
; four arrows in the following diagram, slightly modified from RFC 1035 | |
; section 2: | |
; | |
; +---------+ +----------+ +--------+ | |
; | | query | | query | | | |
; | Stub |-SQ--------CQ->| Recursive|-RQ----AQ->| Auth. | | |
; | Resolver| | Server | | Name | | |
; | |<-SR--------CR-| |<-RR----AR-| Server | | |
; +---------+ response | | response | | | |
; +----------+ +--------+ | |
; | |
; Each arrow has two Type values each, one for each "end" of each arrow, | |
; because these are considered to be distinct events. Each end of each | |
; arrow on the diagram above has been marked with a two-letter Type | |
; mnemonic. Clockwise from upper left, these mnemonic values are: | |
; | |
; SQ: STUB-QUERY | |
; CQ: CLIENT-QUERY | |
; RQ: RESOLVER-QUERY | |
; AQ: AUTH-QUERY | |
; AR: AUTH-RESPONSE | |
; RR: RESOLVER-RESPONSE | |
; CR: CLIENT-RESPONSE | |
; SR: STUB-RESPONSE | |
; | |
; Two additional types of "Message" have been defined for the | |
; "forwarding" case where an upstream DNS server is responsible for | |
; further recursion. These are not shown on the diagram above, but have | |
; the following mnemonic values: | |
; | |
; FQ: FORWARDER-QUERY | |
; FR: FORWARDER-RESPONSE | |
; | |
; The "Message" Type values are defined below. | |
MessageType = &( | |
; AUTH-QUERY is a DNS query message received from a resolver by an | |
; authoritative name server, from the perspective of the authorative | |
; name server. | |
AUTH-QUERY : 1, | |
; AUTH-RESPONSE is a DNS response message sent from an authoritative | |
; name server to a resolver, from the perspective of the authoritative | |
; name server. | |
AUTH-RESPONSE : 2, | |
; RESOLVER-QUERY is a DNS query message sent from a resolver to an | |
; authoritative name server, from the perspective of the resolver. | |
; Resolvers typically clear the RD (recursion desired) bit when | |
; sending queries. | |
RESOLVER-QUERY : 3, | |
; RESOLVER-RESPONSE is a DNS response message received from an | |
; authoritative name server by a resolver, from the perspective of | |
; the resolver. | |
RESOLVER-RESPONSE : 4, | |
; CLIENT-QUERY is a DNS query message sent from a client to a DNS | |
; server which is expected to perform further recursion, from the | |
; perspective of the DNS server. The client may be a stub resolver or | |
; forwarder or some other type of software which typically sets the RD | |
; (recursion desired) bit when querying the DNS server. The DNS server | |
; may be a simple forwarding proxy or it may be a full recursive | |
; resolver. | |
CLIENT-QUERY : 5, | |
; CLIENT-RESPONSE is a DNS response message sent from a DNS server to | |
; a client, from the perspective of the DNS server. The DNS server | |
; typically sets the RA (recursion available) bit when responding. | |
CLIENT-RESPONSE : 6, | |
; FORWARDER-QUERY is a DNS query message sent from a downstream DNS | |
; server to an upstream DNS server which is expected to perform | |
; further recursion, from the perspective of the downstream DNS | |
; server. | |
FORWARDER-QUERY : 7, | |
; FORWARDER-RESPONSE is a DNS response message sent from an upstream | |
; DNS server performing recursion to a downstream DNS server, from the | |
; perspective of the downstream DNS server. | |
FORWARDER-RESPONSE : 8, | |
; STUB-QUERY is a DNS query message sent from a stub resolver to a DNS | |
; server, from the perspective of the stub resolver. | |
STUB-QUERY : 9, | |
; STUB-RESPONSE is a DNS response message sent from a DNS server to a | |
; stub resolver, from the perspective of the stub resolver. | |
STUB-RESPONSE : 10, | |
; TOOL-QUERY is a DNS query message sent from a DNS software tool to a | |
; DNS server, from the perspective of the tool. | |
TOOL-QUERY : 11, | |
; TOOL-RESPONSE is a DNS response message received by a DNS software | |
; tool from a DNS server, from the perspective of the tool. | |
TOOL-RESPONSE : 12, | |
) | |
; Message: a wire-format (RFC 1035 section 4) DNS message and associated | |
; metadata. Applications generating "Message" payloads should follow | |
; certain requirements based on the MessageType, see below. | |
Message = { | |
; One of the Type values described above. | |
message-type => MessageType, | |
; One of the SocketFamily values described above. | |
? socket-family => SocketFamily, | |
; One of the SocketProtocol values described above. | |
? socket-protocol => SocketProtocol, | |
; The network address of the message initiator. | |
; For SocketFamily INET, this field is 4 octets (IPv4 address). | |
; For SocketFamily INET6, this field is 16 octets (IPv6 address). | |
? query-address => bstr, | |
; The network address of the message responder. | |
; For SocketFamily INET, this field is 4 octets (IPv4 address). | |
; For SocketFamily INET6, this field is 16 octets (IPv6 address). | |
? response-address => bstr, | |
; The transport port of the message initiator. | |
; This is a 16-bit UDP or TCP port number, depending on SocketProtocol. | |
? query-port => uint, | |
; The transport port of the message responder. | |
; This is a 16-bit UDP or TCP port number, depending on SocketProtocol. | |
? response-port => uint, | |
; The time at which the DNS query message was sent or received, depending | |
; on whether this is an AUTH-QUERY, RESOLVER-QUERY, or CLIENT-QUERY. | |
; This is the number of seconds since the UNIX epoch. | |
? query-time-sec => uint, | |
; The time at which the DNS query message was sent or received. | |
; This is the seconds fraction, expressed as a count of nanoseconds. | |
? query-time-nsec => uint, | |
; The initiator's original wire-format DNS query message, verbatim. | |
? query-message => bstr, | |
; The "zone" or "bailiwick" pertaining to the DNS query message. | |
; This is a wire-format DNS domain name. | |
? query-zone => bstr, | |
; The time at which the DNS response message was sent or received, | |
; depending on whether this is an AUTH-RESPONSE, RESOLVER-RESPONSE, or | |
; CLIENT-RESPONSE. | |
; This is the number of seconds since the UNIX epoch. | |
? response-time-sec => uint, | |
; The time at which the DNS response message was sent or received. | |
; This is the seconds fraction, expressed as a count of nanoseconds. | |
? response-time-nsec => uint, | |
; The responder's original wire-format DNS response message, verbatim. | |
? response-message => bstr, | |
} | |
message-type = 1 | |
socket-family = 2 | |
socket-protocol = 3 | |
query-address = 4 | |
response-address = 5 | |
query-port = 6 | |
response-port = 7 | |
query-time-sec = 8 | |
query-time-nsec = 9 | |
query-message = 10 | |
query-zone = 11 | |
response-time-sec = 12 | |
response-time-nsec = 13 | |
response-message = 14 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment