DoS of DNS by an Exchange Focused Backup Software (AppAssure Replay)

 Ehlo All,

Imagine to my surprise that my favorite Exchange & Windows backup solution (AppAssure Replay 4.5.1.27532) was attempting to cause a denial of service (DoS). This version has a major problem with it's use of DNS lookups within the problem. Within 3 days, one Replay Server had performed over 450,000 queries of the hostname I used for Replay replication. This is almost 100 queries every minute 24 hours a day. That's what the product is doing. This is a serious issue. I've alerted the vendor, so I'm sure a fix will be included in a future release. In the mean-time, see below for the work-around until that happens.

The Issue
Inside AppAssure's Replay for replication, you specify a "Replication Target Host Name". This can be a hostname or IP address. See below for setting within Replay.

 This "Select Replication Target" configuration is per protected server (e.g. your Exchange Server, etc). I normally use a hostname for these types of settings since I'm a big fan of using DNS instead of IPs when possible (saves time when changing IPs & saves brain memory space for Exchange Server things). So, when you add your Replication Target hostname, the Replication target and source perform lookups more often than the snap-shot period (x min/hrs). In reality, Replay should only perform a DNS lookup when a replication needs to occur and NOT almost a 100 per minute.

AppAssure's Replay abusing DNS lookups. View from my Firewall hostname query  logs.

The Workaround Until a Permanent Fix is Released by AppAssure
If you use a hostname within the Replication option, make sure you add the corresponding information inside the hosts file (c:\windows\System32\drivers\etc\hosts - format is IP address space and hostname - use notepad to open the "hosts" file) on the source AND target Replay Replication Server. This avoids the use of an external DNS query and the query is handled by the operating system. So, this speeds up the process of performing a lookup and reduces your hostname's name server load. Otherwise prepare for your DNS to be attacked by your Replay environment.

Sadly, this isn't the first time I have seen a product mis-use DNS, but it's one of the worst in recent memory.

-Ben

Handy Free Tool to Test Connections to other Mail Servers - Time Saver Tip

Ehlo All,

When you need to test another mail server connection, to make sure it's accepting emails, I normally do the following: RDP to mail server, open telnet, open some ip:25 and then enter in smtp commands and make sure the other mail server accepts the email. I recently heard about a tool that expedites this process by handling DNS lookups, smtp commands, etc. It's called TestMX.

About TestMX. It's a very small free Windows application (command line, but don't be afraid, it's very easy). All you need to do is enter the domain to test, and it handles everything for you. The download is 2 files, help file and the .exe program. Below is what I did. I downloaded TestMX, and ran it against my domain (testmx -dreefsolutions.com). See, so easy. So, let's see what happens.

Play by Play
1) it performs a DNS lookup. It shows my local PC's DNS is 4.2.2.2 and 4.2.2.3.
2) it shows the MX records for reefsolutions.com, which are 3 servers.
3) attempts to connect to the lowest preference number (lower is priority connection). If it fails, the tool is suppose to attempt to connect to next preference number.
4) creates a connection to the MX record it found and is successful since the servers responds with "Spam Be Afraid" which indicates my server would be willing to accept more commands to send an email. This does NOT guarantee an email will be accepted though. It simply is testing that the other server is alive and responding.
5) quits connection.

D:\>testmx -dreefsolutions.com
Testing MX connection with domain reefsolutions.com
Using nameserver 4.2.2.2 4.2.2.3

MX for reefsolutions.com is spamcopcluster1.reefsolutions.com [69.31.40.115]
MX for reefsolutions.com is b.reefsolutions.com [72.68.143.91]
MX for reefsolutions.com is spamcopcluster2.reefsolutions.com [72.68.143.92]
Connecting with spamcopcluster1.reefsolutions.com [69.31.40.115]
Connection established with spamcopcluster1.reefsolutions.com [69.31.40.115]
< 220 Spam Be Afraid
> HELO BlackThunder
< 250 spamcopcluster1.reefsolutions.com Hello static-xx-xx-xx-xx.nycmny.fios.ve
rizon.net [xx.xx.xx.xx], pleased to meet you
> QUIT
< 221 Bye
Connection closed with spamcopcluster1.reefsolutions.com [69.31.40.115]

D:\>

Or, if you want to actually test sending of email you'll need to use an email client or perform the smtp commands by telnet. I recently found a better smtp command site than my old favorite (Microsoft's KB article on the process). Like I said before, the TestMX is only to insure the other mail server responds.

Old School way to test smtp (command by command). Favorite site to explain smtp command sending and is more accurate than the one below.
http://exchangeninjas.com/SpeakSMTP

Old Favorite for testing via smtp commands (XFOR: Telnet to Port 25 to Test SMTP Communication)
http://support.microsoft.com/kb/153119

-Ben