[VirtualBox 5.1.30 r118389 (Qt5.6.3), HOST: MacBook Pro High Sierra 10.13.1, GUEST: Ubuntu 14.04 LTS]
[Wireshark 2.2.7 (v2.2.7-0-g1861a96)]
I was having some local domain resolution problems with a DNS server I have setup inside a VirtualBox 'Host-Only' network that I think I've now fixed. The server would sporadically resolve my local (internal access only) domains but later refuse to resolve them (only to recommence resolution some time later). I used Wireshark to help me debug the above problem. The symptom of the problem seemed to be that my HOST was generating a lot of ICMP Destination unreachable (Port unreachable) packets that were being sent back to my DNS server.
Over the last few hours, my DNS resolution seems stable and the number of these packets has reduced significantly. Whilst things are looking much better here, I am still getting a few of these packets periodically and I would like to fix the issue that is causing them, whilst I have the momentum.
Whilst investigating the problem and searching the web, I came across a short thread in google groups: 10.6 DNS resolution, does not obey DNS server priority from DHCP that intrigued me. Of particular relevance is a thread which Andy references, and I'm wondering if this issue with mDNSResponder, or something similar, still exists as I believe it could explain the problem I'm having.
10.6 (Snow Leopard) all DNS queries
now go via mDNSResponder. mDNSResponder queries for both the "A" and
"AAAA" record, but after the first response it cancels the queries and
shuts down the socket so that all other responses are rejected (port
unreachable).
In my case, I have IPv6 resolution turned off in my DNS server, so I'm only asking for A records. But I'm wondering if mDNSResponder is closing the ephemeral ports before the responses are returned, a kind of accounting problem? Not being a regular user of Wireshark, I am having difficulty matching the requests with responses, so my question is:
How can I match the ICMP Destination unreachable (Port unreachable) error report packet from the HOST to the packet that cause the error; ie, which query response was not delivered? (See black/selected blue packets in the image below.)
(URL to the image is: https://abms.net.au/public/PortUnreachable.png)
[UPDATES]
Here is a breakdown of such a packet, and from what I can see, it is not following the RFC792 format, as per the example shown below. Contrary to RFC792, the 1st 6 bytes of the packet are the Mac Address of the Server hosting the DNS....
Here is the data in a ICMP Destination unreachable (Port unreachable) packet, as an image (couldn't figure out how to copy/paste it):
(URL to the image is: https://abms.net.au/public/PortUnreachablePacketData.png)
Here is Wireshark's decoding of the packet:
Frame 876: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0
Interface id: 0 (vboxnet0)
Encapsulation type: Ethernet (1)
Arrival Time: Nov 23, 2017 14:26:42.894172000 AEST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1511411202.894172000 seconds
[Time delta from previous captured frame: 0.000033000 seconds]
[Time delta from previous displayed frame: 0.000033000 seconds]
[Time since reference or first frame: 227.535174000 seconds]
Frame Number: 876
Frame Length: 70 bytes (560 bits)
Capture Length: 70 bytes (560 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:ip:udp]
[Coloring Rule Name: ICMP errors]
[Coloring Rule String: icmp.type eq 3 || icmp.type eq 4 || icmp.type eq 5 || icmp.type eq 11 || icmpv6.type eq 1 || icmpv6.type eq 2 || icmpv6.type eq 3 || icmpv6.type eq 4]
Ethernet II, Src: 0a:00:27:00:00:00 (0a:00:27:00:00:00), Dst: PcsCompu_5b:b3:ef (08:00:27:5b:b3:ef)
Destination: PcsCompu_5b:b3:ef (08:00:27:5b:b3:ef)
Address: PcsCompu_5b:b3:ef (08:00:27:5b:b3:ef)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: 0a:00:27:00:00:00 (0a:00:27:00:00:00)
Address: 0a:00:27:00:00:00 (0a:00:27:00:00:00)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.56.1, Dst: 192.168.56.2
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 56
Identification: 0xea51 (59985)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: ICMP (1)
Header checksum: 0x9f1f [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.56.1
Destination: 192.168.56.2
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 3 (Port unreachable)
Checksum: 0xfda7 [correct]
[Checksum Status: Good]
Unused: 00000000
Internet Protocol Version 4, Src: 192.168.56.2, Dst: 192.168.56.1
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 286
Identification: 0xb292 (45714)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xd5e8 [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.56.2
Destination: 192.168.56.1
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 53, Dst Port: 65045
Source Port: 53
Destination Port: 65045
Length: 266
[Checksum: [missing]]
[Checksum Status: Not present]
[Stream index: 14]
