The Foundation: ICMP, DNS, and TCP
Synthetic Monitoring Series — Part 2 of 8
The Foundation: ICMP, DNS, and TCP
Every synthetic monitoring strategy is built on three protocols. Not because they’re the newest or the most sophisticated — but because they answer the three questions that matter most before anything else can be measured.
Can you reach the host? Can you resolve its name? Is the service actually listening?
ICMP, DNS, and TCP answer those questions, in that order. If any one of them fails, everything downstream fails with it. Understanding them isn’t optional for anyone who operates infrastructure — it’s foundational.
Start Here: What the Videos Cover
▶ Video 3 — “The Ping Heard Round the World — ICMP Fundamentals”
▶ Video 4 — “DNS — The Invisible First Step”
▶ Video 5 — “TCP — The Handshake That Starts Everything”
ICMP: The Oldest Synthetic Test
The Internet Control Message Protocol was defined in RFC 792 in 1981. The ping command — still the first thing most engineers run when something looks wrong — was written by Mike Muuss in 1983 to debug a network problem. He named it after sonar.
The concept is as simple as it gets. Your machine sends an Echo Request packet. The destination sends back an Echo Reply. The time between those two events is your round-trip time — RTT.
But RTT isn’t just the destination’s response time. It’s the sum of every router hop, every queue, every processing delay — in both directions. That distinction matters when you’re trying to isolate where a problem lives.
What ping actually measures
Metric | What It Tells You |
|---|---|
Minimum RTT | Your best-case scenario — the path when clear |
Maximum RTT | Your worst case, often a congestion spike |
Average RTT | The typical user experience |
Std. Deviation | Consistency; high stddev means jittery connections |
Packet Loss | Even 1% loss can devastate TCP throughput |
Ping is indispensable. It’s also never enough on its own — it operates at the network layer only, can’t detect application failures, and is frequently blocked by firewalls.
DNS: The Step That Happens Before Everything Else
Every outage investigation should start with one question: is DNS working?
Because if DNS is broken, everything looks broken — even if the underlying service is completely healthy. The Domain Name System translates hostnames to IP addresses, and it runs silently before every single network request your application makes.
The resolution chain
Step | What Happens |
|---|---|
1. Query | Device asks the recursive resolver: “Where is example.com?” |
2. Root | Resolver asks a root name server, which points to the TLD |
3. TLD | TLD server (.com) points to the authoritative nameserver |
4. Auth | Authoritative server returns the IP address |
All of this happens before your browser loads a single byte of content.
Record types you should be monitoring
Record | Purpose |
|---|---|
A | Maps hostname to IPv4 address |
AAAA | Maps hostname to IPv6 address |
MX | Directs email traffic |
NS | Identifies authoritative nameservers |
TXT | Carries verification data (SPF, DKIM, etc.) |
CNAME | Creates hostname aliases |
Why location matters: DNS-based load balancing and geo-steering mean the same hostname can return different IP addresses depending on where you ask from. A probe in New York resolves to one IP. London gets another. Tokyo gets a third. You need to test from multiple locations to understand the full picture.
TCP: Proving the Service Is Actually Listening
Here’s a scenario that illustrates exactly why ICMP isn’t enough.
Ping to a database server succeeds — the host is up, the network is reachable. But a TCP check to port 5432 fails — PostgreSQL has crashed. Ping missed the actual outage entirely.
That’s the gap TCP monitoring fills. The three-way handshake is the connection that precedes every application interaction:
Packet | Meaning |
|---|---|
SYN | Client: “I want to connect” |
SYN-ACK | Server: “Acknowledged, I’m ready” |
ACK | Client: “Let’s go” |
The total time for these three packets is your TCP connection time — a pure measurement of network latency with no application processing involved.
Best used for: database ports (PostgreSQL 5432, MySQL 3306, Redis 6379), custom application protocols, load balancer health checks, and any internal service that doesn’t expose a web interface.
The Three Together: A Layered Baseline
These three protocols aren’t alternatives — they’re layers. Each one verifies something the others can’t.
Protocol | What It Confirms | What It Misses |
|---|---|---|
ICMP | Host is reachable | Service health, application errors |
DNS | Hostname resolves correctly | Whether the resolved service works |
TCP | Port is open and accepting connections | Application-layer behavior |
When you run all three continuously from multiple geographic locations, problems that would take minutes to diagnose manually become immediately locatable — wrong layer, wrong region, wrong component.
Real-World Scenario
Users in Europe report the app is slow, but US-based monitoring shows everything green. ICMP from a European probe shows normal latency. TCP to port 443 connects cleanly. But DNS resolution from Frankfurt is taking 380ms — versus 28ms from US-East. The problem isn’t the application. It’s a misconfigured DNS resolver adding hundreds of milliseconds to every European request. Without geographic DNS monitoring, this is invisible. With it, you have the answer in seconds.
This is the baseline every synthetic monitoring strategy is built on. Everything else — HTTP phase decomposition, TLS certificate tracking, WebSocket validation, ML anomaly detection — sits on top of it.
Next in the Series
Part 3 — TLS, HTTP, and the Full Request Lifecycle. How a complete web request gets measured, phase by phase.
Synthetic MonitoringICMPDNS MonitoringTCP MonitoringPingNetwork ObservabilityInfrastructure MonitoringSRENetwork Operations
About Parlon
Parlon is an infrastructure observability platform built for enterprise teams operating complex, hybrid environments. Parlon combines active synthetic validation, real-time telemetry normalization, and learning-based alerting into a single platform — shifting operations from firefighting to foresight. Learn more at parlon.io.