Linux tcpdump Command Detailed, BPF filter Rule reference __linux

Brief Introduction

The simplest way to define tcpdump is: Dump the traffic on a network, the packet analysis tool that intercepts packets on the network according to the user's definition. Tcpdump can intercept the "head" of packets transmitted in the network and provide analysis. It supports filtering for network layers, protocols, hosts, networks, or ports, and provides logical statements such as and, or, not to help you get rid of useless information.

Practical Command Instances

default startup

Tcpdump

Under normal circumstances, direct start tcpdump will monitor all packets flowing through the first network interface.

monitoring packets for a specified network interface

Tcpdump-i eth1

If you do not specify a network adapter, the default tcpdump only monitors the first network interface, typically eth0, and the following examples do not specify a network interface.

monitoring packets for a specified host

Print all packets entering or leaving the sundown.

Tcpdump Host Sundown

You can also specify IP, such as intercepting all packets received and emitted by all 210.27.48.1 hosts

Print a packet of Helios and hot or communication with Ace

Tcpdump host Helios and \ (hot or ACE \)

Interception of communication between host 210.27.48.1 and host 210.27.48.2 or 210.27.48.3

Print an IP packet that communicates between the ACE and any other host, but does not include packets between the Helios.

Tcpdump IP host ace and not Helios

If you want to get the host 210.27.48.1 IP packets that communicate with all hosts except the host 210.27.48.2, use the command:

Tcpdump IP host 210.27.48.1 and! 210.27.48.2

Intercepts all data sent by host hostname

Tcpdump-i eth0 SRC host hostname

Monitor all packets sent to host hostname

Tcpdump-i eth0 DST host hostname

 

monitor packets for the specified host and port

If you want to obtain a telnet package that the host 210.27.48.1 receives or emits, use the following command

Tcpdump TCP Port Host 210.27.48.1

Monitoring the UDP 123 port on this machine 123 is the service port for NTP

monitoring packets for a specified network

Print all communication packets between the local host and the host on the Berkeley Network (Nt:ucb-ether, which is understood as the network address of the ' Berkeley Network '), the most original meaning of which is to print all packets with a network address of Ucb-ether

tcpdump Net Ucb-ether

Print all FTP packets through the Gateway Snup (note that the expressions are enclosed in quotes, which prevents the shell from parsing the parentheses in them)

Tcpdump ' Gateway Snup and (port ftp or Ftp-data) '

Print IP packets for all source or destination addresses that are local hosts

(If the local network is connected to another network through a gateway, the other network does not count as a local network.) (NT: This translation twists and turns, need to be supplemented). LocalNet actually use to replace the cost of the network name)

tcpdump IP and not net LocalNet

monitoring packets for a specified protocol

Prints the start and end packets in a TCP session, and the source or destination of the packet is not a host on the local network. (Nt:localnet, when actually used to replace the cost of the network name))

Tcpdump ' tcp[tcpflags] & (Tcp-syn|tcp-fin)!= 0 and not SRC and DST net localnet '

Print all source or destination ports are 80, Network layer protocol is IPV4, and contains data, not syn,fin and ack-only packets without data. (IPv6 version of the expression can do exercises)

Tcpdump ' TCP port and ((Ip[2:2)-((IP[0]&0XF) <<2))-((tcp[12]&0xf0) >>2))!= 0) '

(NT: Understandably, Ip[2:2] represents the length of an entire IP packet, (IP[0]&0XF) <<2) that represents the length of the packet header (IP[0]&0XF represents the IHL domain in the package, and the unit of this field is 32bit, to convert

The number of bytes needs to be multiplied by 4, that is, 2 to the left. (TCP[12]&0XF0) >>4 represents the length of the TCP header, the unit of this field is also 32bit, converted to bits ((tcp[12]&0xf0) >> 4) << 2,
That is ((tcp[12]&0xf0) >>2). ((Ip[2:2]-((IP[0]&0XF) <<2))-((tcp[12]&0xf0) >>2))!= 0 says: The length of the entire IP packet minus the length of the IP header, minus
The length of the TCP header is not 0, this means that there is indeed data in the IP packet. For the IPv6 version, you only need to consider the difference between ' Payload length ' and ' tcp head length ' in the IPv6 header, and the expression ' ip[' must be replaced with ' ip6['.)

The print length exceeds 576 bytes, and the gateway address is Snup IP packet

Tcpdump ' Gateway Snup and Ip[2:2] > 576 '

Print all IP-layer broadcast or multicast packets, but not a broadcast or multicast datagram on the physical Ethernet layer

Tcpdump ' ether[0] & 1 = 0 and ip[16] >= 224 '

Print ICMP packets other than ' echo request ' or ' echo Reply ' type (for example, you can use this expression when you need to print all of the data packets that are not generated by the ping program).
(NT: ' Echo reuqest ' and ' echo Reply ', two types of ICMP packets are usually generated by the ping program))

Tcpdump ' Icmp[icmptype]!= Icmp-echo and Icmp[icmptype]!= icmp-echoreply '

 

tcpdump and Wireshark

Wireshark (formerly Ethereal) is a very simple and easy to use grab tool under Windows. But under Linux it's hard to find a handy graphical grab kit.
Fortunately there are tcpdump. We can use the perfect combination of Tcpdump + Wireshark: Grab the package in Linux and analyze the package in Windows.

Tcpdump tcp-i eth1-t-S 0-c and DST Port! and src net 192.168.1.0/24-w./target.cap

(1) tcp:ip icmp arp rarp and TCP, UDP, ICMP these options, etc., are placed in the position of the first parameter to filter the type of datagram
(2)-I eth1: Only grab packets that pass through the interface eth1
(3)-T: Do not show time stamp
(4)-S 0: The default crawl length is 68 bytes when fetching packets. Plus-S 0 to capture the full packet
(5)-C 100: Crawl only 100 packets
(6) DST Port! 22: Do not crawl the destination port is 22 packets
(7) SRC net 192.168.1.0/24: The source network address of the packet is 192.168.1.0/24
(8)-W./target.cap: Save as cap file for easy ethereal (i.e. Wireshark) analysis

 

using Tcpdump to crawl HTTP packets

tcpdump  -xvvennss 0-i eth0 tcp[20:2]=0x4745 or tcp[20:2]=0x4854

0X4745 is the first two letters "GE" for "get" and 0x4854 is the first two letter "HT" of "HTTP".

Tcpdump does not completely decode the intercepted data, and most of the content in the packet is printed directly in hexadecimal form. Obviously this is not conducive to the analysis of network failures, the usual solution is to use the tcpdump with the-w parameter to intercept the data and save to the file, and then use other programs (such as Wireshark) for decoding analysis. Of course, filter rules should also be defined to avoid the capture of packets filling the entire hard disk.

Output information meaning

First of all, we note that basically tcpdump the total output format is: System time source host. port > Target host. Port packet parameters

The output format of the tcpdump is related to the Protocol. The following is a brief description of most commonly used formats and related examples. Link Layer Header

For FDDI networks, '-e ' causes tcpdump to print out the ' Frame control ' field, source and destination address, and the length of the package for the specified packet. (Frame control field
Controls resolution of other domains in the package). Generic packages (such as those that are IP datagrams) are packets with ' async ' (asynchronous flags), and have a priority of 0 to 7 values;
For example, ' async4 ' means that the packet is an asynchronous packet and has a priority level of 4. It is generally assumed that these packages will contain a LLC package (logical Link control pack); At this point, if the package
is not an ISO datagram or so-called SNAP package, its LLC head will be printed (NT: It should refer to the Baotou of the LLC package contained in this package).

For the Token Ring network (token loop network), '-e ' enables tcpdump to print out the ' Frame control ' and ' access control ' fields for the specified packet, as well as the source and destination addresses,
Plus the length of the package. Similar to FDDI networks, this packet typically contains LLC packets. Regardless of whether the ' E ' option is available. For ' source-routed ' type packets on this network (NT:
Translation is: The source address is tracked packets, the specific meaning is unknown, need to be supplemented, the packet's source routing information will always be printed.

For a 802.11 network (WLAN, or wireless local area network), '-e ' enables tcpdump to print out the ' frame control ' of the specified packet.
All addresses included in the header, and the length of the package. Similar to FDDI networks, this packet typically contains LLC packets.

(Note: The following description assumes that you are familiar with the slip compression algorithm (Nt:slip for the serial line Internet Protocol.), this algorithm can
RFC-1144 to find the relevant clues.

For a SLIP network (Nt:slip links, it is understood to be a network, a connection established over a serial line, and a simple connection can be viewed as a network).
The ' direction indicator ' (' directional indicator ') of the Packet ("I" is represented, "O" is indicated), and the type and the compressed information will be printed. The package type will be printed first.

Types are divided into IP, utcp and CTCP (NT: Unknown, need to be supplemented). For IP packets, the connection information will not be printed (the connection information for the IP packet may be useless or undefined on the Nt:slip connection).
Reconfirm). For TCP packets, the connection identity is printed immediately after the type representation. If the packet is compressed, its encoded head will be printed.
For special compression packs, the following will appear:
*s+n or *sa+n, where n represents the number of additions or decreases in the packet (sequence number or (sequence number and answer number)) (NT | Rt:s,sa is awkward and needs to be translated).
For non-special compression packs, 0 or more ' changes ' will be printed. The ' Change ' is printed in the following format:
' Flag ' +/-/=n packet data length of the compressed head.
Where ' flags ' can take the following values:
U (represents the emergency pointer), W (refers to the buffer window), A (answer), S (serial number), I (package ID), and the increment expression ' =n ' means to be given a new value,/+ to indicate an increase or decrease.

For example, the following shows the printing of an outgoing compressed TCP packet, which implies a connection identifier (connection identifier); The answer number increased by 6,
The order number increased by 49, and the packet ID number increased by 6; Packet data length is 3 bytes (octect) with a compressed head of 6 bytes. (NT: So it seems that this should not be a special compressed packet).

Arp/rarp Data Packets

Tcpdump the output information for the ARP/RARP package contains the request type and the corresponding parameter for the request. The display format is simple and straightforward. The following is the ' Rlogin ' from the host RTSG to the host Csam
Example of a packet at the beginning of the process (telnet):
ARP Who-has csam tell RTSG
ARP reply Csam is-at Csam
The first line says: RTSG sent an ARP packet (NT: Send to full network segment, ARP packet) to ask for Csam Ethernet address
Csam (NT: As can be seen from below, Csam) responds with her own Ethernet address (in this case, the Ethernet address is identified with an uppercase name, and the Internet
The address (that is, the IP address) is identified by all lowercase names.

If you use Tcpdump-n, you can see the Ethernet and the IP address clearly instead of the name ID:
ARP Who-has 128.3.254.6 tell 128.3.254.68
ARP reply 128.3.254.6 is-at 02:07:01:00:01:c4

If we use TCPDUMP-E, we can see clearly that the first packet is broadcast all over the net, and the second packet is point-to-point:
RTSG broadcast 0806 64:arp Who-has Csam tell RTSG
Csam RTSG 0806 64:arp reply Csam is-at Csam
The first packet indicates that the source Ethernet address of the ARP packet is RTSG, the destination address is a full Ethernet segment, and the value of the Type field is 16-in-0806 (representing the Ether_arp (type identification of the NT:ARP package)).
The total length of the package is 64 bytes. TCP Packets

(Note: The following will assume that you are familiar with the TCP described by RFC-793. If not, the following description and the Tcpdump program may not help you. (NT: Warnings can be ignored,
Just keep looking, unfamiliar place can look back again.

Typically, the display format for TCP packets is as follows: Tcpdump
src > Dst:flags data-seqno ack window urgent options

SRC and DST are the source and destination IP addresses and the corresponding ports. Flags flag by S (SYN), F (FIN), P (PUSH, R (RST),
W (ECN CWT (NT | Rep: unknown, to be supplemented)) or E (Ecn-echo (NT | Rep: unknown, to be added)),
A single '. ' Indicates that there is no flags identity. The sequence number (data-seqno) of the data segment describes a position in the sequence number space of the data in this packet (NT: The entire data is segmented,
Each segment has a sequential number, all of which form a serial number space (refer to the following examples). Ack describes the same connection, the same direction, the next one should receive
The order number of the data fragment (the other person should send). window is the size of the data receive buffers available on the local side (and it is the data that the other person needs to organize according to that size).
URG (urgent) indicates that there are urgent data in the packet. Options describe some of the choices for TCP, which are represented by angle brackets (such as <mss 1024>).

SRC, DST, and flags are the three domains that are always displayed. The display of other domains depends on the information in the TCP protocol header.

This is the beginning of a rlogin application login from TRSG to Csam.
rtsg.1023 > Csam.login:s 768512:768512 (0) win 4096 <mss 1024>
Csam.login > Rtsg.1023:s 947,648:94,764 8 (0) Ack 768513 win 4096 <mss 1024>
rtsg.1023 > Csam.login:. Ack 1 win 4096
rtsg.1023 > Csam.login:p 1:2 (1) Ack 1 win 4096
Csam.login > rtsg.1023:. ACK 2 win 4096
rtsg.1023 > Csam.login:p 2:21 () Ack 1 win 4096
Csam.login > Rtsg.1023:p 1:2 (1) ACK win 4077
Csam.login > Rtsg.1023:p 2:3 (1) ACK win 4077 Urg 1
Csam.login > Rtsg.1023:p 3:4 (1) ACK win 4077 Urg 1
The first line indicates that a packet was sent from TCP port 1023 on the RTSG host to the TCP port login on the CSAM host (NT: The port of the UDP protocol and the end
port of the TCP protocol are two spaces, albeit in a consistent range of values. s indicates that the SYN flag is set. The order number of the package is 768512 and does not contain data. (The Format
is: ' First:last (nbytes) ', meaning ' the sequence number of the data in this package begins with the first until last, excluding last.) and contains a total of nbytes
User data '. ' No response (NT: see below) , the second line is a packet with a piggyback response, the available Accept window is 4096bytes in size, and the maximum acceptable segment size of the request-side (RTSG)
is 1024 bytes (NT: This information is sent as a request to the reply-side Csam for further consultation).

Csam to RTSG back to the same SYN packet, the difference is just one more ' piggy-backed ack ' (NT: The return ACK reply, for the RTSG SYN packet).

RTSG also responds to an ACK packet for the Csam SYN packet. '.' The implication is that no flags are set in this package. Because this answer package does not contain data,
There is also no data segment serial number in the package. Remind! The order number of this ACK packet is only a small integer 1. As explained below: Tcpdump for a session on a TCP connection, print only the
The sequence number of the initial packet, after which the corresponding packet prints only the difference from the initial packet sequence number. The serial number after the initial sequence number can be considered as the current data fragment on the session
The ' relative byte ' position in the data to be transferred (NT: the first position on both sides is 1, the start number of ' relative bytes '). '-S ' will overwrite this feature,
The original sequence number of the packet is printed.

The meaning of line six is: RTSG sends 19 bytes of data to Csam (the byte number is 2 to 20, and the delivery direction is RTSG to Csam). The push flag is set in the package. On line 7th,
Csam shouted that she had received a byte below 21 from the RTSG, but did not include 21 numbered bytes. These bytes are stored in the receive buffer of the CSAM socket, and correspondingly,
The Csam receive Buffer window size is reduced by 19 bytes (NT: You can see the change from the 5th and 7th lines of the win property value). Csam also sent a RTSG to the packet in the 7th line.
Bytes. On lines 8th and 9th, Csam continues to send two packets containing only one byte to the RTSG, and this packet is with a push flag.

If the captured TCP packet (NT: That is, the snapshot here) is too small for the tcpdump to get its header data intact, Tcpdump will try to parse the incomplete head.
And the remaining unresolved parts are shown as ' [|tcp] '. If the head contains false attribute information (such as its length property is actually longer or shorter than the actual length of the head), Tcpdump will
Show ' [Bad opt] '. If the length of the head tells us certain options (NT | RT: In the context of the TCP packet's head, some options for the IP packet are turned back) in this package,
and the real IP (the length of the packet is not enough to accommodate these options, tcpdump will show ' [Bad hdr length] '.

Grab TCP packets with special flags (such as Syn-ack flags, urg-ack flags, etc.).

In the head of TCP, 8 bits (bit) are used as the control bit area, and the value is:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
(NT | RT: It can be inferred from the expression: These 8 bits are combined in the same way and can be turned over again)

Let's assume that we want to monitor the data packets generated during the entire process of establishing a TCP connection. Can recall as follows: TCP uses 3 times handshake protocol to establish a new connection; It shook hands with this three times
The connection order corresponds to the following packets with the corresponding TCP control flags:
1) connection initiator (Nt:caller) packet sending SYN flag
2) the receiver (Nt:recipient) responds with a packet with a SYN and ACK mark
3 The initiator receives a response from the receiving party and then sends a packet with an ACK flag to respond

0 15 31
-----------------------------------------------------------------
| SOURCE Port | Destination Port |
-----------------------------------------------------------------
| Sequence Number |
-----------------------------------------------------------------
| Acknowledgment number |
-----------------------------------------------------------------
| HL | RSVD | c| e| u| a| p| r| s| F| Window Size |
-----------------------------------------------------------------
| TCP Checksum | Urgent pointer |
-----------------------------------------------------------------

A TCP header that typically occupies 20 bytes without the option data (NT | rt:options is interpreted as option data and needs to be translated). The first line contains 0 to 3 numbered bytes,
The second line contains the byte of number 4-7.

If the number starts at 0, the TCP control flag is located at 13 bytes (NT: The left half of the fourth line).

0 7| 15| 23| 31
----------------|---------------|---------------|----------------
| HL | RSVD | c| e| u| a| p| r| s| F| Window Size |
----------------|---------------|---------------|----------------
| | 13th Octet | | |

Let's take a closer look at the byte number 13:

| |
|---------------|
| c| e| u| a| p| r| s| F|
|---------------|
|7 5 3 0|

Here is a bit of control sign we are interested in. From right to left these bits are numbered 0 through 7 sequentially, thus PSH at number 3rd, and the Urg bit at 5th.

Remind yourself that we're just going to get the packet containing the SYN flag. Let's take a look at the header of a package, if the SYN bit is set, exactly
What happened in Byte 13th:

| c| e| u| a| p| r| s| F|
|---------------|
| 0 0 0 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|

In the control segment data, only bit 1 (bit number 1) is placed.

Suppose that the byte numbered 13 is a 8-bit unsigned character and sorted by network byte number (NT: For a byte, the network byte order is equivalent to the host byte order), and the binary value
As shown below:
00000010

and its 10 binary values are:

0*2^7 + 0*2^6 + 0*2^5 + 0*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2^0 = 2 (nt:1 * 2^6 means 1 times 2 6 times, maybe this more
Clear, that is, the original expression of the index 7 6 ... 0 moved to the following to express)

Close to the target, because we already know that if the SYN in the header of the packet is set, the 13th byte in the header is 2 (NT: In the order of the network, that's the big head, the most important byte
In front (in front, that is, the byte actual memory address is relatively small, the most important byte, refers to the mathematical representation of the number of high, such as 356 of 3)).

Expressions as tcpdump can understand the relationship is:
TCP[13] 2

So we can take this relationship as a tcpdump filter, and the goal is to monitor packets that contain only SYN flags:
Tcpdump-i xl0 tcp[13] 2 (nt:xl0 refers to network interface, such as eth0)

This expression says "let the 13th byte of the TCP packet have a value of 2", which is the result we want.

Now let's say we need to grab a packet with a SYN flag and ignore whether it contains other flags. (NT: Just bring SYN is what we want). Let's take a look at when a contains
Syn-ack packets (both Nt:syn and ACK flags), what happens when they arrive:
| c| e| u| a| p| r| s| F|
|---------------|
| 0 0 1 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|

The number 1th and 4th digits of byte 13th are placed, and the binary values are:
00010010

Converting to decimal is:

0*2^7 + 0*2^6 + 0*2^5 + 1*2^4 + 0*2^3 + 0*2^2 + 1*2^1 + 0*2 = (nt:1 * 2^6 = 1 times 2 of 6), maybe this more
Clear, that is, the original expression of the index 7 6 ... 0 moved to the following to express)

Now, you cannot use ' tcp[13] 18 ' as a tcpdump filter expression, because this will result in the selection of only packets containing the SYN-ACK flag, and the rest being discarded.
To remind ourselves, our goal is: As long as the package of SYN flag is set on the line, the other signs we ignore.

In order to achieve our goal, we need to do and manipulate (NT: Logic and) The binary value of byte 13th with the other number to get the value of the SYN bit bit. The goal is: as long as the SYN is set
Yes, so we put her up with the SYN value of number 13th bytes (nt:00000010).

00010010 Syn-ack 00000010 SYN
and 00000010 (We want SYN) and 00000010 (We want SYN)
-------- --------
= 00000010 = 00000010

We can find that the above and operation will give us the same value regardless of whether the packet's ACK or other flags are set, and the 10 binary expression is 2 (2 binary expression is 00000010).
Thus we know that for packets with SYN flags, the result of the following expression is always True (true):

((Value of octet) and (2)) (2) (Nt:value of Octet 13, that is, the value of 13th bytes)

The inspiration followed, and we got the following tcpdump filter expression
Tcpdump-i xl0 ' tcp[13] & 2 2 '

Note that single quotes or backslashes (NT: single quotes here) cannot be omitted, which prevents the shell from interpreting or replacing &.
UDP Packets

The display format for UDP packets can be illustrated by rwho the data packets generated by this particular application:
actinide.who > BROADCAST.WHO:UDP 84

The meaning is: port on the actinide host who sends a UDP packet (Nt:actinide and broadcast to an Internet address) to the port on the broadcast host.
This packet hosts 84 bytes of user data.

Some UDP services can be identified from the source or destination port of the packet, or from the higher level protocol information displayed. For example, Domain Name service requests (DNS request,
In rfc-1034/1035), and sun RPC calls to NFS (Remote Call to NFS server (NT: That is, Sun RPC), with a description of the remote call in RFC-1050).

UDP Name Service Request

(Note: The following description assumes that you have a description of domain Service Protoco (nt: in RFC-103), otherwise you will find that the following description is the heavenly book (nt: Greek heavenly Book,
Don't bother, scare you, then look on the line)

The Name Service request has the following format:
src > Dst:id op? Flags Qtype qclass name (len)
(NT: From the below, the format should be src > dst:id op flags qtype qclass? Name (len))
For example, there is an actual display:
h2opolo.1538 > helios.domain:3+ A? Ucbvax.berkeley.edu. (37)

The host H2opolo queries the ucbvax.berkeley.edu address record (Nt:qtype equals a) to the name server running on the Helios. The ID number for this query itself is ' 3 '. Symbol
' + ' means that the recursive query flag is set (the NT:DNS server can query to higher-level DNS servers for address records not included in this server). This final query request sent over the IP packet
Data length is 37 bytes, which does not include header data for UDP and IP protocols. The OP field is omitted because this query operation is the default (NT | Rt:normal one understanding).
If the OP field is not omitted, it will be displayed between ' 3 ' and ' + '. Similarly, Qclass is also the default, c_in, and thus is not displayed, and if not ignored, she will be shown after ' A '.

An exception check displays additional fields in square brackets: If a query contains a response (NT: It can be understood as a response to a previous request), and the response contains an authoritative or additional record segment,
Ancount, Nscout, Arcount (NT: Specific field meaning to be added) will be shown as ' [Na] ', ' [nn] ', ' [Nau] ', where n represents the appropriate count. If the following in the package
The response bit (e.g. AA bit, RA bit, Rcode bit), or any bit in byte 2 or 3 that ' must be 0 ' (NT: set to 1), ' [B2&3]=x ' will be displayed, where x indicates
The header byte 2 and byte 3 are performed with the value after the operation.

UDP Name Service Answer

The packet to which the name service answers, Tcpdump will have the following display format
src > Dst:id op rcode Flags A/n/au type class data (len)
For example, the specific display is as follows:
Helios.domain > H2opolo.1538:3 3/3/7 A 128.32.137.3 (273)
Helios.domain > H2opolo.1537:2 nxdomain* 0/1/0 (97)

The first line says: Helios responded to H2opolo's 3rd query request with 3 answer records (NT | Rt:answer records), 3 name server records,
and 7 additional records. The first answer record (the first in the Nt:3 answer record) is of type A (NT: address), and its data is Internet address 128.32.137.3.
This response UDP packet contains 273 bytes of data (not including UPD and IP header data). The OP field and the Rcode field are ignored (Nt:op's actual value is query, Rcode, that is,
The actual value of response code is NOERROR), and the fields that are also ignored are class fields (NT | RT: Its value is c_in, which is also the default value of a type record)

The second line says: Helios responded to the 2nd query request sent by H2opolo. In response, Rcode is encoded as a Nxdomain (NT: A domain that does not exist), and no answer is recorded.
But contains a name server record and does not contain authoritative server records (NT | ck: From the above, the authority records here is the corresponding additional
Records). ' * ' indicates that the authoritative server answer flag is set (NT: thus additional records means authority records).
Because there are no answer records, type, class, data fields are ignored.

The Flag field is also available