[afnog] Best Practices

[Phil Regnauld]

Mike Barnard (mike.barnardq) writes:
> 
> Mail needs DNS, combining the two *may not* be bad though it depends on the
> kind of traffic you will realise for each service.
> 
> LDAP and Database can do together.
> 
> just do not put an LDAP database on a publicly visible database server.

    At least not a read write version :)  But yes, there's no reason
    why external users should be able to access the LDAP.

    > > I have to configure a number of servers including DNS, LDAP, Mails,
    > > Database, Security (antivirus, authentication) for about 2000 users and was
    > > wondering which ones I could bundle together in one server and have
    > > a failover of them.

    Benjamin:

    In terms of network architectures, you'll want to split out the
    services, but also think how to place your servers with regards
    to access levels -- sensitive servers such as authentication and
    email storage probably should not be publicly visible.  For instance
    you could split the mail service into two: delivery/relay, and a
    backend storage that only allowed POP/SMTP/IMAP from the frontend [3] --
    but that might be overkill for 2000 users.

    A possible architecture might be something like this:

    +--------------+--
    |              |
    |            [DNS-S] offsite slave DNS [1]
{internet}
    |                           [3]
    |        [1]          mail frontend +     [2]           [4]
    |  local slave DNS  relay & scanning  LDAP replica   SQL replica
    |      [DNS-S]      [POP/IMAP/SMTP]    [LDAP-S]        [SQL-S]
    |         |               |               |              |
   [FW]-------+---------------+---------------+--------------+--- DMZ / CSN
    |
    |       [1]
    |    hidden SOA     [3]         [2]        [4]
    |      [DNS-M]   [MAILSTORE] [LDAP-M]    [SQL-M]
    |         |          |           |         |
    +---------+----------+-----------+---------+-- Internal network
    
    [FW] is the firewall/packet filter/router of your choice.  Basic
    policy: don't allow traffic from outside to inside, limit selected
    services from outside to DMZ, and from DMZ/CSN to inside.

    [1] DNS slaves pull zones from the hidden SOA/Master -- technically
    "pull" could be rsync from the master so you didn't have to open in
    your firewall traffic from the outside.  Or you could limit traffic
    from the DMZ/CSN (Common Services Network) to the Internal network,
    and make the offsite slave AXFR from the DMZ one (chained).

    [2] You don't really need an LDAP replica on your DMZ, and there
    are security implication to having authentication information stored
    there, but it does provide you with a failover instance you can convert
    to read-write if the master fails, and it provides LDAP service
    locally, avoiding unnecessary traffic across the firewall.

    [3] As described above, you could split your mail into two pieces,
    and even have two dedicated SMTP instances on the DMZ server, one for
    inbound, one for outbound -- this allows to maintain separate mail
    queues when mail floods hit, and privilege outgoing mail for example --
    also, do scanning only on the external instance, and let the mailstore
    be a simple POP/IMAP box with lots of disk.

    There are many ways to do this..

    [4] Same considerations as for the LDAP bit.

    The view above is a logical one.  You could bundle services together,
    and typically I'd avoid putting interdependent (Mail and DNS, LDAP and Mail,
    etc...) ones on the same instances (virtual, jail/vserver, physical)
    
    Do NOT mix I/O intensive applications together -- i.e.: mail scanning
    will typically hammer your disks, so don't mix that and SQL, if your SQL
    has lots of writes.  DNS, LDAP and SQL might fit well together in a
    "information store" group, though do consider to split them up using
    vserver or jails -- it might be extra overhead, but it gives you more
    freedom to upgrade and rollback.