We have enough issues with DNS that adding split DNS into the mix is a ball ache I don't want to contend with.
We actually have the DNS for our private domain set publicly, and all the actual work happens on a load balancer which is on the network. We're fully remote so this avoids the "my communal WiFi provider seems to have issues with the VPN" (which is what we had when we used split DNS)
We use split DNS and the admins can't even do it right, they keep fucking it up and configuring one DNS view but not the other, so when I'm on VPN I randomly can't use certain domain names.
Also as another commenter mentioned, it is impossible to tell based on the name if it is an internal or external resource
I'm curious what split DNS offers that a separate internal zone wouldn't.
And having a website on the domain.tld adds shenanigans.
One of many examples I had is when Outlook loses connection to Exchange (eg S2S VPN is down) it starts autodiscovery process, hits domain.tld (because users have email@domain.tld, duh) and complains to user with a scary messages (which are also blocks the process until the users hit something). Which is totally understandable, because the website is on some public hosting, so CN in the cert is from the public host at best and != domain.tld.
Using corp.domain.tld or even techdomain.tld solves this totally and also let you use public certs (LE in the current era) even on the 'local' side of the network.
Aside from all technical issues the biggest problem I have seen with such an approach is that is really hard for employees to remember what is external and what internal that way. Distinct domains help there
made me think this wasnt such a great idea. particularly the part about facebook employees not being able to use their keycards to enter the buildings at the same time as the site outage.
