Jump to: navigation, search


< Designate‎ | Blueprints
Revision as of 17:56, 26 January 2014 by Kiall (talk | contribs) (Initial Draft Quality Write Up)


Gerrit Patch []
Launchpad Blueprint [1]


The intent of this blueprint is to describe the reasoning for, advantages and disadvantages of implementing a "Mini DNS" server directly in Designate. Low-level Implementation details will not be discussed.


Designate's current "Backends" implementation is flawed, leaving many opportunities for for Designate and a Backend to become out of sync, and being excessively complex to implement certain kinds of Bakends (For example: writing BIND9 zonefiles to N DNS servers). The reasons for these failings can be broken down into two core ideas:

  1. Designate does not perform Backend operations transactionally. Implementing a two-phase commit protocol spanning Storage and Backends has been attempted in the past, the complexity of such a solution for non database based backends (BIND9, NSD etc) introduced a significant amount of complexity, and to be truly reliable, would require a fix to reason #2 below.
  2. Non-Database based Backends (for example BIND9) require that each change is applied to each and every DNS server, and that the changes are applied in the same same order across all servers. Designate currently lacks a reliable way to perform either of these tasks. Additionally, any implementation would be required to behave correctly under the two-phase commit protocol discussed above.

Most solutions to both of those problems are prohibitively complex. While the Mini-DNS proposal is certainly complex, it provides several additional advantages that no other solution provides. The additional features Mini-DNS can allow for make the complexly acceptable.

High Level Implementation

Designate will implement a Mini-DNS server capable of handling a very limited number of DNS operations, from a pre-defined list of "Supported DNS clients". End user QUERY's will not be processed by this service. Initially, this service will perform two core tasks:

  1. Provide an AXFR source for the public DNS servers. This involves accepting both SOA and AXFR QUERY's from a known sub-subset of supported DNS servers (BIND9, PowerDNS, NSD etc).
  2. Publish DNS NOTIFY's upon zone changes, triggering an AXFR by the public DNS servers.

This service will be implemented in two parts:

  1. A DNS protocol implementation (Proof of concept code exists)
  2. A new designate-master service. This service will act as what is commonly called a "Hidden" or "Stealth" nameserver. Listening for AXFR QUERY's and sending NOTIFY's.


Immediate Advantages:

  1. Transactional zones changes can be performed by simply performing a transactional update to Storage. No two-phase commit protocol is required.
  2. Ensuring all public DNS servers receive all zones changes is simplified to sending N DNS NOTIFY's
  3. Ensuring zone changes are applied on all public DNS servers in the appropriate order is no longer an issue, AXFR's resolve this issue with no additional work on our part.
  4. Zone changes are applied to the public DNS servers asynchronously, and DNS's in-built zone refresh interval ensures eventual consistency in the case of a missed updated (i.e. a nameserver was down during the change)
  5. Backend implementations are reduced to the minimal amount of functionality required to add and remove zones
    1. For BIND9, we can implement this using RNDC over TCP
    2. For PowerDNS, we can implement this using the same DB interactions as we currently perform.
    3. TODO: Understand how NSD / FreeIPA DNS / Akamai EDNS etc etc would tie-in

Future Advantages:

With this code in place, we have a solid foundation for additional future features;

  1. Ability to support RFC2136 (nsupdate style) Dynamic DNS updates
  2. Ability to support inbound AXFRs from customers
  3. Ability to DNSSEC sign zones on-demand
    1. Consider the possibility of having multiple views of a DNS zone (The most common example of this is for split horizon). Without on-demand signing, every possible view of a zone must be pre-signed.
  4. Simplifies the implementation of the Server Pools proposal


  1. We have to maintain our own Mini-DNS server.
  2. The core DNS RFC's are simple, but have been extended so many times that being truly compliant will all DNS RFC's is hard.
  3. Some DNS clients are buggy, send dodgy or corrupt data, or otherwise misbehave. As the number of use-cases for Mini-DNS grows from AXFR -> publicly accessible services, the requirement to gracefully handle these bugs will increase the complexity of the implementation.