| A/I Orange Book (1.0): An how-to for the realization of a resilient network of self-managed servers | ||
|---|---|---|
| Prev | Chapter 2. Network | Next |
For such a plan to work, a correct organization of the DNS service is crucial.
In the DNS organization it is clear that we need to separate the management level and the users' services level: the network described above needs a clear and unambiguous naming of the various addresses connected to the different interfaces, so as to make it clear which connection we are referring to with a specific name. On the other hand, from the point of view of the users, the less specific the naming system is, the better they will be able to understand that they are dealing with a single "virtual organization". That is to say that the whole infrastructure needs to stay hidden from the eyes of the users that connect to www.domain.org and do not really want to know exactly which server they are connecting to, or whether their mailbox is in Japan or in Brazil.
We have chosen to use a specific domain for the infrastructure part of the network (infra.org in our case) to resolve the address of the various servers and of the non-public services. Since on this domain we do not offer any service to users, we do not need this domain to be public (or in any case publicly known). This separation is by no means an absolute necessity for the system to work, but could be handy to keep things a bit clearer.
This is more or less the structure of our infra.org zone dns record:
infra.org NS ns1.infra.org
ns2.infra.org
ns3.infra.org
ns1.infra.org A 1.2.3.4
ns2.infra.org A 2.3.4.5
ns3.infra.org A 3.4.5.6
mx1.infra.org A 1.2.3.4
mx2.infra.org A 2.3.4.5
mx3.infra.org A 3.4.5.6
server1.infra.org A 1.2.3.4
server2.infra.org A 2.3.4.5
server3.infra.org A 3.4.5.6
server1-vpn.infra.org A 172.16.1.1
server2-vpn.infra.org A 172.16.1.2
server3-vpn.infra.org A 172.16.1.3
It's fairly easy to add aliases to this zone for specific services or roles the server fulfills:
ldap-master.infra.org CNAME server1
The DNS structure of "normal" domains needs to be standardized (i.e. all zones are identical in terms of their dns record), and it substantially implements all the round-robin mechanisms with which the load and traffic are approximately balanced over the various servers.
The common part of the dns record of all the domains is as follows:
public.org NS ns1.infra.org
NS ns2.infra.org
NS ns3.infra.org
public.org MX 10 mx1.infra.org
MX 10 mx2.infra.org
MX 10 mx3.infra.org
www.public.org A 1.2.3.4
A 2.3.4.5
A 3.4.5.6
This practically means that each mail is directed randomly to one of the three
mail servers, and that http requests are distributed at random among the
three webservers. DNS round robin is a quite rough way of
performing load distribution, but it is enough for our purposes.
The only domains that have different dns records are those for which we need to identify the single boxes. This applies both to subsites (www.domain.org/something) specifically assigned to a single box (particularly because of the difficulty of multi-master mysql replication), and to some https services (as webmail). For these reasons the A record of these domains is as follows:
www.domain.org A 1.2.3.4
A 2.3.4.5
A 3.4.5.6
www1.domain.org A 1.2.3.4
www2.domain.org A 2.3.4.5
www3.domain.org A 3.4.5.6
Last but not least, concerning the DNS organization (as we will detail more in depth in the chapter on Apache service), we have decided to centralized all the SSL services on a single domain (e.g. www.domain.org), so as to keep the coeherence of the name detailed on SSL certificates (that is one and one only for each server).