Q1. Can someone tell me how to test and diagnose issues with my home LAN?
I think that it is a DNS problem, but I have no clue how to proceed.

Q2. What information might I post so that my LQ colleagues are better able to offer helpful suggestions?

My Symptoms
The Following events happen during almost every end-user session. In most cases, they resolve after some variable elapsed time.

One "interesting" situation happens. When requesting a web link, we get some web based error report "server can't do that" which almost immediately resolves into display of whatever we were trying to reach.

I notice that 'update-manager' has notified of available package updates.
When I launch the utility, I request a rescan and see the spinner saying that things are working. This continues for quite some time.

I'm in a browser — typicall Firefox or Chrome — and select a link.
I see the spinner saying that things are working. This continues for quite some time.

I receive email with an embedded web address link.
I select the link and see the spinner saying that things are working. This continues for quite some time.

My Configuration:
Thank you in Advance,
~~~ 0;-Dan

time dig google.com

2 members found this post helpful.

google.com or any public host site is likely to be in cache along the way:

• my local workstation or device (resolver of similar)
• the "gateway" address for my LAN (my router)
• whatever my ISP box might do (their router)
• other DNS at the ISP (their cloud)

Something is taking a lot of time to satisfy my request, via selected web link, to deliver my pages.
QUESTION: How do I diagnose this?

Are my browsers taking forever to render content?
Are services taking forever to create and send requested content?
Is content getting stalled by my own network parts? Other network parts?

Thank you in advance,
~~~ 0;-Dan

Check your primary and secondary DNS resolvers. In /etc/resolv.conf that would be the first and second nameservers. IF the first is not resolving properly then you are seeing the delay while your networking waits to failover when the first does not answer before trying the second.

If you use a caching nameserver locally, check what nameservers it uses upstream for the same problem.
One or more of your nameservers is either answering with a delay, or not answering forcing failover. Changing you nameservers, or changing their order, might change or eliminate these symptoms.

Simple example. Check the servers that you want, from the dns that you want.

I'm running Linux Mint and use whatever Mint offers for "network management" and "resolver." Until recently, I've been able to ignore the nuts and bolts of home LAN components. It appears that networkd-dispatcher or similar is running things. I don't know enough to say that with certainty.

Thanks for your help,
~~~ 0;-Dan

Did you ever setup a local DNS or pi-hole server? Is so where in the network is located?

Are the two routers setup as a double nat or maybe the ISP is in passthrough mode?

Are you getting the expected speed from the ISP and wireless APs?

name service bottlenecks can be caused by large uploads in the network... the request for ip address is a packet in a queue; if a device on the same network, say an anroid phone, is syncing to a cloud, with gphoto's syncing to its cloud, for example, the packets of photo data in the queue are larger and plentiful, slowing down your request for an ip address: so you see the spinning wheel while your request for an ip address waits its turn in the queue.

1 members found this post helpful.

While I've used Linux "forever" I'm only a power user and not a wizard*...
Is there an easy to deploy and straight forward to use utility that I might use to monitor raw traffic so that might see"
Thank you for the Reply,
~~~ 0;-Dan

If it's your network, and you have access to the router, then depending on the kind of router, and its firmware, some/most provide a way to create priority queues for the devices that connect through them.

There is a linux app, called "tc" for throttle control, that is useful for traffic shaping, and can be run on a bridge interface; but like many linux apps there is a learning curve to using it.

I use rsync for backing up to cloud devices, and it used to hog the bandwidth, until I discovered that I could run it with the flag "--bwlimit=" and provide it with a rate limit in kilobytes per second (unless providing another unit, like m, for megabytes per second). That solved my problem without having to mess with tc and a bridge.

If there are other users on a network that you are not the administer to, then it becomes a social issue; sometimes kindly asking them to turn off their phone to see if the internet speeds up, proves that their phone is the culprit, and you might convince them to disable syncing to cloud on the apps they are using.

There are network monitoring tools, but the best of those are built by and for network professionals and would drive the average user crazy. (or crazier, depending.)

Dimply doing and timing a manual name lookup against both the default and a selected public nameserver will tell you if your default is the problem, and will give you a response time metric.