Internal DNS - emailsrvr.mydomain won't resolve, IP does - www works.

Question

Internal Mail won't resolve to emailserver domain, but LAN ip is fine
Hey gang, longtime reader first time poster.
After wrestling with this issue, i'm about out of ideas.
Here's my setup.
Leopard server 10.5.4, running OD master (all rocking),
AFP, Firewall, DNS, (mobile) network home directories.
I'll call this "xserve.mydomain.com "
Its NAT'd IP is 192.168.1.102.
It's a FQDN, kerberos is running and happy, all is well.
There are about 12
clients, each with a desktop (imac) and laptop (macbook).
I have a second (windows 2003 sbe) server hosting the following
services: Exchange and Web (for now).
I'll call this winsbe.mydomain.com
Its NAT'd IP is 192.168.1.101
My External DNS setup is this.
Our DNS hosting is done by our registrar (network solutions).
We own 4 static IPs from our ISP.
One IP is for our router/firewall providing NAT
to internal clients, and the xserve is on DMZ, with
its OSX firewall service turned on.
One IP is for the
windows server. (the last two, if you've been counting, are unused .
Via Network Solutions "advanced DNS", I have our zone
configured. "xserve.mydomain.com" points to its WAN
IP (66.xxx.xxx.198).
www points to 66.xxx.xxx.194.
MX records refer to "winsbe.mydomain.com" via
WAN IP 66.xxx.xxx.194 as well.
All outside services resolve correctly.
IE, i can hit the website and send/receive email from mydomain.com.
My internal DNS as setup as this:
primary zone= mydomain.com
nameserver= xserve.mydomain.com
mx record= winsbe.mydomain.com
xserve.mydomain.com has an A record to LAN IP.
winsbe.mydomain.com has an A record to LAN IP.
www is a CNAME record to winsbe.mydomain.com. <----i'm not sure about this one but it works.....
My forwarder IP points back to my Router (which seems to give me better performance than using ISP
DNS from here..)
I know this is working fine insofar as the webserver, as
an nslookup (www.mydomain.com) internally resolves www to 192.168.1.101.
mydomain.com and www.mydomain.com hit the webserver internally
on client browsers. rock.
Again, forward AND reverse nslookups internally resolve to winsbe.mydmain.com/92.168.1.101
Here is my guess as to my problem,
my internal hostname + a record for the windows server the same as the MX record
which has an alias from www.
I think it's getting effed in there somewhere?
If I setup email clients with the windows server LAN IP rather than
the domain "winsbe.mydomain.com" it all works fine.
I'd frankly be willing to half-*** it with this solution,
but each client will require a mobile computer, so we can't have that
I feel like i'm on the right track, but
just can't make the breakthrough.
Am I barking up the wrong tree here?
Here is a last question,
I have my firewall/router as the "Forwarder IP Address"
in the last page of Settings in server admin. When i put
my ISP's DNS servers, i always get a 2 second delay
for any web query on any client.
I have "127.0.0.1" as the first DNS entry in xserve Network Preferences.
The xserve is the only DNS entry in the client computers.
This isn't a "bad practice" or anything is it?

Answer 1

For the curious, my named.conf below (haven't messed with it):
// Include keys file
include "/etc/rndc.key";
// Declares control channels to be used by the rndc utility.
// It is recommended that 127.0.0.1 be the only address used.
// This also allows non-privileged users on the local host to manage
// your name server.
// Default controls
controls {
inet 127.0.0.1 port 54 allow {any; }
keys { "rndc-key"; };
options {
include "/etc/dns/options.conf.apple";
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
// query-source address * port 53;
// a caching only nameserver config
logging {
include "/etc/dns/loggingOptions.conf.apple";
// Public view read by Server Admin
include "/etc/dns/publicView.conf.apple";
// Server Admin declares all zones in a view. BIND therefore dictates
// that all other zone declarations must be contained in views.