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”
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.
▶ Video 5 — “TCP — The Handshake That Starts Everything”
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.
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
| 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 |
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.
TCP: Proving the Service Is Actually Listening
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.
| Packet | Meaning |
|---|---|
| SYN | Client: "I want to connect" |
| SYN-ACK | Server: "Acknowledged, I'm ready" |
| ACK | Client: "Let's go" |
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
All of this happens before your browser loads a single byte of content.
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.