About control and edge services

Each of the Private DNS/Enterprise DDI containers are responsible for a unique service which can be logically grouped into two categories—control or edge—describing their relationship to a typical network topology. The services work in tandem to maintain high-availability of DNS while regularly updating information synchronized from the control node's main database.

Control services include the DATA, CORE, and XFR containers.

• The DATA container hosts resource records in the system's main database.
• The CORE container runs the REST API, application web interface server, and the notification subsystems.
• The XFR container provides zone transfer services that enable importing/exporting zone data with other DNS systems via AXFR or IXFR.

Edge services include the DNS, DIST (distribution), and DHCP* containers.

• The DNS container runs NS1's next-generation authoritative DNS server, high-speed caching daemon, and (if applicable) a server for recursive resolution.
• The DIST container keeps a local copy of the main database at the edge of a distributed network.
• The MONITOR container runs NS1’s monitoring probe daemon and makes observations to endpoints for the purpose of DNS traffic steering and notifications.
• The DHCP container runs NS1's DHCP daemon and DHCP server.

The diagram below shows an example network topology in which one data center hosts three sets of control services with two edge nodes hosting (each) two sets of edge services. In a typical Private DNS or Enterprise DDI deployment, one or more instances of the control services are deployed in a single location (the control node/data center) while multiple edge nodes serve DNS and/or DHCP to local clients. 

Note: The MONITOR container is new and not yet included in the diagram below. Monitoring containers are deployed at various vantage points with “line of sight” to endpoints checked via monitoring jobs.

 *DHCP containers are only applicable to NS1 Enterprise DDI installations.

Installing all DATA containers within the same data center or region minimizes replication delay. Keeping the CORE containers proximate to DATA containers reduces connection latency for writes to the main database. While control services are physically separated from edge services, the architecture allows edge services to operate independently from control services.

DIST (distribution) containers keep a local copy of the main (control) database at the edge node. Deploying the DIST container proximate to the DNS, DHCP, and MONITOR containers at the edge node provides local survivability. If the edge containers need to be restarted or redeployed from scratch, they can leverage the local copy of the data from the DIST container to repopulate DHCP configurations, monitoring jobs and feeds, as well as DNS zone and record information.

For examples on how to deploy core and edge services to hosts, refer to the usage information for control-compose.yml and edge-compose.yml found here: https://github.com/ns1/ns1-privatedns/tree/master/docker-compose.