I read a mysterious DNS problem story from Jan 2006 issue of Windows IT Pro magazine a few days back. Yes, it's a quite old story, literarily almost two years ago, but I have no idea why and how it got to my desk and drew my attention at one point.
The story talks about a DNS problem that was caused by an un-registered .net domain name used in AD but being registered by their ISP, which changed all DNS records once it's been registered. It took the whole network down for two days to have them discovered and finally fixed the issue. The author concluded that there were two lessons that they had learned from this incident.
First of all, if you're using an ISP and you're having an Internal problem, be sure to communicate with the ISP. Before you start changing your DNS setup, ask the ISP's technical staff whether they've changed anything in their configuration.
Question is why didn't register the domain in the first place. The issue wouldn't happen if being done so. However, even the domain was registered, my suggestion is to remove your domain registration including DNS from your ISP and move it to a dedicated domain hosting company like register.com. By doing that, it eliminates all the potential risk mentioned above and you will have more control to your own domain. Besides, anyone who is able to configure AD should be able to handle the tasks like changing DNS records.
Also, I learned my lesson about using the .net domain. Now I use .local for all internal DNS settings. You can't get trouble with that one because you can't register it.
Yes, it's true that using .local as internal DNS name would be a good idea. I learned that lesson years ago and has been using it ever since then. However, .local is not a recommended TLD names for part of an AD tree name if you want to obtain the digital certificate from 3rd party certificate authority because simply it is not a standard Internet domain name.