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
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.

Reply via email to