If you want things to work easily and painlessly, do the following:
Run Windows DNS servers only on Active Directory domain controller computers. (This insures they have copies of your Active Directory-integrated DNS zones).
Insure that your Windows DNS servers have either "Root Hints" specified (which is the case by default) or have a "Forwarder" specified referring to a DNS server at your IPS.
Verify that all Windows machines (servers and clients) have only Windows DNS servers specified as their DNS servers. (No non-Windows DC-based DNS servers should be specified in any server, client, or DHCP configurations.)
Verify that your firewall rules permit the Windows DNS servers outbound UDP port 53 to the Internet (either the entire 'net, if you're using "Root Hints" or your ISP DNS servers, if you're using "Forwarders").
This is the recommended configuration from Microsoft and will result in both Internet and internal name resolution w/o "leaking" dynamic registration requests from Windows machines to your ISP or other external DNS servers.
This answer is rather assumptive, but being that you mentioned SBS it's likely that this is a fairly simplistic network and the above is your most painless way to get what you're looking for moving forward.
If it were me, BTW, I'd use root hints rather than forwarders. I don't trust my ISP not to do nasty things with DNS (respond with their own "serach engine" site rather than returing NXDOMAIN's for invalid domain names, etc).
Yes, there are currently two popular solutions to this problem.
The first is called Anycast, where the same IP block is literally in use in multiple locations around the world. That is to say, the name servers for your domain always return the same IP address, but that IP address is actually assigned to more than one set of physical servers.
You can read more about it here http://en.wikipedia.org/wiki/Anycast
The second technique again involves AnyCast, however this time, the IP address range being anycasted referes to our name servers themselves. As the nameservers will only requests from clients who they are closest too (as determined by the magic of BGP), they can themselves return IP addresses that are logically local to the client.
An example of this is google's l.google.com domain
From a host in Australia
crimson:~ dave$ host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com is an alias for www-notmumbai.l.google.com.
www-notmumbai.l.google.com has address 66.249.89.99
www-notmumbai.l.google.com has address 66.249.89.147
www-notmumbai.l.google.com has address 66.249.89.103
www-notmumbai.l.google.com has address 66.249.89.104
From a host in the US
[dave@odessa ~]$ host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 74.125.95.99
www.l.google.com has address 74.125.95.147
www.l.google.com has address 74.125.95.104
www.l.google.com has address 74.125.95.106
www.l.google.com has address 74.125.95.105
www.l.google.com has address 74.125.95.103
So, the CNAME for www.google.com resolves to www.l.google.com, but when you resolve that, depending on your location, your client receives a different set of IP addresses. This is because the name server that received the request for www.l.google.com was the local nameserver, relative to the client.
Best Answer
You're right that there is a conflicting message. A warning, plus valid data. Some things to try:
Use NS lookup to confirm that your zone is responding correctly. Here's a video walkthrough on how to do that. Make sure to use
server secondary_dns_serverto test directly from your secondary server.