Recently, we've come across a problem sending e-mail to a certain external
address that has a @us.customer.com domain. In looking up the MX record, I
found that no MX record existed for us.customer.com. I also found that the
MX record for customer.com = us.customer.com, and there was an A record for
us.customer.com. I can get name resolution on us.customer.com, and most of
the e-mail and web browsing seems to work correctly, including if I just
send directly to customer.com.
I looked into my DNS server, and discovered that there were no root hints
configured, except for my own server. I added the root hints manually (a-m),
but it doesn't seem to make any difference. Recursion is not disabled. My
best guess here is that my server is having trouble because there is not a
specific MX record for us.customer.com, and it can't perform recursion to
resolve it. Am I in the ballpark here? Anyone know of a fix or where else I
can look?
--
IP, Therefore I Am
"Steele" <kst...@summitnetworking.net> wrote in message
news:OVvYFDTY...@tk2msftngp13.phx.gbl...
"Roger Abell [MVP]" <mvpN...@asu.edu> wrote in message
news:uUq$SBUYD...@tk2msftngp13.phx.gbl...
Can you let us know the actual domain name so we can test it from our end?
You can also goto www.dnsreport.com or www.dnsstuff.com to check it.
--
Regards,
Ace
Please direct all replies to the newsgroup so all can benefit.
Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
--
=================================
--
IP, Therefore I Am
"Ace Fekay [MVP]"
<PleaseSubstituteMyActualFirstName&LastNa...@hotmail.com> wrote in
message news:OPJomZVY...@TK2MSFTNGP10.phx.gbl...
... none of which describes something that is wrong. Is there an SMTP Relay
server listening on that IP address ? If not, then one problem is that the
DNS administrator should have added an "MX" resource record set for that
domain name but hasn't.
This may, or may not, be the cause of your problem. You haven't told us what
the error messages from your mail system actually said, so we don't know what
your problem actually _is_.
S> I added the root hints manually (a-m) [...]
That may not have been the correct thing to do. Is the correct shape of hole
knocked into your firewall to accommodate all of the extra IP addresses to and
from which DNS traffic might now travel ? You deleted the root hints for a
reason when you initially installed your DNS server.
In any case: You've just successfully looked up various resource record sets.
What made you think that your problem is with _your_ DNS service, and with
recursion ? What made you think that you needed to poke and prod anything at
all on your system ? _What_did_the_error_messages_say_ ?
I understand that there should be an MX record on the other end specifically
for the US zone - which is why I'm a little confused about why I seem to be
able to send to it from other places.
I don't remember ever deleting the root-hints, I'm not sure why they weren't
there.
What would this "correct shape of hole" look like in my firewall? I did turn
on DNS logging, and I saw what I believe was my configured forwarders
sending the list of root-hint servers to my server, although my server never
updated itself with them - which is why I created them myself. As I
understand it, the recursive queries should be being initiated from my
server internally, and therefore responses should be allowed back through my
firewall.
I may be off-base here in thinking that my problem lies with my DNS server -
I open to suggestions.
--
IP, Therefore I Am
"Jonathan de Boyne Pollard" <J.deBoyn...@tesco.net> wrote in message
news:3F3A04CB...@tesco.net...
One is that you are using as forwarders machines that do not
process recursive queries, and so you see these replying with
the root servers referrals. Answers are never entered into your
DNS servers data (your root hints) but only into volitile cache.
Use as forwarders only name servers that will work the query.
The other seems to be that you are attempting to send directly
to such as us...@us.tenax.com whereas I see that the machine
us.tenax.com is the host named as the mail server on the MX
record for tenax.com
"Steele" <kst...@summitnetworking.net> wrote in message
news:e0GeFTbY...@TK2MSFTNGP12.phx.gbl...
--
IP, Therefore I Am
"Roger Abell [MVP]" <mvpN...@asu.edu> wrote in message
news:eo6lg2mY...@TK2MSFTNGP09.phx.gbl...
Probably because the folks running the mail server at us.tenax.com have a
user account for that user and the us.tenax.com falls under tenax.com, which
that server is authorative for receiving mail, since it has an MX record
pointing to it, but us.tenax.com doesn't, as Michael pointed out. Here's my
output:
>set type=mx
> tenax.com
Server: ponyexpress.bandwidthpros.com
Address: 208.47.39.10
tenax.com MX preference = 10, mail exchanger = us.tenax.com
us.tenax.com internet address = 207.114.60.3
>
If you want to receive mail for us.tenax.com, I would suggest creating a
speparate MX record in the child zone called us and point it to your own
mail server.
I find that the SMTP Relay server for mailboxes in that domain,
207.114.60.3, is not actually speaking the protocol. I'd have
predicted that to be your error in the absence of the information
in your second sentence.
If there really is a DNS lookup problem, as claimed by the error
message, then you need to diagnose it. On the machine running
your SMTP Relay client, use a tool such as "dig" or "dnsquery" to
look up the "MX" and "A" resource record sets for "us.tenax.com.",
using the same proxy DNS server that Exchange itself is configured
to use, at the same time as the machine is experiencing these
problems. (Make sure that you force the use of DNS/TCP by your
chosen lookup tool in order to replicate the erroneous behaviour
of Exchange.)
I suspect that you'll find that there is no DNS lookup problem.
S> I understand that there should be an MX record on the other
S> end specifically for the US zone [...]
Your understanding is wrong. It is neither mandatory nor
recommended for "MX" resource record sets to be present. It is
simply optional, and there is no recommendation or requirement one
way or the other. See RFC 2821 section 5.
S> I'm a little confused about why I seem to be
S> able to send to it from other places.
One of the possible reasons for the SMTP Relay server on 207.114.60.3
being broken, and not speaking the protocol, is that its being
configured to treat SMTP Relay clients on different IP addresses
differently.
It appears to be that the SMTP traffic is going through a Cisco PIX
with the "MailGuard" feature enabled, which is known to contain bugs
that stop mail transport from working. So there are several things
that could be happening. However, these bugs are not DNS problems;
nor are they problems with _your_ system.
S> What would this "correct shape of hole" look like in my firewall?
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-shaped-firewall-holes.html>