The latter part of this post is wrong. I was under the impression, based on some stuff I had read on the web (if it's on the web, it must be true!) that part of the Windows DNS Server Service's tasks for creating its cache was to also load its host file into cache along with its local zone data. I searched around and couldn't find hard evidence of this. I tested the theory on my own Server 2008 R2 machine and found that the hosts file was not used to build the DNS Server's Cache.
However, I believe I have a slightly more elegant solution that Massimo. Instead of creating an authoritative zone for the entire nlscan.com zone, simply create a zone named mailserver.nlscan.com and place a nameless A record in that zone. The nameless A record will have the same name as the zone itself and you can give it the IP address that you want. All other domains underneath nlscan.com as well as nlscan.com itself will resolve by public DNS.
I just tested this out on my own Server 2008 R2 DNS server and was able to make my friend's website (nessus.nl) resolve via public DNS servers but the specific subdomain (blog.nessus.nl) resolve to an Apple.com IP address. Try it and see if it works for you.
Older, wrong post commences:
If my understanding is correct (EDIT: and it is not), when the DNS cache is built in the Server 2003 machine it pulls in entries from the hosts file as well as it's zone data. Placing 172.16.0.10 mailserver.nlscan.com in your Server 2003 machine's hosts file should solve the problem. Restart your DNS services after changing your hosts file.
Use ipconfig /displaydns on any Windows machine (specifically, your Server 2003 DNS machine) to see your host file entries. Also keep in mind that negative responses are cached in your clients so always run ipconfig /flushdns on the clients that you're experimenting with. Otherwise you'll end up abusing yourself against various hard objects as you wonder why your clients can't resolve a name you just entered into a zone / hosts file. =)
Have you tried this and failed?
If you only have a single Domain Controller/DNS server, you can ignore this. If you have more than one, you should be setting the primary DNS server to the IP of the other Domain Controller and setting the secondary DNS server to the loopback interface and vice versa on the other DC.
You get this error with all of your configurations, because 192.168.16.1 is the local interface, so it's effectively the same as 127.0.0.1 as far as DNS and the BPA are concerned.
This is best practice so that a DNS server isn't reliant on itself for name resolution, which would affect replication in a multi-DC environment. If you only have a single Domain Controller (and thus a single ADI DNS server), you'll continue to get this error because, well, only having 1 DC isn't best practice.
Note that you should never set an AD joined computer or a domain controller to use an outside DNS server. They should always point only to Active Directory Integrated DNS servers. This is so that they can find the relevant SRV and RR records in the _msdcs zone for your domain. If you want to set up a global forwarder to 8.8.8.8 (still not the best idea), you can do that, but you should never made a DC or AD client use 8.8.8.8 directly.
Best Answer
dcdiag /test:dns options tests some of the records relevant for DCs. It doesn't test all of them. However, if that works, thats a good start.
I dont know why you created a forward lookup zone for the domain. What type of zone storage were you using in Windows 2000? I would have expected that zone to replicate when you promoted the new DC.
If you can resolve records in the zone using tools like nslookup pointed against the Windows 2008 R2 DNS server, I would ignore this. However, feedback on the BPA functionality is welcomed as per http://blogs.technet.com/b/windowsserver/archive/2009/02/11/best-practices-analyzer-resolution-guidance-now-available-online.aspx
You could feedback to support engineers that monitor the official AD support blog at http://blogs.technet.com/b/askds/archive/2010/08/02/new-dns-and-ad-ds-bpa-s-released-or-the-most-accurate-list-of-dns-recommendations-you-will-ever-find-from-microsoft.aspx or at http://connect.microsoft.com/ADBPA .