If you would like to read the other parts in this article series please go to:
- Managing SPF and reverse DNS in Exchange Server (Part 1)
- Managing SPF and reverse DNS in Exchange Server (Part 3)
Introduction
In the previous article, we covered the SPF record and on this second article of our series, we will start with the basics of reverse DNS, and we will wrap the series up with some hints to increase security on the firewall and a Q&A about SPF and reverse DNS.
Managing Reverse DNS…
When the topic is message outbound to the Internet from on-premises Exchange Servers, or even for organizations using Exchange Online Protection, the recommendation is always to have reverse DNS configured for SMTP Traffic.
We can use the scenario depicted on Figure 01, where we have a single Exchange Server using a Firewall with one or more external interfaces and those interfaces have several Public IP addresses that are available to use.
Figure 01
It boils down to how your firewall manages the Public IP addresses, in some firewalls (Including the TMG) the primary IP (in that case 99.99.99.99) is the one used if there is nothing configured, which means that SMTP and all other internal traffic that is not part of a special rule will use that same Public IP address.
We will add more thought on the Firewall portion in the third article of this series.
Finding out your Public IP in use by SMTP traffic…
The first step is to find out which Public IP address your Exchange Server(s) are using when they go to the Internet. The first attempt could be using any site to check your Public IP (Figure 02), an easy to remember site is http://IPChicken.com, in the first page we will have the Public IP address and the name address associated to that IP.
Figure 02
However, using just that website is not a final answer for a couple of reasons: some administrators configure NAT based on protocols, which means that a specific Public IP address could be used just for web surfing and not be the same for SMTP communications for instance. Another possibility is for companies that use web proxy, so that Public IP probably is from the Web Proxy server and not the one that is being used for SMTP.
The best way is using telnet utility from your Exchange Server(s), we just need to connect on any external SMTP server and run ehlo SMTP verb, and the answer for that will contain the public IP that it is in use by that connection. The entire process is depicted in Figure 03.
Figure 03
If you do not remember how to find a MX record for a domain, you can use the following commands from the Exchange Server and for this exercise the domain chosen was Microsoft.com, as follows:
Nslookup
Server 8.8.8.8
Microsoft.com
Quit
Now that you have the MX record information, you can connect to the name provided (in early 2015, this was the MX record for the Microsoft.com domain).
telnet Microsoft-com.mail.protection.outlook.com 25
Configuring reverse DNS…
There are two type of zones in DNS: forward and reverse lookup zones. The forward lookup zones we use every day, a brief example is when we search a website like www.msexchange.org, and in simple terms the forward lookup zone will be queried and an IP retrieved which will allow the client to get the page (you have just done that by the simple fact of loading this article on your browser).
The forward lookup zones is the one that you are accustomed to manage your pages on the Internet, and all these type of records are created on a forward lookup zone: A, CNAME, MX, TXT, SRV and so forth. Some companies have Public DNS zones managed on servers located in their DMZ, and other prefer to host them on big providers that usually are the same that sell domain registrations, the DNS is part of the package.
The reserve is a different story, the client provides an IP and a name will be returned. Because DNS is distributed we cannot have zones using the same format as forward zones, otherwise the search time would be time consuming and not efficient at least. To avoid this issue, the reverse DNS zones use the order of the three octets of the Public IP, and they always end in in-addr.arpa. Here is a piece of important information, by definition when you get a new Public IP, it is your Internet Provider (ISP) that has access to the zone in the first place, you cannot go there and create a reverse zone out of thin air and expect it to work, that is the most important take away of this article.
If your Public IP range is smaller than a class C, then your zone will be something like this x/x.y.z.in-addr.arpa or x-x.y.z.in.addr.arpa format. It seems complex at the beginning but fear not, because when you are in the process of being responsible of your reverse zone, the ISP provider will give you the required information.
There are a couple of ways to configure reverse DNS and it depends of your design and your requirements, here are the three most common ways to manage reverse DNS:
- Option A: If you have a small environment, you can call your ISP provider and request for them to create the reverse entry for you. You will ask the ISP team to create a PTR record for the desired IP pointing out to the dns name (something like mail.company.ca)
Note: Some providers will say that they cannot perform this work and they will try to sell you Option B below. However, if you insist a little bit longer, then usually get it done. Make sure that you explain to them that this kind of change is rare and you do not want to build an infrastructure for a single name and yada, yada, yada.
Note #2: In some countries (especially South America and Central America) it may take a while to get it done on the ISP side, my personal worst experience was a 2 weeks waiting time in Argentina. - Option B: sub-delegate the reverse lookup zone from your ISP provider to a DNS Server/Service. In this scenario, the ISP will delegate the reverse zone to your DNS server and from that point on you can create your own PTR records and update them whenever you like.
If your decision is to create a couple of DNS servers in your DMZ, the recommendation here is to make sure that you plan well and make sure that you have a resilient solution in place. Having a DNS in-house is not a technical challenge but to keep it running at all times involves more planning, such as at least two links of Internet, datacenter infrastructure to avoid fault domains and so forth. If you want to have the reverse on your control, the recommendation is to use DNS providers on the Internet where you just manage the reverse zone as a service. - Option C: this option applies only for environments hosted on datacenter co-locations, since this type of facility controls everything including internet links, they usually offer a web console where the costumer can change their reverse DNS zone.
Conclusion
In this article, we went over the process to configure the reverse DNS in Exchange Server. In our final article of this series, we will continue discussing the reverse DNS, firewall and a small Q&A about the main topic of this series.
If you would like to read the other parts in this article series please go to:
