Jump to content

Dns And Mail Security


Recommended Posts

Good Day Everyone,

 

Don't know whether this is the correct forum to be in, but I am going to ask a couple of questions anyways. Please be patient with me, i don't claim to be an expert at this stuff but I think I know just enough to be dangerous/get myself in trouble.

 

Went to DNSstuff .com which allows you to run some, what I think are, informational reports on a domain, etc. Overall my domain passed the tests the DNS Report ran but two tests did not pass. In the "NS" section it told me my DNS server was open and gave me the following info:

 

ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Also, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Also, the bad guys could use your DNS server as part of an attack, by forging their IP address. Problem record(s) are:

 

Server 207.44.236.88 reports that it will do recursive lookups. [test] Server 72.9.224.186 reports that it will do recursive lookups. [test] See this page for info on closing open DNS servers.

 

My question - Should it be open or should it be closed?

 

Second thing was in the mail section that warned me about the SPF record:

 

Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).

 

My question - Should there be one?

 

 

 

Please don't take these questions as an attack on TCH, I ask out of curiousity because of all the crap that goes on with the internet and spam

 

Thanks,

 

Chip

Link to post
Share on other sites

Chip,

 

The SPF record is certainly something we can setup for you. Open a ticket with the help desk and we will configure your DNS entry with an SPF record.

 

For the Open DNS Error, this is something we have intentionally left open. While DNSStuff flags this a a big error, it is highly unlikely that any issues would arise from this. We currently use recursion from some of our servers and so have left this enabled.

 

In the future, we may turn this off as all of our servers are migrated to the new Data Center.

Link to post
Share on other sites

Thanks for the reply Jesse,

 

Is a SPF record a good thing to have setup or is it not nessesary?

 

Recursion is on because some servers are at different TCH controlled DC's, correct?

 

Just asking to learn a little about the backend of this webhosting stuff.

 

 

Thanks again,

 

Chip

Link to post
Share on other sites

>> Is a SPF record a good thing to have setup or is it not nessesary?

 

SPF records are definitely a good thing to have. They help to prevent mail spoofing (ie mail that looks as though it came from your domain) and some mail servers check for it's existence. I've not actually seen mail rejected due to the absence of an SPF record, but they are helpful.

 

>> Recursion is on because some servers are at different TCH controlled DC's, correct?

 

That would be correct. We have left recursion on the DNS servers so that some of our servers in any of the datacenters can perform a lookup as needed.

 

>> Just asking to learn a little about the backend of this webhosting stuff.

 

Feel free to ask, we're all more than happy to answer.

Link to post
Share on other sites
  • 1 year later...

Has the open/recursive server policy been reconsidered/changed with the current cache poisoning alert?

 

I got the same "Fail" message when checking my DNS awhile back, sent a support ticket to TCH and was told it couldn't have anything to do with my intermittant site access problems. I've learned since then that open and recursive servers can cause slow loading and even "cannot find page" errors if a page takes too long to load, which is precisely the problem with my sites. I was told to "run, not walk" if my host didn't understand why the system wasn't a good one. I didn't run, but especially with the new security risk for recursive servers, I'm planning to walk when my accounts come up for renewal next month - unless the policy's been changed.

 

I apologize if the policy has been changed and I didn't see the accouncement.

Link to post
Share on other sites

Let me try to address all the concerns in this topic and I will begin first with the most recent DNS vulnerability disclosed by security researcher Dan Kaminsky. This vulnerability deals with a fundamental protocol flaw with DNS and how the protocol randomizes certain values during the communication process such as the source port of DNS queries and special sequencing ID values, or lack thereof.

 

The vulnerability exposes what we call a potential DNS Cache Poisoning attack, since an attacker can potentially predict certain values of the communication between client and server (you and dns server), they could potentially inject unwanted values into an already established DNS query or forge DNS results against the server which would typically cache those results. For example let us assume we were vulnerable (which we are not and I will show you that in a moment) and you were requesting DNS for totalchoicehosting.com (as you do every time you load this site), an attacker could cause the returned IP results to point to a site of malicious intent which we will for this example call something.com. So when your browser is returned the DNS results, instead of totalchoicehosting.com appearing, you would find yourself sitting at something.com. The real hit from this attack is the way caching works is that your client DNS servers (typically your ISP) would cache this result then hand that same malicious result out to any subsequent requests for it (till it times out). That is the most simplified example I can put forward of this issue and as much knowledge as I do have about DNS, I reserve the right to be slightly incorrect in the above scenario =)

 

Now onto the actual vulnerability of TCH DNS servers, at present we have 6 deployed and public DNS servers, all these servers run on high end hardware and are subject to thousands of queries per minute and maintain that request load with great success and incredibly low resource usage (on the order of less than 0.15% cpu and 40% memory usage day to day). Now the way we can test for the above mentioned vulnerability is with the dig command which shows us a deviation value for the sequencing/port values in a DNS query, a higher deviation per query means the ability to predict a value is that much harder versus a low or zero deviation value means it is easier and as such vulnerable.

 

>execution command is: dig +short @IP porttest.dns-oarc.net txt:

"64.246.50.105 is GOOD: 26 queries in 1.4 seconds from 26 ports with std dev 15462.95"
"65.254.32.122 is GOOD: 26 queries in 1.8 seconds from 26 ports with std dev 19500.80"
"207.44.236.88 is GOOD: 26 queries in 1.4 seconds from 26 ports with std dev 18339.32"
"72.9.224.186 is GOOD: 26 queries in 1.8 seconds from 26 ports with std dev 20698.03"
"204.11.34.66 is GOOD: 26 queries in 1.7 seconds from 25 ports with std dev 18767.98"
"204.11.34.67 is GOOD: 26 queries in 1.7 seconds from 26 ports with std dev 18929.89"

 

As you see above we are running query tests against our 6 DNS servers (the IP's at the beginning of the results) by using a 3rd party DNS testing facility (porttest.dns-oarc.net) and subsequently the results all have a very high deviation value and multiple source ports meaning we are not vulnerable, further you do not need to take my word for it.

 

Now, recursive DNS queries - this is a picky subject and one we have long discussed here at TCH but at the end of the day we find recursive queries to be an advantageous feature to have enabled on our DNS servers as it enables us certain luxuries that otherwise would not be available to our servers running on a very diverse set of networks, not to mention huge performance benefits. Although there are people out there that claim the mere fact of having recursive queries enabled is a sign of a poorly administered DNS server, I would have to argue that recursive queries is simply a feature that facilitates attacks of other underlying administrative issues such as allowing public DNS Zone Transfers (AXFR). We go to great lengths to ensure that our DNS servers have all the appropriate restrictions in place to safe guard not only your domain names hosted with us but to preserve the integrity of the TCH image by not allowing our DNS servers to be used in facilitating external attacks. All the TCH DNS servers only allow zone transfer requests over the local IP address (127.0.0.1) and from trusted clustered client servers (the servers that host your sites) using special RSA based access hashes.

 

I would really enjoy indulging further on this topic but this reply has grown to be much larger than I had initially expected and with that I am going to wrap it up in saying that we take great care in addressing the concerns of our clients and despite all I have said above, as soon as we have completed migrations from all partner data centers into our Troy Michigan facility, DNS recursion will be a thing of the past at TCH. I hope I have adequately addressed the concerns in this topic and if you have any further questions or concerns, please go ahead and reply so I can take a crack at them.

Link to post
Share on other sites

I was looking into this before the recent flurry of excitement. My main concern hasn't been so much the vulnerability to attacks (since that wasn't big news at the time) but the statement in my (dnsreport.com) reports that:

 

This can cause an excessive load on your DNS server.

 

In fact, that's what started my research - the intermittent episodes of "cannot find page on server" errors for both myself and some of my site visitors (lasting from a couple of hours to a couple of days), no matter which browser was being used. I didn't realize when I chose my domain names that a .us TLD would make the sites more prone to this kind of problem because they don't have the "glue" that .com names do. I don't want to change domains at this point in the game, but knowing that my sites are among the first to be affected by too many look-up requests on the server gives me an added interest in the topic.

 

I really don't want to change hosts. It's a headache that I don't need right now, and since my site traffic drops over the summer there haven't been any access problems lately that I know of. I'm very glad to know that open servers will soon be gone at TCH, and will hold my breath and hang on for now.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...