Ran this:
cloudflared tunnel route dns <tunnel> sub.righthost.comIt printed a success line. The record did not exist on righthost.com. It existed on a completely different domain, as sub.wrongzone.com.
The reason: cloudflared does not parse the zone out of the hostname argument. It uses the zone that was baked into ~/.cloudflared/cert.pem when you ran cloudflared tunnel login and picked a zone from the browser picker. The hostname argument only supplies the record name. The zone comes from the certificate.
So if your cert was issued for zone A and you ask it to route sub.b.com, you get sub.b.com created inside zone A. Which is a valid record. Which is why it reports success. It did exactly what it was asked, in a context you were not thinking about.
Two things follow.
First, the success line from this command is not evidence that anything useful happened. Verify by listing the DNS records of the zone you actually meant, through the API or the dashboard, and confirming the record is there.
Second, the fix is to re-run cloudflared tunnel login and select the correct zone, which overwrites cert.pem. There is no per-command zone flag that overrides it on route dns.
I lost about 40 minutes to this, most of it spent checking DNS propagation for a record that was never going to appear, because propagation is the thing you suspect when a DNS change does not show up. Wrong suspect. The record was live and propagated the whole time, on a domain I was not looking at.