Tink vs external-dns
external-dns is a Kubernetes DNS controller. It watches Service and Ingress hostnames, then upserts A and CNAME records at a provider. That is not a mechanic. Tink installs in one command, watches the Linux server, explains what is wrong, and helps you fix it.
external-dns writes records. Tink answers “why is this VPS sick?”
Accidental sysadmins land on external-dns because every Kubernetes Ingress diagram mentions it. Then the volume fills, nginx dies, and the A record still resolves — the VPS was never a hostname. A filling /var is a Tink warning; it is not a TXT owner unless you already run external-dns on that cluster.
Tink is the other job: detect the issue on the machine, say why it happened in plain English, propose the command, and run it only after you approve. Keep external-dns if you already operate Kubernetes and need cluster DNS sync. Use Tink if you run Linux servers and want a mechanic.
| Feature | Tink | external-dns |
|---|---|---|
| Setup time | 30 seconds (one curl | sh command) | Hours — a cluster, provider credentials, TXT ownership, source filters, and still no host mechanic |
| What you get | Working monitoring, diagnosis, and approved fixes | Synced DNS records. The box is still yours to diagnose and SSH |
| Pricing | Free (Scout) / $9 / $29 per machine per month | Free (Apache 2.0). You still pay for the cluster, Route53/Cloudflare API, and the engineer who owns TXT owners |
| Hidden costs | None — fully managed | Stale TXT records, provider rate limits, annotation mismatches, and a second tool that pages you when /var fills |
| Monitoring approach | Agent on the server — CPU, disk, services, logs, certs, ports | Service/Ingress sources and DNS upserts — external-dns does not watch the OS |
| Configuration | None after install — heuristics and AI | Provider, domain filters, txt-owner-id, annotation policy, and which sources the controller is allowed to sync |
| Plain-English diagnosis | Yes — AI explains root cause, impact, and fix | No — external-dns logs registry errors. You still SSH or kubectl logs to learn why a VPS is sick |
| Fix execution | Proposes and executes approved commands with an audit trail | DNS only — external-dns cannot free disk, restart host nginx, or rotate a cert on a VPS that is not a hostname |
| Alerting | Built-in across 8 channels | None — scrape registry_errors_total or watch TXT drift before anyone is paged about the host |
| Predictive alerts | Yes — disk fills in ~6 days, memory and CPU trends | Record sync only — external-dns upserts A/CNAME. It does not forecast host fill |
| SSH brute-force detection | Built-in — parses auth.log every scan | Never — external-dns does not read auth.log, journald SSH, or host firewall state |
| Machine offline detection | Agent presence monitoring with multi-channel alerts | A silent hostname is a missing controller — only if the API server still answers |
| Public status page | Shareable URL with 90-day history | None — external-dns has no customer-facing status page |
| Weekly fleet digest | Automated Monday digest + daily brief when issues are open | None — a DNS upsert is not a plain-English fleet narrative |
| On-call tracking | Built-in /oncall command + incident acknowledgment | Not included — wire controller metrics into PagerDuty or another incident tool |
| Conversation interface | Telegram, WhatsApp, web dashboard, CLI | kubectl logs -l app=external-dns. No mechanic you text when /var filled on a VPS that is not a hostname |
| Learning curve | None — works after install | Steep — Kubernetes, DNS providers, TXT ownership, annotation policy, and which registry error actually means the box is sick |
| Best for | Freelancers, small teams, accidental sysadmins (1-50 Linux servers) | Teams that already run Kubernetes and need cluster DNS sync, not a sick-VPS mechanic |
When external-dns is the right choice
Keep external-dns when you already want that exact job:
- Cluster DNS sync — external-dns is how Kubernetes writes an A or CNAME from a Service or Ingress. You need it to feed Route53 or Cloudflare, not to watch a quiet VPS.
- An existing cluster — provider credentials, domain filters, and TXT owners already exist, and someone owns annotation policy.
- Record ownership questions — registry errors and stale TXT records matter more than host nginx, disk, and SSH.
- Hosts that only exist as Nodes — you already run Kubernetes, not a sick-box SSH loop.
The real cost of “just run external-dns”
external-dns is in every Kubernetes Ingress diagram. A working ops loop for five Linux boxes is not:
- A healthy A record still means you SSH in and change the box by hand
- Host fill, nginx, and SSH brute-force never appear unless they show up as a registry error you already scrape
- A filling /var is a Tink disk warning on every scan — external-dns will stay quiet until the hostname is the thing that drifted
- A single VPS with no cluster still needs a mechanic, not a DNS record controller
For a 5-server team, Tink Mechanic at $45/month is cheaper than external-dns plus the engineer who keeps provider credentials and TXT owners alive, and every scan includes a diagnosis a quiet A record will not type.
No TXT-owner homework. No silent host. One command install.
Start MechanicAlso compare: Tink vs etcd · Tink vs Horizontal Pod Autoscaler · Tink vs Prometheus