[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1051
  • Last Modified:

Cannot receive emails via Exchange 2010 - Emails are down, PLEASE HELP!

Hi, this is quite urgent, so any help would be greatly appreciated:

I have Windows 2008 R2 with Exchange 2010 installed on the same server - everything is running on this one server (including DNS, IIS, Exchange, File Server, Print Server, AD). DHCP is handled by a router. This server has fqdn: server.domain.com with local ip 10.0.0.2. The server is currently set in a DMZ. The router has port forwarding for 80, 25, 110, 993, 995, 587 and a few others all setup to forward to server, 10.0.0.2.

Exchange 2010 setup
Exchange has send and receive connectors correctly configured. I can send emails locally and externally, and can receive them locally but not externally. The receive connector is set to listen to all external ip addresses.

DNS setup
DNS is configured such that the forward and reverse lookup zones have been defined. A local cmd nslookup, cannot find server unless WINS and WINS-R are enabled. Is this supposed to happen? I thought that NetBIOS was supposed to take over?

Currently in DNS, I have:
- an A record pointing to server local ip, 10.0.0.2 (10.0.0.1 is DHCP-enabled router) and an A record pointing to external ip address of server, both linked to server.domain.com. There is also an A record on ZoneEdit - see second point for more details.
- 3 NS records, one detailing server.domain.com and the other two directing to ZoneEdit nameservers (www.ZoneEdit.com). ZoneEdit also has an A record pointing the nameservers to the external ip of domain.com. From here, the router would forward the requests/data to server.domain.com at 10.0.0.2
- a Mx record pointing locally to server, 10.0.0.2, with the fqdn set as server.domain.com.
- a CNAME record to append www as a prefix to domain.com
- a PTR record in the reverse lookup zone pointing to local server, 10.0.0.2 with fqdn server.domain.com.

local nslookup
- returns server.domain.com and its local ip, 10.0.0.2.
- set type=mx for domain.com returns the correct record in accordance with above (mail pref = 10)
- set type=ns for domain.com returns all three nameservers and their ip addresses. The ZoneEdit servers have external ip addresses listed, while the server.domain.com nameserver has the local ip listed, 10.0.0.2.
- EVEN THIS DOES NOT WORK UNLESS WINS AND WINS-R ARE NOT SETUP IN DNS

nslookup on a computer away from premesis, including online nslookup (http://network-tools.com/nslook/)
- returns domain.com and external ip address (due to ZoneEdit A record)
- set type=mx for domain.com returns nothing
- set type=ns for domain.com returns only ZoneEdit nameservers

It is as if no computer can see server, but they can see the ZoneEdit servers. However, if I type in the external ip or domain.com, the IIS7 website will load. But when I type www.domain.com, the page will not load - again this is due to servers being able to see ZoneEdit which lists an A record pointing to my external ip.

Please advise me as to what I need to do. This is quite urgent. Thank you to everyone in advance.
0
indiglo265
Asked:
indiglo265
  • 4
  • 4
3 Solutions
 
tigermattCommented:

Okay, let's wind back your DNS configuration a second. I think you've added a few too many records and modified what Windows adds and manages itself too much, which would explain the loss of connectivity.

I'm unclear what your internal Active Directory domain name is. Is this domain.com too or something else, like domain.local?

I will use domain.local here to refer to the internal Active Directory domain name and domain.com to refer to your externally facing name, but please let me know exactly what you are using.

Whatever happens, within the DNS zone for your AD domain, you should have only one record for the server. It will be an A record which maps the name of the server to its internal IP, 10.0.0.2.

You do not need additional records to map server.domain.local to the external IP. If DNS round robin is enabled, that will wind up returning random DNS records which will lead to inconsistencies in attempting to access the server internally.

If you just have the one Exchange server then you don't need NS records or MX records anywhere in your internal DNS either. Those are unrequired because Exchange takes care of all email handling internally. Email gets routed to it from outside by the MX records at ZoneEdit.com and internally Exchange already knows that it is responsible for emails to domain.com -- it doesn't need to look up an MX record and get pointed back to itself.

So, what you need to do is return anything to do with your internal zone to how it was before, which means removing the additional NS records to ZoneEdit.com, the MX records and any server records which point to the external IP. You will see a bunch of Active Directory related containers and records, such as _msdcs, which should all be left alone.

If your internal Active Directory and external domain names are the same, domain.com, then it gets a little more complicated because you will be managing two DNS zones which, although they have the same name, serve very different purposes. One runs your domain and internal network, the other runs the external.

It would be of great assistance if you could post screenshots of what you have already so I can see exactly what is happening. We'll focus on internal DNS for now, and once that is resolved, we can look at the external DNS issues.

-Matt
0
 
indiglo265Author Commented:
Hi Matt, thanks for your response.

Unfortunately, both AD domain name and external facing name are the same; domain.com.

I am heading back to the office now, and will make the changes you detailed above, and also post the screenshots. I assume you'd like to see my forward and reverse lookup zones?

I have a few questions:
1) I have a pending request with my ISP to point their rDNS records to domain.com, should I follow through with this?
2) should the mx record on ZoneEdit point to domain.com or server.domain.com?

Thanks for your help. I really do appreciate it.
0
 
tigermattCommented:

The forward lookup zone is the key one, but by all means include an image of the reverse one too. We're just not concerned about that one at this stage.

>> I have a pending request with my ISP to point their rDNS records to domain.com

If you want to send email out directly, the rDNS on the IP which the email goes out on should strictly point to the address your server is available at (see next point). This is known as a forward-confirmed reverse DNS entry, and is required to satisfy lots of spam filters these days that your email is indeed legitimate.

>> should the mx record on ZoneEdit point to domain.com or server.domain.com?

The MX record should be created for the host "domain.com", but its data should contain a priority and then the host which your server can be found at. The host needs to be valid in external DNS.

So if you have an A record of server.domain.com at zoneedit.com which resolves to your public IP, say 4.5.6.7, then your MX record should point to server.domain.com. Personally, I would normally create a record called mail.domain.com in my external DNS zone and then put that on the MX record -- it means your external zone is fairly generic and you aren't tying records to server names externally.

The critical distinction here is that you have an internal and external DNS zone with the same name. Any changes you make on your server will not be reflected and cannot be referenced from ZoneEdit, and any changes at ZoneEdit will not be used internally. You must physically create the A record at ZoneEdit which is then referenced in the MX record.

Going back to the rDNS records, whatever you set your MX record to should be what is set in the rDNS. So if you use mail.domain.com in ZoneEdit, get the rDNS record set to the same value. We will also need to ensure your Exchange send connector is announcing itself to the world using the value in the MX record too, but we can do that later.

If you are comfortable with doing so, you can always post your domain name here so that I can remotely look up the DNS records in your external (ZoneEdit) zone. The Moderators can obscure it later to protect your identity once everything has been resolved.

-Matt
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
indiglo265Author Commented:
My domain.com is patricks.org.uk. UKPS01 is the name of my server.

Forward-lookup zone: forwardDNSZoneEdit: zoneedit
I don't fully understand what you are saying concerning the mx records. Wouldn't an A record resolving to my public IP be for domain.com, then forwarded via the router to server; not server.domain.com?
0
 
tigermattCommented:
Okay - your forward lookup zone seems fine to me. We don't need to worry about that at all.

>> Wouldn't an A record resolving to my public IP be for domain.com, then forwarded via the router to server; not server.domain.com?

No problem - this is quite a common misconception so I don't blame you for getting confused!

The MX record is a special type of resource record (DNS speak) which maps a domain name, domain.org.uk, to a list of one or more mail servers which are responsible for handling email sent to that domain.

Right now, you have an MX record created for the subdomain "@". You can think of @ as being domain.org.uk -- it is nothing to do with the @ in email addresses but is rather a short-hand of saying "the current domain". In your Windows DNS, it is equivalent to the (same as parent folder) records.

That MX record is basically telling the world something like this:

"Hey! You want to send an email to bob@domain.org.uk? According to my records, the MX record for bob's domain, domain.org.uk has a host name of ukps01.domain.org.uk, so please open an SMTP session on port 25 to whatever IP ukps01.domain.org.uk resolves to, and the server at that IP will happily oblige and deliver your message to bob. Thank you! Have a good day!"

The first part of all that is fine. Inbound email looks up domain.org.uk and gets your MX record. The MX record has ukps01.domain.org.uk in the host column, so the sender's server knows that whatever IP ukps01.domain.org.uk goes to, that's the IP they need to send the email to.

The next part is the problem. Right now, the host name in the "host" column of the MX record is ukps01. Except, at ZoneEdit, there is no A record called ukps01 which goes to your external IP. So the server sending you an email goes, "hey, he gave me bad information, because nothing is there for ukps01. Nope. Nothing. As far as I go that server must be imaginary -- even if it does exist, I can't find it."

The confusion now steps in because you have a record called ukps01.domain.org.uk on your server, so why can't the world see that? The reason... you actually have two totally isolated DNS namespaces which are called the same name. Unless a workstation is on your network, it will NEVER see the records on your server (and this is a good thing); the ONLY thing it sees is what is at ZoneEdit.com, and right now, the ones at ZoneEdit.com don't have a ukps01 host. You wouldn't want the outside world to use the ukps01 name on your server anyway, because that resolves to the IP 10.0.0.6 which isn't routable by anyone outside your firewall.

This is one of the issues with naming the AD domain the same as the external domain; although it is technically fine, it can be very difficult to get your head around the fact you have two DNS namespaces which can resolve totally different things. You will also run into issues with making www.domain.org.uk work inside your network which we can talk about once email is working.

So... how do you fix it?

You need to create, at ZoneEdit.com, an A record called ukps01 which goes to your public IP.

You also want to update the "host" column on the MX record to read the full name: ukps01.domain.org.uk for completeness, rather than simply the shortened alias.

Once you have allowed for that to propagate, and as long as your Exchange Server is properly configured, you should be able to receive email from outside to your mailbox@domain.org.uk. Once you've made the changes, feel free to let me know and I can run a lookup from here to say if the DNS is sound or not.

Note: none of this affects the A record for "@" you have in place, which makes your website work. This is just an additional A record which goes to the same IP address and tells inbound email where to go.

If you've got any questions, please let me know. This can be difficult stuff when you first start to play around with it.

-Matt

----

Bonus info:

You might ask why we don't just put the IP address right into the "host" column of the MX record itself at ZoneEdit.com. Although this might technically work, it directly contravenes the RFCs which govern how all this stuff works. The RFCs explicitly state, and I quote:
When a domain name associated with an MX RR is looked up and the associated data field obtained, the data field of that response MUST contain a domain name.  That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed.

-- from RFC 5321, Simple Mail Transfer Protocol
0
 
indiglo265Author Commented:
Matt, I can't thank you enough for the help you have provided me. The exchange server is receiving mail now. Thanks again, Steve.
0
 
indiglo265Author Commented:
Fantastic. Thank you!
0
 
tigermattCommented:

Steve, you're welcome. Glad to hear it's working and thanks for the feedback!
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now