Analysis Our first capture file begins when the user at workstation address 172.101 attempts to access an application hosted by the headquarters app...

Analysis

Our first capture file begins when the user at workstation address 172.16.16.101 attempts to access an application hosted by the headquarters app server, 172.16.16.200. This capture contains only two packets.

1. (3 points) The DNS request in packet 1 was sent to what IP address? What is this device? Where is the packet 1 destination device physically located?
2. (2 points) Did the DNS query complete successfully? Justify your answer.

Because the DNS queries at the branch office are resolved by the DNS server at 172.16.16.251, that's our next stop.

In order to capture the appropriate traffic from the branch office server, we'll leave our sniffer in place and simply change the port-mirroring assignment so that the server's traffic, rather than the workstation's traffic, is now mirrored to our sniffer. The result is the file stranded_branchdns.pcap.

This capture begins with the query and response we saw earlier, along with one additional packet.

1. (3 points) What device is the additional packet (packet 3) attempting to communicate with? What is its IP address? Where is the device physically located?
2. (2 points) What port is being used? What protocol is being used?

In order to figure out the purpose of this packet, recall the discussion of DNS from Wireshark Lab #4 DNS.

The DNS server at the branch office location is the slave to the DNS server at the central office, meaning that it relies on it in order to receive resource records. The application server that users in the branch office are trying to access is located inside the central office, which means that the central office DNS server is authoritative for that server.

5. (5 points) Speculate as to the likely cause of the SYN packet (packet 3) in the capture file. Should we normally have a SYN packet in this situation? Why or why not?

The lack of response to this SYN packet tells us that the DNS problem here is the result of a failed zone transfer between the branch and central office DNS servers. Now we can go one step further by figuring out why the zone transfer is failing. The possible culprits for the issue can be can be narrowed down to the routers between the offices or the central office DNS server itself. In order to figure this out, we can sniff the traffic of the central office DNS server to see if the SYN packet is making it to the server.

There is no capture file for the central office DNS server traffic because there was none. The SYN packet never reached the server. Upon dispatching technicians to review the configuration of the routers connecting the two offices, it was found that the central office router was configured to allow UDP traffic inbound only on port 53 and block TCP traffic inbound on port 53. This simple misconfiguration prevented zone transfers from occurring between the servers, which prevented clients within the branch office from resolving queries for devices in the central office.