Nothing is down.
Nothing quite works.
DNS and TLS sit in front of almost every transaction on the network. When either degrades, the failure lands on the application — and the network looks perfect the entire time.
Slow DNS resolution and failed TLS handshakes are two of the most common causes of application slowness on a healthy network. A resolver that takes 800 ms instead of 4 ms adds that delay to every new connection. A handshake that fails and retries against a second server doubles the connection cost. Neither moves a byte counter meaningfully, and neither appears in flow records as anything other than a small conversation. Both are trivially visible in a capture, where the query and its response, or the handshake and its outcome, carry timestamps.
Six failures that look like a slow network.
A resolver that has started to think
Response time creeps from single-digit milliseconds into the hundreds. Every new connection in the building pays it. Nothing is down, no threshold is crossed, and the effect is felt everywhere at once — which is why it is usually blamed on the network.
Look for: DNS response time as a distribution, not an average. The tail is where the pain is.
Failures that are being retried quietly
A query that fails against the first resolver and succeeds against the second is invisible to the user and to the application, apart from the delay. The failure rate is the leading indicator, and almost nobody measures it.
Look for: SERVFAIL and timeout rates per resolver, and the ratio of second-resolver successes.
A certificate that expired overnight
The classic outage. Everything worked yesterday, nothing changed, and now one service is refusing connections. The device logs say very little; the handshake says exactly what happened.
Look for: TLS alert messages in the capture. They name the reason — expired, unknown CA, hostname mismatch — without any guessing.
A version or cipher mismatch
A hardening change disables an old protocol version, and one client population that nobody remembered cannot negotiate any more. It presents as "that one application is broken for those users".
Look for: handshake failures concentrated on one client OS, one subnet or one application, rather than spread evenly.
Handshakes that are simply slow
Full handshakes are expensive. When session resumption stops working — after a load balancer change, or because a cache was cleared — every connection pays the full cost, and a chatty application pays it hundreds of times.
Look for: the ratio of full to resumed handshakes changing on a date. That date is the change that caused it.
Resolution that is fine, to the wrong address
Stale records, split-horizon mistakes and a cached answer for a service that has moved all produce a fast, successful lookup to somewhere that no longer answers. The DNS metrics look excellent.
Look for: successful resolution followed immediately by connection timeouts to the returned address.
Four checks, in this order.
- 1
Measure resolution time before anything else
It is the cheapest check and it sits in front of everything. If the distribution has a long tail, that is very likely your whole problem and the rest of the investigation is unnecessary.
- 2
Separate failures from slowness
A slow answer and a failed-then-retried answer feel identical to a user but have completely different causes and fixes. The capture distinguishes them; a timing metric alone does not.
- 3
Read the TLS alert, do not infer it
When a handshake fails, the alert names the reason. This turns an afternoon of hypothesis into a single line of evidence.
- 4
Check when the ratio changed
Both DNS and TLS problems usually begin on a date rather than drifting. Finding the date almost always finds the change.
Both layers, one timeline.
Discovered devices
| DEVICE | TYPE | PORTS | LOAD |
|---|---|---|---|
| core-1 | Router | 48/48 | 62% |
| core-2 | Router | 48/48 | 55% |
| dist-3 | Switch | 96/96 | 71% |
| acc-3 | Switch | 46/48 | 94% |
| acc-4 | Switch | 48/48 | 38% |
Physical map
WAN-1 utilisation
38%
WAN-2 utilisation
41%
Response time
480ms
Conversations on this link
LINK ONLY 38% USED
- Backup replication10.4.18.2234%
- File share (SMB)10.4.2.5124%
- Video conferencing10.4.9.14017%
- Database sync10.4.31.812%
- Everything else—13%
- Retransmit storm on Gi0/3acc-3
Sniffer recording packets · +412% vs baseline · duplex mismatch suspected
9614:36 - Unusual east-west conversation10.4.18.22
NetFlow · new peer pair, 3.1 GB in 20 min, off-hours
7114:22 - Latency drift on WAN-2core-2
SNMP + sniffer recording packets · RTT trending up 6 hours
6411:08 - Baseline re-learneddist-3
Model updated after sustained topology change
1209:41
Recent configuration changes
142 DEVICES BACKED UP · 2 DRIFTED
- OFF BASELINE
interface Gi0/3 speed 100 → auto
acc-3 · n.levi · 14:31
ACL 120 — 2 lines added
core-1 · automation · 11:55
VLAN 340 created
dist-2 · m.cohen · Yesterday
- OFF BASELINE
SNMP community updated
acc-5 · n.levi · Yesterday
Illustrative views representing Net-Monitor output.
Why this is hard to catch after the fact
- The handshake is a moment. Once it has failed and the client has retried, the evidence is gone unless something was recording. Net-Monitor already was.
- Success rate is a baseline problem. A DNS failure rate of 0.4% is fine on one network and an incident on another. A learned baseline knows which yours is; a fixed threshold cannot.
- Certificates expire on a schedule you can see coming. Watching what is actually negotiated on the wire catches the ones nobody inventoried.
Short answers.
How do I know if DNS is causing application slowness?
Measure the time between the query leaving and the response arriving, as a distribution rather than an average. If the 95th percentile is in the hundreds of milliseconds while the median is low, DNS is adding real delay to a subset of connections — and because resolution happens before every new connection, a subset is enough to make an application feel unreliable.
Why did an expired certificate take so long to find?
Because the symptom appears at the application while the cause is one message inside a handshake that nobody is looking at. The device logs report a refused connection without saying why. A capture contains the TLS alert, which names the reason outright.
Can you monitor TLS without decrypting it?
Yes, and for this purpose decryption is unnecessary. The handshake happens in the clear: the version offered and selected, the cipher suites, the server name requested, the certificate presented and any alert raised are all visible before encryption begins.
What DNS failure rate is normal?
There is no universal figure — it depends on your resolvers, your clients and how much of your traffic goes to external names. What matters is your own steady state and departures from it. A rate that has doubled is a signal regardless of whether the absolute number sounds small.
An application that fails for no reason anyone can find?
Very often it is one of these two. We will show you the query or the handshake that explains it.