Jump to: navigation, search

Difference between revisions of "Designate/Blueprints/Template"

(Initial Draft Quality Write Up)
(Undo revision 40514 by Kiall (talk))
 
Line 5: Line 5:
 
! Gerrit Patch || []
 
! Gerrit Patch || []
 
|-
 
|-
! Launchpad Blueprint || [https://wiki.openstack.org/wiki/Designate/Blueprints/MiniDNS]
+
! Launchpad Blueprint || []
 
|}
 
|}
  
 
=== Summary ===
 
=== Summary ===
  
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.
+
Quick overview of the change
  
==== Reasoning ====
+
== API Changes ==
  
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:
+
List of changes to the HTTP API
  
# 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.
+
=== One Per Change ===
# 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.
+
{| class="wikitable"
 +
|-
 +
! Verb !! Resource !! Description
 +
|-
 +
| GET || /resource || Description of call
 +
|-
 +
| GET || /resource/{id} || Description of call
 +
|}
  
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.
+
==== Example of Call (HTTP Verb) ====
  
==== High Level Implementation ====
+
Overview of call
  
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:
+
'''Response'''
 +
    {
 +
        “data”: [
 +
            {
 +
                "more":"data"
 +
            }
 +
          ]
 +
    }
  
# 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).
+
== Database Changes ==
# Publish DNS NOTIFY's upon zone changes, triggering an AXFR by the public DNS servers.
+
Description of Changes to DB schemas
  
This service will be implemented in two parts:
+
eg -
  
# A DNS protocol implementation (''Proof of concept code exists'')
+
{| class="wikitable"
# 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.
+
|-
+
! Name!! Data Type !! Length !! Nullable!! Details
==== Advantages ====
+
|-
 
+
| id || VARCHAR || 36 || False || Primary Key, Generated UUID
Immediate Advantages:
+
|-
 
+
| name || VARCHAR || 255 || False || Domain name to be blacklisted
# Transactional zones changes can be performed by simply performing a transactional update to Storage. No two-phase commit protocol is required.
+
|-
# Ensuring all public DNS servers receive all zones changes is simplified to sending N DNS NOTIFY's
+
| version || INTEGER || - || False || Designate API version
# 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.
+
|-
# 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)
+
| created_at || DATETIME ||  -  || False || UTC time of creation
# Backend implementations are reduced to the minimal amount of functionality required to add and remove zones
+
|-
## For BIND9, we can implement this using RNDC over TCP
+
| updated_at || DATETIME || - ||True || UTC time of creation
## For PowerDNS, we can implement this using the same DB interactions as we currently perform.
+
|-
## TODO: Understand how NSD / FreeIPA DNS / Akamai EDNS etc etc would tie-in
+
| description || VARCHAR || 160 || True || UTF-8 text field
 
+
|}
Future Advantages:
 
 
 
With this code in place, we have a solid foundation for additional future features;
 
 
 
# Ability to support RFC2136 (''nsupdate style'') Dynamic DNS updates
 
# Ability to support inbound AXFRs from customers
 
# Ability to DNSSEC sign zones on-demand
 
## 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.
 
# Simplifies the implementation of the [[Designate/Blueprints/Server Pools|Server Pools]] proposal
 
 
 
==== Disadvantges ====
 
 
 
# We have to maintain our own Mini-DNS server.
 
# 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.
 
# 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.
 

Latest revision as of 17:57, 26 January 2014

Overview

Gerrit Patch []
Launchpad Blueprint []

Summary

Quick overview of the change

API Changes

List of changes to the HTTP API

One Per Change

Verb Resource Description
GET /resource Description of call
GET /resource/{id} Description of call

Example of Call (HTTP Verb)

Overview of call

Response

   {
       “data”: [
           {
               "more":"data"
           }
         ]
   }

Database Changes

Description of Changes to DB schemas

eg -

Name Data Type Length Nullable Details
id VARCHAR 36 False Primary Key, Generated UUID
name VARCHAR 255 False Domain name to be blacklisted
version INTEGER - False Designate API version
created_at DATETIME - False UTC time of creation
updated_at DATETIME - True UTC time of creation
description VARCHAR 160 True UTF-8 text field