Re: Re[6]: [Declude.JunkMail] DNS Changes
I have to say I also agree with Sandy. While recommending a free external DNS solution like OpenDNS is an easy fix for many less technical customers, as Sandy has pointed out it is not the best solution. 1. The customer has no control over its availability. With a free external DNS solution there is no guarantee it will be available in the future. This is why an internal or pay-for solution is generally a better choice, especially for something as critical as business mail services. 2. There is a performance hit from using external DNS for mail processing. So again, while recommending it may be an easy fix, and may get you many thanks, the above points should always be discussed so the customer understands the implications of using a solution like OpenDNS. While there is a full range of customer knowledge levels and desired depth/control of a technical solution, I would have to agree that running mail servers and use of a technical solution like Declude should require a background knowledge in DNS and SMTP. I would think that being halfway up-to-speed with the technical background necessary is a much worse and dangerous place to be in running these services than either outsourcing or having a deep enough understanding to do something as simple as set up multiple internal DNS servers with recursion turned on. My $0.01. (decreased due to inflation and other financial considerations, plus being mostly a reiteration of points already made) Darin. - Original Message - From: Sanford Whiteman [EMAIL PROTECTED] To: Linda Pagillo declude.junkmail@declude.com Sent: Thursday, October 09, 2008 4:52 AM Subject: Re[6]: [Declude.JunkMail] DNS Changes In a perfect world this would be correct, but as you already know from working in the IT profession, no server, DNS or otherwise has an uptime of 100%. A single physical DNS server may go down, sure, whatever. The DNS config (redundant DNS servers or load-balanced on a virtual IP) used by a mail infrastructure _must_ be 100% as available as the mailservers themselves. I'm certain that everybody on this list who runs a hosting provider or supports a large company completely agrees and has built their infrastructure accordingly. My clients always have DNS resolution -- yes, _100% of the time that they are connected to the internet_ -- as is commonplace in enterprise-class IT (if not in all enterprise IT). It is not so in SMB IT, to be sure, but for your (presumably) SMB clients, we are likelytalkingaboutmakingDNS _as available as a single-point-of-failure MX_. That can mean running caching DNS on the same box. If an admin can't keep a modern DNS daemon running on the mailserver, then their mail should be outsourced. Period. Yes, things may be slowed down a bit by using a DNS server over a WAN, Will certainly be slowed down, no may, let's please be clear about this. but in my experience, it's more reliable to use the OpenDNS servers with Declude because they are configured properly for use of the RBL tests. An OpenDNS server is not more reliable for RBL lookups than local recursive DNS servers. It is more reliable than overloaded ISP DNS servers. That is not the same statement. You'd be suprised how many people i talk to in a week who have very little understanding about the role DNS plays in having these tests work properly. I wouldn't be surprised at all... and I wouldn't be surprised if, nnn months after they magically switch to OpenDNS, they _still_ have very little understanding of DNS and how to troubleshoot SMTP sending and receiving problems. Because you've patched the problem, but you haven't educated them one bit by telling them that DNS -- rather than being the mail-critical, distributed, scaleable, high-performance, learnable, fairly brilliant protocol that it is -- is something they should get from a free provider over the WAN. By the way, I completely support shops that outsource their anti-spam/anti-virus + their mailboxes (and just about everything else) using OpenDNS for web browsing, since otherwise they would have to support their first reliable, recursive DNS server(s). But if you are capable of supporting your own anti-abuse and mailbox servers, _you are capable of supporting a recursive DNS server_. Or you lied about the first part. I don't consider the questions that are asked by our customers as stupid stuff that is not our fault, especially the questions about how DNS plays an important role in our product. But you know very well what I mean by stupid stuff These are the issues you have to deal with that cause collateral damage to the reputation of your product or service, even though you have no direct control over the problem area. In my password example, people with bad memories or unstuck post-it notes are not your fault. But you don't yell
Re: Re[6]: [Declude.JunkMail] DNS Changes
There is also the question of loss of connectivity from point A to OpenDNS server #1 which is all that you have if you setup Declude to use a Single Source DNS server. If anywhere in that path there is an outage you will have no DNS. Far better to learn a little about DNS and run your own. Then you can at least use several other sources even if you care to set it up to use OpenDNS. As for $0.01 I have changed that as of recent events to $0.005 as your 401K has probably gone down that much in recent months. At 09:01 AM 10/9/2008 -0400, Darin Cox wrote: 1. The customer has no control over its availability. My $0.01. (decreased due to inflation and other financial considerations, plus being mostly a reiteration of points already made) - This information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or action taken in reliance on the contents of these documents is strictly prohibited. If you have received this information in error, please notify the sender immediately and arrange for the return or destruction of the document(s). Warning: All e-mail sent to or from this address will be received or otherwise recorded by the Corporate e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: Re[6]: [Declude.JunkMail] DNS Changes
Sandy, I agree with you. While recommending OpenDNS is certainly painless and easy for the support desk, it is certainly not the best solution for an in-house mail server - especially those running anti-spam products. Just my .02 ~Patrick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanford Whiteman Sent: Thursday, October 09, 2008 4:52 AM To: Linda Pagillo Subject: Re[6]: [Declude.JunkMail] DNS Changes In a perfect world this would be correct, but as you already know from working in the IT profession, no server, DNS or otherwise has an uptime of 100%. A single physical DNS server may go down, sure, whatever. The DNS config (redundant DNS servers or load-balanced on a virtual IP) used by a mail infrastructure _must_ be 100% as available as the mailservers themselves. I'm certain that everybody on this list who runs a hosting provider or supports a large company completely agrees and has built their infrastructure accordingly. My clients always have DNS resolution -- yes, _100% of the time that they are connected to the internet_ -- as is commonplace in enterprise-class IT (if not in all enterprise IT). It is not so in SMB IT, to be sure, but for your (presumably) SMB clients, we are likelytalkingaboutmakingDNS _as available as a single-point-of-failure MX_. That can mean running caching DNS on the same box. If an admin can't keep a modern DNS daemon running on the mailserver, then their mail should be outsourced. Period. Yes, things may be slowed down a bit by using a DNS server over a WAN, Will certainly be slowed down, no may, let's please be clear about this. but in my experience, it's more reliable to use the OpenDNS servers with Declude because they are configured properly for use of the RBL tests. An OpenDNS server is not more reliable for RBL lookups than local recursive DNS servers. It is more reliable than overloaded ISP DNS servers. That is not the same statement. You'd be suprised how many people i talk to in a week who have very little understanding about the role DNS plays in having these tests work properly. I wouldn't be surprised at all... and I wouldn't be surprised if, nnn months after they magically switch to OpenDNS, they _still_ have very little understanding of DNS and how to troubleshoot SMTP sending and receiving problems. Because you've patched the problem, but you haven't educated them one bit by telling them that DNS -- rather than being the mail-critical, distributed, scaleable, high-performance, learnable, fairly brilliant protocol that it is -- is something they should get from a free provider over the WAN. By the way, I completely support shops that outsource their anti-spam/anti-virus + their mailboxes (and just about everything else) using OpenDNS for web browsing, since otherwise they would have to support their first reliable, recursive DNS server(s). But if you are capable of supporting your own anti-abuse and mailbox servers, _you are capable of supporting a recursive DNS server_. Or you lied about the first part. I don't consider the questions that are asked by our customers as stupid stuff that is not our fault, especially the questions about how DNS plays an important role in our product. But you know very well what I mean by stupid stuff These are the issues you have to deal with that cause collateral damage to the reputation of your product or service, even though you have no direct control over the problem area. In my password example, people with bad memories or unstuck post-it notes are not your fault. But you don't yell at them, and you don't tell them to rely on somebody else's account. You do the smart thing and reset their password. Likewise for people that can't open their corporate e-mail account because they forgot to plug in their LAN cable when they came back from a trip. You don't hang up on them, and you don't tell to go down to the local coffee shop and use their GMail account. You tell them how to deal with the problem, not how to avoid it. When a customer comes to me in a panic about their mail backing up and causing delays, they are quite happy when we diagnose, fix and educate them about the issue, DNS related or otherwise. I do not see that as bad service. We provide some of the best support available. If you would like to see the thank you letters and cards that i receive each year, i will gladly show them to you. I'm not debating whether people are pleased with your service. I am sure they are pleased as punch to have avoided learning something new and nonetheless brought their mailserver back to life (albeit at lower performance). That does not change the fact that by suggesting that the right thing to do for DNS is use a free service, you are pretending that
re: Re[6]: [Declude.JunkMail] DNS Changes
Sandy, A single physical DNS server may go down, sure, whatever. The DNS config (redundant DNS servers or load-balanced on a virtual IP) used by a mail infrastructure _must_ be 100% as available as the mailservers themselves. I'm certain that everybody on this list who runs a hosting provider or supports a large company completely agrees and has built their infrastructure accordingly. Sandy, i agree on the importance of having a well-designed DNS server in a network infrastructure. You and I are both intelligent and experienced enough to realize that although both of us feel this way, it does not mean that people want to take the time to educate themselves accordingly to implement one, no matter how simple a task. There is not much we can do about this. My clients always have DNS resolution -- yes, _100% of the time that they are connected to the internet_ -- as is commonplace in enterprise-class IT (if not in all enterprise IT). It is not so in SMB IT, to be sure, but for your (presumably) SMB clients, we are likely talking about making DNS _as available as a single-point-of-failure MX_. That can mean running caching DNS on the same box. If an admin can't keep a modern DNS daemon running on the mailserver, then their mail should be outsourced. Period. It is great that your clients always have DNS resolution. Unfortuantley this is not true of many Declude customers. The issue here is not how much you know but rather how educated our customers are. Sandy, we talking old school vs noobs. We cannot spend the time explaining DNS to certain customers who barley know how to get a cmd prompt. In this case the suggestion to use a reliable external DNS. This is the best we can do. If you would like to take the time to educate these users feel free. I can certainly direct them to the lists or you personally. Yes, things may be slowed down a bit by using a DNS server over a WAN, Will certainly be slowed down, no may, let's please be clear about this. Excuse me, things WILL be slowed down by using a DNS server over a WAN. However, where our product is concerned, a slow-down is much better than a serious backup of email which we see almost everyday due to in-house DNS server issues. An OpenDNS server is not more reliable for RBL lookups than local recursive DNS servers. It is more reliable than overloaded ISP DNS servers. That is not the same statement. You are correct. In all cases, a local, recursive DNS server is a better choice. However, An OpenDNS server is more reliable in running the RBL tests than having an in-house DNS server that is configured incorrectly and frankly, the truth is, it's not our job to teach people how to set up, run or manage a DNS server. I wouldn't be surprised at all... and I wouldn't be surprised if, nnn months after they magically switch to OpenDNS, they _still_ have very little understanding of DNS and how to troubleshoot SMTP sending and receiving problems. Because you've patched the problem, but you haven't educated them one bit by telling them that DNS -- rather than being the mail-critical, distributed, scaleable, high-performance, learnable, fairly brilliant protocol that it is -- is something they should get from a free provider over the WAN. I educate all of our customers who are having DNS issues. I explain how DNS works with Declude and why a working, properly configured, recusrive, in-house server would be better to use (faster and more controllable). After hearing a hundred times a month that they do not want to or do not have the time to set one up, i start feeling like my lessons are falling on dead ears. Most of our customers don't care about how it works. They simply want it to work. When i tell them about how recursive DNS servers work with Declude, they ASK ME if i know of any open dns servers that will do this. What would you like us to do? We can't force our users to listen, and we surely will not force them to use an in-house DNS server. By the way, I completely support shops that outsource their anti-spam/anti-virus + their mailboxes (and just about everything else) using OpenDNS for web browsing, since otherwise they would have to support their first reliable, recursive DNS server(s). But if you are capable of supporting your own anti-abuse and mailbox servers, _you are capable of supporting a recursive DNS server_. Or you lied about the first part. Alot of our customers were thrown into the job of running their own mail servers and they are learning as they go. There are plenty of different circumstances which cause this to happen and i'm sure you're aware of that. But you know very well what I mean by stupid stuff These are the issues you have to deal with that cause collateral damage to the reputation of your product or service, even though you have no direct control over the problem area. In my password example, people with bad memories or unstuck post-it notes are not your fault. But you don't yell at them,
RE: Re[6]: [Declude.JunkMail] DNS Changes
Thanks Kevin. I will be sure to pass this info on to the customers that i speak
with.
From: Kevin Bilbee [EMAIL PROTECTED]
Sent: Thursday, October 09, 2008 2:19 PM
To: declude.junkmail@declude.com
Subject: RE: Re[6]: [Declude.JunkMail] DNS Changes
I have a suggestion since DNS is so critical to Declude. A secure recursive
bind implementation can be setup in less than 5 minutes.
How is this difficult? There is no learning DNS.
Steps - Tested with Bind 9.5.0-P2 Windows XP/2003/2008 Binary Kit
1) Download BIND
http://www.isc.org/index.pl?/sw/bind/index.php
2) Install Bind
a. Unzip and run BINDInstall.exe
b. Give the service account a strong password
c. Do not start bind service after install
3) Configure Bind
a. Go to c:\windows\system32\dns and give the service account named
read\write permissions to the etc folder
b. Place the attached files into the etc folder.
c. Open a command propmt
i. CD to
c:\windows\system32\dns\bin
ii. Run
rndc-confgen -a
d. Change the first line of the named.conf file to your IP range that
needs recursive DNS. I would use the ip address of the mail server and
12.0.0.1. change the 169.14.238.0/24 to the IP of your mail server.
acl dmz { 169.14.238.0/24; 127.0.0.1; };
4) Start bind and make some queries
This process takes less than 5 minutes. You now have a reliable easily
upgradeable recursive DNS dedicated to your mail server.
Kevin Bilbee
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Linda Pagillo
Sent: Thursday, October 09, 2008 8:47 AM
To: declude.junkmail@declude.com
Subject: re: Re[6]: [Declude.JunkMail] DNS Changes
Sandy,
A single physical DNS server may go down, sure, whatever. The DNS
config (redundant DNS servers or load-balanced on a virtual IP) used
by a mail infrastructure _must_ be 100% as available as the
mailservers themselves. I'm certain that everybody on this list who
runs a hosting provider or supports a large company completely agrees
and has built their infrastructure accordingly.
Sandy, i agree on the importance of having a well-designed DNS server in a
network infrastructure. You and I are both intelligent and experienced enough
to realize that although both of us feel this way, it does not mean that people
want to take the time to educate themselves accordingly to implement one, no
matter how simple a task. There is not much we can do about this.
My clients always have DNS resolution -- yes, _100% of the time that
they are connected to the internet_ -- as is commonplace in
enterprise-class IT (if not in all enterprise IT). It is not so in
SMB IT, to be sure, but for your (presumably) SMB clients, we are
likely talking about making DNS _as available as a
single-point-of-failure MX_. That can mean running caching DNS on the
same box. If an admin can't keep a modern DNS daemon running on the
mailserver, then their mail should be outsourced. Period.
It is great that your clients always have DNS resolution. Unfortuantley this is
not true of many Declude customers. The issue here is not how much you know but
rather how educated our customers are. Sandy, we talking old school vs noobs.
We cannot spend the time explaining DNS to certain customers who barley know
how to get a cmd prompt. In this case the suggestion to use a reliable external
DNS. This is the best we can do. If you would like to take the time to educate
these users feel free. I can certainly direct them to the lists or you
personally.
Yes, things may be slowed down a bit by using a DNS server over a
WAN,
Will certainly be slowed down, no may, let's please be clear about
this.
Excuse me, things WILL be slowed down by using a DNS server over a WAN.
However, where our product is concerned, a slow-down is much better than a
serious backup of email which we see almost everyday due to in-house DNS server
issues.
An OpenDNS server is not more reliable for RBL lookups than local
recursive DNS servers. It is more reliable than overloaded ISP DNS
servers. That is not the same statement.
You are correct. In all cases, a local, recursive DNS server is a better
choice. However, An OpenDNS server is more reliable in running the RBL tests
than having an in-house DNS server that is configured incorrectly and frankly,
the truth is, it's not our job to teach people how to set up, run or manage a
DNS server.
I wouldn't be surprised at all... and I wouldn't be surprised if, nnn
months after they magically switch to OpenDNS, they _still_ have very
little understanding of DNS and how to troubleshoot SMTP sending and
receiving problems. Because you've patched the problem, but you
haven't educated them one bit by telling them that DNS -- rather than
being the mail-critical, distributed, scaleable, high-performance
