How can internal users reach our website when AD uses the same domain?

The cleanest workaround is probably a website change. Make the www name work without redirecting it to the root, and keep an internal DNS record for www pointing to the site. The root can still work for visitors outside the network.

Both names need to be configured on the web hosting side, including the certificate. Just adding a www DNS record won't help if the site immediately sends the browser back to the root.

If the root name has to work internally, look at redirecting TCP ports 80 and 443 at the firewall from the domain controller addresses to the website. That's a network translation, not an HTTP redirect. AD DNS can continue returning the domain controller addresses.

Check whether anything else needs those ports on the controllers, whether client traffic actually passes through the firewall, and how the web host handles the connection. Test HTTPS and certificate validation as well as any effects on other traffic before rolling it out.

A browser proxy is another option if firewall translation isn't practical. You could push a proxy configuration for requests to the website and have the proxy resolve the public address independently of internal AD DNS.

That adds another service to maintain, though, and it only helps traffic configured to use it. Check how the proxy resolves the name and test HTTPS before depending on it.

There are also controller-side workarounds, such as a port proxy or a web server on each domain controller. Those bring their own maintenance and security tradeoffs, and a proxy can run into compatibility issues with some web providers. I'd investigate the website or network options first.

Adding the public web server as another address at the AD zone root has been suggested too, but that mixes web and domain controller addresses in the same DNS answer. It isn't a reliable way to direct each kind of client to the right service.

For a new AD deployment, using a subdomain such as ad.example.com avoids this particular collision with the public root. Users can still have sign-in names using the public domain.

That's not a quick fix for an existing domain. Renaming AD can affect applications and scripts that depend on the current name, and products such as Exchange can rule it out. Treat it as a major migration decision, not a DNS tweak.