Designate/Deployment

= Overview =

The Moniker architecture is using an agent to perform DNS changes to DNS Servers. The API communicates with the agents through RPC. This document will look at the implication of this design on the Moniker deployment for multiple scenarios.

= DNS overview =

Without going into the details on how DNS works, for this discussion, we are only interested by the deployment aspect. A typical large scale DNS infrastructure is comprised of :
 * Authoritative Server : Able to provide results for queries on zones that are directly managed by this server
 * Caching Server: Able to provide results on behalf of authoritative servers, and caching the results

Zones and records are configured on the authoritative servers, while only zones need to be configured on the caching servers.

= Deployment Options =

Files only
For example, Bind9.

In this scenario, the Moniker agent need to run both on the authoritative servers and the caching servers. Files need to be updated locally and rndc can be used to reload the zones. Moniker will need to know about all the servers in the infrastructure, potentially differentiating between authoritative and caching servers.

Centralized Authoritative and distributed Caching
For example : PowerDNS with DB/LDAP backend and PowerDNS caching servers.

PowerDNS allows the configuration of the authoritative servers through multiple backends such as a database or LDAP. This option does not require the agent to run on every authoritative servers as the configuration can be performed by a single agent connecting remotely to the DB or LDAP

Today Moniker has a resource per server, in this case, the resource will not be representing the authoritative server but the agent communicating with the DB or LDAP, multiple authoritative servers may share the same backend

However, caching servers will still need to have an agent deployed as they do not read from the backends. This means that to configure the new zones to be cached, their configuration has to be changed. Moniker will have a resource per caching server, and will need to differentiate between authoritative and caching server as their configuration mechanisms are different.

All centralized
For example: Nominum ANS and Vantio

This deployment option uses centralized configuration (through API) both for authoritative and caching servers configuration. The agent would not need to know about every server in the infrastructure, but just the agent performing the configuration requests.

= Conclusion =

The use of an agent to perform the configuration of the DNS infrastructure is bringing advantages compared to an centralized only architecture. To completely support the above use cases, there are two options :
 * The model for distributing the agents is specific to the choice of a backend, in which case, the API should not assume a deployment model and let the backend define the deployment architecture. This will mean that the server resource in the Moniker API should be completely managed by the backend
 * Moniker knows about the different deployment options and manages completely these options. It need to extend the server resource to allow the configuration of the multiple use cases.