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, 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. I understand your example, but re-setting a password and running a DNS server are two completely different things. Especially when it would be the support tech resetting the password vs. end user who would have to set up the DNS server. People these days want everything done for them. They do not have the time or do not want to make the time to do it themselves. I do not mind educating people, but again, when it comes to actually "doing" something about it, most people would rather us just "get it working". If you worked here for one week, you would completely understand what i'm saying. Again.. it's not our job to teach people how to set up, run or manage a DNS server. <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 DNS is not a necessary skill area for a mail admin, <and *that is ridiculous*. These days people do not want to learn or know the inner-workings of every piece of software they have. This has been proven to me time and time again when i try to explain the functionallity of Declude and i'm cut off in a middle of a sentence with "i don't care how it works, as long as my customers are not getting spam, i'm happy". As i said above.. most people i deal with are not old-school. They are the new crowd who "just want a product that works". I start to feel like i'm wasting THEIR time by trying to educate them when they don't care to hear the lesson. I'm sure you can understand the frustration that goes along with that. <These are DECLUDE users we are talking <about! Yours is not a tremendously user-friendly product in the <anti-spam scene. Its powers are rich and at times obscure. Maybe some <people can get by with the defaults for a while; eventually, that will <not suffice. And if they want to understand how to optimize their <anti-abuse defenses, they *must* understand TCP/IP, SMTP, MIME, and <DNS. Otherwise, they should be outsourcing -- perhaps to a <Declude-powered provider. I agree that if you are an IT professional, it's imperitive to know how TCP/IP, SMTP, MIME, and DNS work. Unfortunately, this is not the case with all people. <I will say it again: if you're outsourcing everything else, by all <means use OpenDNS. But if you are keeping your anti-abuse and mailbox <solutions on-premises, and you are using as technical a solution as <Declude for the former, running away from DNS is plain foolish. I will <"always" disagree with your steering people to "always" use OpenDNS <the moment they encounter a DNS problem. Again, i always recommend OpenDNS these days because no one wants to listen when i try to educate them on the importance of an in-house, recursive DNS server. Disagree if you like, but until you've spent some time in my shoes, having your lessons fall on dead ears, please do not judge my support tactics. > how many people i speak with who do not have the recursive option > set on their DNS servers... <Yeah, that would surprise me utterly, since they wouldn't be able to <do _anything else_ with said servers that would lead them to believe <they were suitable for Declude's use. I worked for an ISP for a long time before joining Declude. DNS servers are NOT useless without the recursive DNS option turned on. I don't know where you're getting your information, but it is incorrect. > ... even more so, they are using their ISP's DNS server and the ISP > does not allow recursive lookups because of the high traffic. <Very well, in these cases the problem is not that they can't keep <their own DNS up, it's that _they haven't tried_. And they won't ever <try if they skip to OpenDNS. Again, we can't force people to run their own DNS server. > We have no bearing on how people choose to run their business or > educate their employees. <Of course you do! The way internal IT people interact with product <support, and vice versa, is absolutely part of the definition of IT <competence. Everyone who has seen the pros and cons of reliance on <outside support knows this. Every single blithering, delusional fake <that I have had the misfortune of dealing with in this industry has a <characteristic tic: they will not learn for themselves what should be <their core competencies. Sandy, i can talk and educate until i'm 90 years old and blue in the face, but this DOES NOT mean that people listen. If people listened, there would be no reason to offer them the option of an OpenDNS server. I can't force them to listen and learn. > I will work on getting a few articles together next week. If you > would like to contribute your extensive knowledge of DNS, shoot me > an email at [EMAIL PROTECTED] and i will glady add your > information. <I may do that. I'm looking forward to it! ---------------------------------------- From: "Sanford Whiteman" <[EMAIL PROTECTED]> Sent: Thursday, October 09, 2008 4:44 AM To: "Linda Pagillo" <declude.junkmail@declude.com> 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 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. > 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 DNS is not a necessary skill area for a mail admin, and *that is ridiculous*. These are DECLUDE users we are talking about! Yours is not a tremendously user-friendly product in the anti-spam scene. Its powers are rich and at times obscure. Maybe some people can get by with the defaults for a while; eventually, that will not suffice. And if they want to understand how to optimize their anti-abuse defenses, they *must* understand TCP/IP, SMTP, MIME, and DNS. Otherwise, they should be outsourcing -- perhaps to a Declude-powered provider. I will say it again: if you're outsourcing everything else, by all means use OpenDNS. But if you are keeping your anti-abuse and mailbox solutions on-premises, and you are using as technical a solution as Declude for the former, running away from DNS is plain foolish. I will "always" disagree with your steering people to "always" use OpenDNS the moment they encounter a DNS problem. > how many people i speak with who do not have the recursive option > set on their DNS servers... Yeah, that would surprise me utterly, since they wouldn't be able to do _anything else_ with said servers that would lead them to believe they were suitable for Declude's use. > ... even more so, they are using their ISP's DNS server and the ISP > does not allow recursive lookups because of the high traffic. Very well, in these cases the problem is not that they can't keep their own DNS up, it's that _they haven't tried_. And they won't ever try if they skip to OpenDNS. > We have no bearing on how people choose to run their business or > educate their employees. Of course you do! The way internal IT people interact with product support, and vice versa, is absolutely part of the definition of IT competence. Everyone who has seen the pros and cons of reliance on outside support knows this. Every single blithering, delusional fake that I have had the misfortune of dealing with in this industry has a characteristic tic: they will not learn for themselves what should be their core competencies. > I will work on getting a few articles together next week. If you > would like to contribute your extensive knowledge of DNS, shoot me > an email at [EMAIL PROTECTED] and i will glady add your > information. I may do that. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ --- 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. --- 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.
