What happens when my primary DNS server is not reachable?

 In my classes, workshops and presentations I would explain that you are behind the 8 ball if you follow the old adage” If it ain’t broke, don’t fix it”. This is mainly because network equipment, protocols, clients, and applications are fairly dynamic and can quickly recover from many of the most common issues.

This is precisely why I am such a big fan of baselining and investigating how things work.

In this example, I was asked what would happen if your primary DNS server entry on a Windows client was not reachable. They said after some research, they found a lot of contradicting information and thought they would ask me. The main question they wanted to be answered was “Does the client continue to try and use the primary DNS address when it is not reachable?”

I explained that it would be much easier to perform packet capture and see for yourself. I warned them that you have to take a lot of what you find online with a grain of salt since there might be changes to the protocol behavior with every update as well as how various applications might impact your operating system behavior.

In this video, I simply started Wireshark and used a “port 53” capture filter while I surfed and then left the browser on Facebook since it will constantly be chatting in the background. It is important to understand the goal of the exercise. All I wanted to do was to confirm if this Microsoft Windows 10 client continues to try and use the primary DNS server IP address even though it is not reachable. I’m sure you can see the temptation to add more questions like “what if you ran a script to clear your DNS cache?”, “what if you just ran a nslookup” and of course” does the client notice any delays when the computer tries this unreachable address.

Check it out.

Ip Camera Baselining - Connecting and The Initial Trace

 Attend the www.COREITPROS.com conference with Laura Chappell, Mike Pennachi, Tony Fortunato August 22 - 26, 2022

Since IOT devices are only getting more popular, more and more ‘challenges’ have arisen.

Everything from the operation, troubleshooting, and of course, security has come up every time we discuss these devices.

My obvious approach is to start with a baseline for a simple reason. We can’t fix what we can't see or in the protocol analysis world, we can't fix what we cant compare with. Ideally, I would like a baseline capture to compare against any trace that contains a potential problem.

In this series I chose an off the shelf IP camera for a few reasons;

- cameras tend to have more configuration control

- some cameras have the ability to run independently from the cloud

- some cameras come in wired/wireless configurations

The make and manufacturer of the camera I chose are not relevant, the methodology is. I would ask you to focus on the techniques, tips, and tricks so you can reproduce on your equipment.

In this video, we connect the camera (since it has a wired connection) directly to my computer and start Wireshark to see how it behaves on startup.

Things you might want to look for in your trace:

- ipv6 and ipv4 enabled

- DNS name lookups

- If it has a static ip address

- Any ‘special discovery or announcement’ packets and their protocol:port

As I state in the video, you should let the trace run for a minute or two. There is no real need to run a capture for a long period of time since the camera won’t get on the internet.

Don’t worry if the device you want to baseline isn’t wired, I will cover wireless in future videos.

Investigating MTU/MSS Issues

 I have seen an increase in problems that go back to IP MTU or TCP MSS issues.

Its very important to figure out which one you are dealing with so you can troubleshoot it properly.

Both TCP MSS and IP MTU refer to the amount of payload that layer can carry.

A general rule of thumb is that IP MTU is a layer 3 concept, therefore any layer 3 device would affect the MTU like a router. TCP MSS is a layer 4 concept and is affected by NAT, proxies, etc..

When using Wireshark, you will see ICMP error messages stating “Destination Unreachable (Fragmentation needed)”. Within the ICMP packet you will see the “MTU of next hop” that is allowed. MTU issues are tricky to troubleshoot since the symptoms range from timeouts, drops or poor performance. Also pay attention to your network firewalls and ensure that ICMP error packets are allowed back to the client.

When it comes to TCP MSS, you will see the MSS values in the TCP SYN packets. Super small TCP MSS values such as anything less than 500 bytes will cause performance-related issues.