Split horizon / brain use case triggering error 1016

Hello,

I’ve read past posts about split horizon / brain DNS use cases, and I’m not sure my specific use case has come up and/or I’m understanding things correctly.

I have some private homelab services protected behind Cloudflare. To get some security through obscurity, these are on subdomains that are difficult to identify through brute force.

For my LAN, mobile devices, and family (not on LAN), I’d like to use more user friendly subdomain names. To work around this, I though I could setup a private DNS server that had local CNAME records pointing to the the obscure subdomain on Cloudflare. When navigating, from these devices using this private DNS and CNAME (that Cloudflare itself cannot resolve), I receive an error 1016. From reading, I understand this is because the Cloudflare CDN determines how to route the traffic based on host.

Is there a way to work around this, and I can use a split horizon / brain DNS for this use case? Is there a way to tell Cloudflare how to route it? I would prefer not to have a simple subdomain public, as that will likely get accessed by threats that are just iterating through common words. Sure, there are ways to use Cloudflare to protect these subdomains, but it’s “attack surface area” that I’d like to avoid, especially since this is for a homelab, and I’m sure I won’t configure things perfectly… At the same time, for users of my LAN / private DNS, I’d like the subdomain to be user friendly.

Thank you!

Not exactly. The reason is Cloudflare does not recognise those “friendlier” hostnames and hence throws that error. You’d need to configure them on Cloudflare too, but then you lose the obscurity part of course.

I am afraid there isn’t for the mentioned reason. Considering these hostnames and requests are only for private use and should come only from your own network, the best approach would be to configure your private DNS server to simply resolve directly to the origin and not to Cloudflare (A record to the origin instead of CNAME record to your Cloudflare hostname).

This post was flagged by the community and is temporarily hidden.

Thanks for the quick reply, and makes sense (even though not what I wanted to hear).

No worries. Generally I’d probably rather advise against a setup the way you described it, but I might not know all the details, so it’s hard to tell for sure.

Nonetheless, if you want to split it I’d really have the origin configured on your private network as that will avoid quite a few issues, one of them the one you encountered here, the inability to proxy unknown hostnames.

I don’t think there’s anything particularly unique to know, so I’d appreciate suggestions!

I want to make services available on the open internet but not have any connection come through to the service that isn’t already pre-authorized in some way. Perhaps that’s an oxymoron – public but not. The reason for this is that homelab services are not built with security in mind; Nextcloud, which is among the more sophisticated, has a poor security track record and has all kinds of bugs (which does not instill confidence for security).

I think a VPN, Cloudflare Access, and client certificate authorization (mTLS) could fulfill the same requirement. VPN would require specific software and configuration on all devices, which is cumbersom (and not all devices have VPN clients). I think Cloudflare Access could break compatibility with non-brower apps that can’t handle the Cloudflare web-based authentication. And client certificate authorization is tricky, as some platforms like iOS, do not allow system-wide installation of client certificates.

What do you think? Thanks.

Sounds to me like a classic case for Cloudflare Access, but I am not sure where the different hostnames and separate local configuration came in. And I believe you could even skip Access for certain network ranges then. So Access probably addresses this case.

Again, thanks for the super fast reply and your time and insight!

The local configuration would be to route traffic local to the services on the local network. I think that can coexist with Cloudflare Access.

What I’m not sure about with Cloudflare Access is the use case of mobile devices, when they are not on the LAN and when they are using specialized apps instead of the browser to access services.

Since I’d want access on a broad IP range, as mobile devices will roam networks, a target IP allowlist for Access would not work, right?

And then, I’m not sure if apps will be able to navigate through the Cloudflare Access login screen? I think apps would at least need to use web-based authentication already, and then it would be necessary for them to store the right Cloudflare cookies and tokens (in addition to what they would for their own authentication)?

Am I understanding this correctly? That seems like a lot of ifs to get right.

More or less.

So you currently rely on a “secret” hostname but apart from that everything is accessible?

Cloudflare does support service authentication for Access as well, but this will require tokens and possible changes in your applications.

So, yeah, quite a few ifs, but depending on your budget and what you plan to do I’d still look into it (or something else non-Cloudflare related) as hostnames are not really the best security approach in the long run.

Yes. The secret hostname still has Cloudflare firewall rules, etc. And there is the specific service login after that. It has worked well with all connections coming to the login pages being those that are ultimately users that I want to login to their respective accounts. Of course, the jig is up once the secret hostname is known.

I think I’ll just need to do some testing. Most mobile phone apps these days do user login by popping up on a browser and doing something like OAuth. If the Cloudflare Access auth tokens get retained through that process, along with the app-specific tokens, then it can probably work well. If it doesn’t work, I don’t think modifying the apps would be viable – out of my depth when its a open source offering and/or not something I think the app developer will prioritize.

Thanks again. Happy to report back if that’s helpful for your / this community’s knowledge base.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.