Canaries are designed to be simple to deploy, quiet when nothing is happening, and loud when it matters. The communications channel underpinning this is DNS.
Every Canary you deploy talks to its Console through DNS. A deliberate design choice by us to make deployments easier. You may have heard of this concept as DNS Tunnelling.
This article covers what's happening when your Canary "phones home" and the path that handles heartbeats, updates, configuration changes and any offloading of alert data.
The short version
A Canary doesn't need to communicate directly, and instead it encodes its reports — an alert or a heartbeat — into the subdomain of a DNS lookup, it then sends that lookup to its configured DNS server. The lookup is answered by the chain of DNS servers the rest of the internet already uses. It arrives at a nameserver run by the Canary Console. Your Canary Console decodes the subdomain, processes the message, and sends a reply back in the TXT record of the DNS response.
That's it. No outbound TCP connection. Just a DNS query that looks, to every device in the path, like another DNS query on the internet.
Under the hood
A Canary — on any platform — will generate DNS lookups (TCP or UDP on port 53) for all of its management communication. Traffic stays local between your Canary and your DNS server, which handles the recursive lookup out to the internet.
Since there's no direct communication outbound required, you won't need to add an explicit firewall rule.
Canaries resolve hostnames for the cnr.io domain which we own, and each Canary Console is issued a unique subdomain hash (abc123.cnr.io), which your Canaries are strictly geared to only ever communicate to.
For a technical breakdown of how our DNS channel works, check out our Canary Communications and Cryptography White Paper.
Why DNS?
We've seen teams around the world deploy appliances and bump into obstacles that prevent the solution from being implemented, stopping them providing value sooner than they could.
Firewall rules, proxy configuration and trusted certificates are all up for consideration, each gated behind a change-control process.
While these security controls are important in a modern network, you can almost certainly still resolve a hostname even with them present. Name resolution is a foundational feature to the internet and usually has an open passage. Block it and things break.
By riding DNS resolution, your Canary doesn't have to reach out to anything, instead it hands its traffic to an existing open channel, your internal DNS resolver, which in turn does the work of finding an authoritative answer. Your Canary never needs to open a connection to the public internet. It just asks a question, and its answers comes back.
What this gets you
A few things work out well with this design and that we think are worth pointing at:
Canaries are plug and play. With minimal network configuration — which we handle for you before shipping — Your Canary can immediately get to work as it powers up. No proxy settings. No allow-listing your Canary Console's IP. If the network can resolve a hostname, your Canary can talk to its Canary Console.
They bridge air gaps almost by accident. Canaries are deployed into hyper-sensitive networks, often with no general internet access, yet still have DNS resolution. We've watched Birds happily report in from networks where it was sworn nothing could reach the internet.
It's reliable. Our DNS channel carries the messages of thousands of Canaries in the wild and it does this without sacrificing modern features like encryption (resolvers and intermediaries can't read payloads) and we've layered TCP-style acknowledgements on top so messages are reliably delivered.