I’m aware there are numerous topics on this matter, but there doesn’t appear to be one conclusive 100% working way on this.
We have a domain that, due to business reasons historically is our public facing but also consumed internally. Working to change away from those internal usage of domains is an on-going battle.
As we don’t have CNAME Flattening available in Windows DNS in onprem, we are unable to do the CNAME redirect on the APEX record to CF proxy and have everything served through CF, including for internal staff.
I see mentions of forwarding the A record to to CFs proxy IP, but mixed results on this working at all.
Any guides / advice / tips on a way through this? What this means, is for our upcoming cert expiry’s we’ll potentially be needing to buy a bunch of www certs and binding it on the servers for the internal direct access to the origin to not bug out on staff.
The right answer is always rename the Windows domain to use either a subdomain or a different domain dedicated to that function. I prefer the former. I realize that it can be challenging to get people to do the right thing sometimes.
If you already have the web redirection in place, I’m puzzled as to why a normal event like certificate renewal is causing concern. I also don’t know why you think you need multiple certificates when you can install the same file on multiple devices.
In a Windows domain environment you would typically just issue the certificates from your own internal trusted CA, but can use a commercial certificate or Let’s Encrypt.
Nothing in whichever solution you choose will involve Cloudflare.
Renaming a windows Domain suuuuuuuuuuucks… and if you’re using Exchange on-prem is essentially un-possible.
Since most of those mentions on this forum probably involve me or former me (@cs-cf) I’m curious as to why/where it doesn’t work outside the specific limitations/concerns I’ve outlined in posts where I’ve discussed it.
Thankfully - renaming is on the cards as our primary internal domain isn’t public. It’s just in the past our other public domains were setup internal as well, as we used to have a lot of stuff hosted internally in our own DC. Now all this is external as of start of the year in 2 DCs + a whole bunch of stuff in Azure seperately.
But we still have a lot of techdebt with stuff built to ONLY work internally on those additional domains, as they interact with said domains via their own public APIs etc.
There’s work being done to overhaul this and get rid of it, but it’s slow-going.
We’re trying to move everything out to their own forward lookups (messy af) and remove the root, but it’s just making sure everyone is available to test their stuff as we go.