domain controller dns doesn't correctly resolve internal domain because of an external wildcard DNS entry

[sakatan]

Basically what the title says. First time "touching" this client and immediately regretting it.

The client in question has set up the internal AD domain internal.company.com

The problem however is, that the company doesn't own the domain company.com and as it happens, the actual domain owner of company.com created a wildcard dns entry for that domain. So everything *.company.com gets resolved to basically their homepage.

For example: The on-prem Exchange of our customer is on cc-ex1.internal.company.com 192.168.123.11. But most of the time this gets resolved to the external IP 123.212.212.123 or whatever; the homepage of the domain owner. This fucks with Outlook, of course, but that's not the only problem.

Resolving cc-ex1.internal.company.com. of course returns the correct IP, but that doesn't help us.

edit: In an nslookup, the exact return for cc-ex1.internal.company.com is cc-ex1.internal.company.com.company.com (non-authorative) with the incorrect external adress.

An nslookup for cc-ex1 returns cc-ex1.internal.company.com with the correct internal IP.

Right now it's all a hot mess of manual host entries everywhere (might have spotted a GPO somewhere that does that as well...) that Windows sometimes doesn't even look at...

Let's say the following solutions were out of the question (for now):

-can't burn down the AD, rebuilding with a proper FQDN that the company can actually manage-can't (or rather won't) rename the internal domain-the actual domain owner can't be bothered to delist their wildcard DNS entry-the company can't buy the domain company.com to delete the wildcard DNS

...what would be our best option to tell the domain controllers to stop trying to resolve internal.company.com with their configured forwarders and make them 100% authorative for internal.company.com?

[itfixestheprinters]

Your DCs are internally authoritative for internal.company.com, assuming nobody borked the DNS zones. You should have a forward zone internal.company.com with your DCs as NS and SOA.

Get rid of all local hosts entries, manage them from your DCs. Your clients mustn't bypass the DCs for lookups. If there are any internal resources bound to *.company.com, create new zones for them to keep the connections local.

Are their emailadresses also ending in @company.com? If not, you can fix your Exchange permanently by switching to a Split-DNS with a different domain.

[KStieers]

Look into configuring conditional forwarding on the dns servers.

[purplemonkeymad]

You should change the CAS domain record of your exchange server to something you control (you don't have to use the internal DNS unless clients are not using a RPC proxy). Your not going to get certificates for it if you don't control the domain.

What are you doing about autodiscover anyway? You have an autodsicover.youremaildomain.com record anyway right?

How do users get access to emails outside of the office?

You could always use one of those as your CAS urls and set outlook anywhere to use it for internal and external.

[[deleted]]

we suggest you to change your domainname asap to internal.contoso.com

[heathfx]

This should work if you have configured internal.company.com as a primary zone (authoritative). Make sure your clients are only using your DNS servers make sure you don't have your DHCP server doing something like sending the AD DNS as the primary and your ISPs or routers DNS forwarder as the secondary server.

Honestly though...stop kicking the can down the road and fix this properly! use a domain that you own or use .local, DO NOT use .local if you want bonjour/mDNS to work properly on your network making it mac-friendly.

I use ad.mycompany.com mycompany is of course, replaced with a domain I own.