So
I have a hidden primary and Cloudflare as secondary
My ex-wife's new boyfriend works in IT
How paranoid should I be about the zone file
Hidden primary with Cloudflare slave—paranoid enough?
minhdock
Member
The setup the good one. Very much. But the threat model the cwazy one. Numbered list:
1. The boyfriend the IT wowker, not the hackew
2. The DNS the not pwivate, the cloudflawe know all
3. The ex-wife the probably not care about zone file
You make a server up with this for what? The pawanoia the very specific
The advice the welcome if you explain more
The architecture is sound; the threat model needs calibration.
Hidden primary with Cloudflare as secondary is standard practice. Cloudflare sees your zone data — unavoidable with any secondary provider. The "hidden" aspect protects against direct attacks on your primary's IP, not against the secondary operator's visibility.
If the concern is compromise of the primary, consider:
- TSIG between primary and all secondaries, not just Cloudflare
- RPKI for your reverse DNS if you control the prefix
- Out-of-band management network for zone updates, not SSH over public internet
The ex-wife's boyfriend "works in IT" is not a technical threat. Social engineering, credential access, or physical proximity are more likely vectors than DNS hijacking. Your DNSSEC signing policy matters more than your hidden primary topology.
What is the actual asset you are protecting?
iBGP, eBGP, don't care, just peer
WRONG.
The threat model is VALID. You do not know what the boyfriend knows. "works in IT" means ROOT ACCESS to EVERYTHING.
I have SEEN this. My cousin's ex-wife's boyfriend DELETED the pfsense config.
Hidden primary is NOT ENOUGH. You need:
- AIRGAPPED signing
- MULTIPLE secondaries
- HARDWARE TOKEN for updates
- NUCLEAR OPTION: delete the zone, start over.
@GeorgeNmp RPKI does NOT HELP against angry boyfriend!