Merge "The New Agent"
This commit is contained in:
commit
8afd19fc20
|
@ -0,0 +1,316 @@
|
||||||
|
..
|
||||||
|
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
=============================
|
||||||
|
New Agent
|
||||||
|
=============================
|
||||||
|
|
||||||
|
This spec describes a proposed service for Designate, tentatively called the
|
||||||
|
"Agent," not to be confused with the current component with the same name.
|
||||||
|
|
||||||
|
Terminology
|
||||||
|
===========
|
||||||
|
|
||||||
|
+----------+---------------------------------------------+
|
||||||
|
| Term | Meaning |
|
||||||
|
+==========+=============================================+
|
||||||
|
| AXFR | A DNS zone transfer |
|
||||||
|
+----------+---------------------------------------------+
|
||||||
|
| NOTIFY | A DNS protocol to inform of a zone update |
|
||||||
|
+----------+---------------------------------------------+
|
||||||
|
| OPCODE | Part of a DNS message that informs action |
|
||||||
|
| | http://bit.ly/1pfG8Zp |
|
||||||
|
+----------+---------------------------------------------+
|
||||||
|
| Backend | Different code paths for various DNS servers|
|
||||||
|
+----------+---------------------------------------------+
|
||||||
|
| MiniDNS | Designate component in charge of sending |
|
||||||
|
| | NOTIFYs, and answering AXFRs. |
|
||||||
|
+----------+---------------------------------------------+
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
MiniDNS provides a very elegant solution for many DNS installations. Having a
|
||||||
|
Designate component as the DNS master enables Designate to have a great amount
|
||||||
|
of control over the DNS server, and makes certain processes much easier to
|
||||||
|
implement across backends.
|
||||||
|
|
||||||
|
However, some deployments may not be able to use MiniDNS as a true DNS Master,
|
||||||
|
and would rather keep the current style of backends in some form with the added
|
||||||
|
benefits of MiniDNS. They might need a more specialized type of interaction
|
||||||
|
between Designate and the DNS server, making Designate more flexible.
|
||||||
|
Additionally, there are potential problems with having MiniDNS and it's database
|
||||||
|
being a single point of failure for a DNS infrastructure.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
An agent deployed on the Master DNS server that interacts with MiniDNS solves
|
||||||
|
these problems. A plugable backend that enables users to use any backend with
|
||||||
|
MiniDNS, as well as the ability to isolate MiniDNS from being a master in
|
||||||
|
large deployments are much simpler with an Agent.
|
||||||
|
|
||||||
|
The Agent would be a standalone service that acts as a sort of mirror to
|
||||||
|
MiniDNS. It would receive AXFR/IXFR, NOTIFYs, and other notifications and
|
||||||
|
perform changes to the DNS server through a plugin-style backend.
|
||||||
|
|
||||||
|
Pool Manager Changes
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
A new backend for the Pool Manager would be created for the Agent.
|
||||||
|
It should send fire-and-forget DNS messages with classes and RRTYPE intended for
|
||||||
|
private use, shown here: http://bit.ly/1soCZTffor on Creates/Deletes, and call
|
||||||
|
into MiniDNS as it would normally for updates.
|
||||||
|
|
||||||
|
Agent Changes
|
||||||
|
-------------
|
||||||
|
|
||||||
|
The agent service will need to be created (possibly supplanting the old "agent")
|
||||||
|
|
||||||
|
The structure will be very similar to MiniDNS. A service (TCP, rather than RPC)
|
||||||
|
will listen for TCP and UDP traffic. NOTIFYs and AXFRs will be handled, along
|
||||||
|
with regular DNS queries (via pass through to the real DNS server), and the
|
||||||
|
special DNS CLASSES and RRDTYPEs that are chosen to signify Creates and Deletes.
|
||||||
|
DNS traffic will result in calls into the configured backend. A special OPCODE,
|
||||||
|
14 will be used for all non-standard actions like Creating and Deleting zones.
|
||||||
|
|
||||||
|
Configuration
|
||||||
|
^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
+--------------------------+-------------+--------------+--------------------------------------------------------------------------------------------------------+
|
||||||
|
| **Parameter** | **Default** | **Required** | **Notes** |
|
||||||
|
+==========================+=============+==============+========================================================================================================+
|
||||||
|
| *backend_driver* | 'None' | Yes | The name of the backend driver to use with the Agent |
|
||||||
|
+--------------------------+-------------+--------------+--------------------------------------------------------------------------------------------------------+
|
||||||
|
| *workers* | None | No | The number of worker processes to spawn |
|
||||||
|
+--------------------------+-------------+--------------+--------------------------------------------------------------------------------------------------------+
|
||||||
|
| *masters* | [] | Yes | List of IP/Ports of Masters the Agent will query for AXFRs and SOA queries |
|
||||||
|
+--------------------------+-------------+--------------+--------------------------------------------------------------------------------------------------------+
|
||||||
|
| *allow-notify* | [] | Yes | List of IP/Ports of Masters allowed to NOTIFY/AXFR with the Agent |
|
||||||
|
+--------------------------+-------------+--------------+--------------------------------------------------------------------------------------------------------+
|
||||||
|
| *host* | '0.0.0.0' | Yes | Bind host for the Agent |
|
||||||
|
+--------------------------+-------------+--------------+--------------------------------------------------------------------------------------------------------+
|
||||||
|
| *port* | 5354 | Yes | Port to bind to |
|
||||||
|
+--------------------------+-------------+--------------+--------------------------------------------------------------------------------------------------------+
|
||||||
|
| *tcp_backlog* | 100 | Yes | TCP backlog for the Agent |
|
||||||
|
+--------------------------+-------------+--------------+--------------------------------------------------------------------------------------------------------+
|
||||||
|
|
||||||
|
There would also be sub-configuration sections for the different backends, using
|
||||||
|
the form [agent:backend_name]. These would be mostly ported from the current
|
||||||
|
backends.
|
||||||
|
|
||||||
|
Service
|
||||||
|
^^^^^^^
|
||||||
|
|
||||||
|
Initialization of the service, and basic handling of TCP/UDP traffic. Does some
|
||||||
|
validation on the traffic coming in, making sure it is valid before sending on
|
||||||
|
to the core application logic. This should be mostly taken from
|
||||||
|
designate/mdns/service.py
|
||||||
|
There could be some optimization, since the Agent will be talking only to mdns.
|
||||||
|
|
||||||
|
Middleware
|
||||||
|
^^^^^^^^^^
|
||||||
|
|
||||||
|
A thin middleware that sits between the TCP message receiving, and the handler.
|
||||||
|
Allows for contexts or other metadata to be attached to a request before it goes
|
||||||
|
to a handler.
|
||||||
|
|
||||||
|
Handler
|
||||||
|
^^^^^^^
|
||||||
|
|
||||||
|
The handler will take DNS requests in, and take the appropriate action. This
|
||||||
|
will be very similar to mdns/handler.py
|
||||||
|
|
||||||
|
_handle_update(request, op)
|
||||||
|
"""""""""""""""""""""""""""
|
||||||
|
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
| **Parameter** | **Description** | **Required** |
|
||||||
|
+===============+===============================================+==============+
|
||||||
|
| *request* | Serialized request data from the DNS request | Yes |
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
| *op* | Whether an update or create is happening | Yes |
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
|
||||||
|
1. Get the name from the request
|
||||||
|
2. Make sure the requester is in the allowed list of notifiers
|
||||||
|
3. Call the backend's find_domain to see if the message is for a zone on the DNS
|
||||||
|
server. If not, throw the message away
|
||||||
|
4. Query the requesting mdns (SOA), per the RFC (????)
|
||||||
|
5. Call out to the Agent's AXFR module asynchronously which will perform the
|
||||||
|
AXFR, get the zone and call backend's create or update domain, based on the
|
||||||
|
action.
|
||||||
|
|
||||||
|
_handle_delete(request)
|
||||||
|
"""""""""""""""""""""""
|
||||||
|
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
| **Parameter** | **Description** | **Required** |
|
||||||
|
+===============+===============================================+==============+
|
||||||
|
| *request* | Serialized request data from the DNS request | Yes |
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
|
||||||
|
1. Get the name from the request
|
||||||
|
2. Make sure the requester is in the allowed list of notifiers
|
||||||
|
3. Call out to the backend's delete_domain
|
||||||
|
|
||||||
|
_handle_record_query(request)
|
||||||
|
"""""""""""""""""""""""""""""
|
||||||
|
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
| **Parameter** | **Description** | **Required** |
|
||||||
|
+===============+===============================================+==============+
|
||||||
|
| *request* | Serialized request data from the DNS request | Yes |
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
|
||||||
|
1. Repackage the request, send it along to the local DNS server
|
||||||
|
2. Return the results
|
||||||
|
|
||||||
|
This is a possible way for the Agent to answer DNS queries when MiniDNS is
|
||||||
|
polling for changes
|
||||||
|
|
||||||
|
AXFR
|
||||||
|
^^^^
|
||||||
|
|
||||||
|
The AXFR module will send the AXFR query to one of the masters specified in the
|
||||||
|
config for the zone name that was passed in. Based on the type of query that
|
||||||
|
called for the AXFR, a backend call will then be made with the information
|
||||||
|
gathered from the AXFR.
|
||||||
|
|
||||||
|
_do_axfr(zone_name, action)
|
||||||
|
"""""""""""""""""""""""""""
|
||||||
|
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
| **Parameter** | **Description** | **Required** |
|
||||||
|
+===============+===============================================+==============+
|
||||||
|
| *zone_name* | The zone name to ask for the AXFR with | Yes |
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
| *new_domain* | Boolean value to inform AXFR if the zone is a | No |
|
||||||
|
| | new zone or not. Default is False | |
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
|
||||||
|
1. Pick a master from the config file
|
||||||
|
2. Send the AXFR query
|
||||||
|
3. Parse the response into a designate domain object
|
||||||
|
4. Call the backend for the specified action (Create, Update)
|
||||||
|
|
||||||
|
.. note:: Eventually this module could be renamed "Transfer" and do IXFRs.
|
||||||
|
|
||||||
|
Backend
|
||||||
|
^^^^^^^
|
||||||
|
|
||||||
|
The Backend module will house a base plugin, and a variety of plugins with a
|
||||||
|
similar interface to the Pool Manager. The intent is to take the zone changes
|
||||||
|
gleaned from an AXFR (or IXFR) and apply them to the DNS server. The manner of
|
||||||
|
accomplishing this will vary widely for each DNS server, you might be editing a
|
||||||
|
flat file, or making database calls, or some other method. The following methods
|
||||||
|
would compose the base plugin.
|
||||||
|
|
||||||
|
find_zone(zone_name)
|
||||||
|
""""""""""""""""""""
|
||||||
|
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
| **Parameter** | **Description** | **Required** |
|
||||||
|
+===============+===============================================+==============+
|
||||||
|
| *zone_name* | The zone name to be searched for | Yes |
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
|
||||||
|
When a NOTIFY comes in for a zone, the Agent must first check to make sure that
|
||||||
|
the zone is valid for the DNS server. Otherwise, it might do an AXFR and try to
|
||||||
|
update a zone that doesn't exist on the server. It's possible that this check
|
||||||
|
could be incorporated in to the update_zone function, but it seems more
|
||||||
|
efficient to do it here.
|
||||||
|
|
||||||
|
create_zone(domain)
|
||||||
|
"""""""""""""""""""
|
||||||
|
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
| **Parameter** | **Description** | **Required** |
|
||||||
|
+===============+===============================================+==============+
|
||||||
|
| *domain* | A Designate domain object to create on the | Yes |
|
||||||
|
| | backend server, including it's recordsets | |
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
|
||||||
|
Take the appropriate measure to create the zone on the DNS server. This object
|
||||||
|
will hold all the necessary information to serve the zone.
|
||||||
|
|
||||||
|
update_zone(domain)
|
||||||
|
"""""""""""""""""""
|
||||||
|
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
| **Parameter** | **Description** | **Required** |
|
||||||
|
+===============+===============================================+==============+
|
||||||
|
| *domain* | A Designate domain object to update on the | Yes |
|
||||||
|
| | backend server, including it's recordsets | |
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
|
||||||
|
Take the appropriate measure to update the zone on the DNS server. This has the
|
||||||
|
potential to be very similar to the create_zone logic if there is no way to
|
||||||
|
discern the differences between this object, and the zone on the server.
|
||||||
|
|
||||||
|
delete_zone(zone_name)
|
||||||
|
""""""""""""""""""""""
|
||||||
|
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
| **Parameter** | **Description** | **Required** |
|
||||||
|
+===============+===============================================+==============+
|
||||||
|
| *zone_name* | The zone name identified for deletion | Yes |
|
||||||
|
+---------------+-----------------------------------------------+--------------+
|
||||||
|
|
||||||
|
Take the appropriate measure to delete the zone on the DNS server, and ideally
|
||||||
|
all of it's subresources.
|
||||||
|
|
||||||
|
Other Changes
|
||||||
|
-------------
|
||||||
|
|
||||||
|
This should fit into the Designate pattern well. To the Pool Manager and
|
||||||
|
MiniDNS, the Agent is the same as any other DNS server. It's possible that
|
||||||
|
something in MiniDNS could be supplemented to use with the Agent, but it
|
||||||
|
shouldn't be needed.
|
||||||
|
|
||||||
|
A lot of the code that MiniDNS uses for the actual DNS protocol stuff will
|
||||||
|
be reused in some form in the Agent. Development of the agent would be a good
|
||||||
|
time to port the commonalities into the dnsutils module of Designate.
|
||||||
|
|
||||||
|
Benefits
|
||||||
|
========
|
||||||
|
|
||||||
|
- Configurable backends that can do the work required for different DNS servers
|
||||||
|
(RNDC, Database addition) that don’t connect directly to the database
|
||||||
|
- A deployment with the benefits of MiniDNS, while keeping a traditional
|
||||||
|
Master/Slave DNS setup is possible
|
||||||
|
- Less DNS servers must be managed by Designate
|
||||||
|
- Less chatter between MiniDNS and the database because SOA refreshes and
|
||||||
|
other queries can be handled by a master
|
||||||
|
- MiniDNS becomes less vital to a deployment, MiniDNS/Database issues are
|
||||||
|
isolated from the DNS infrastructure
|
||||||
|
- An agent with direct control of the DNS servers adds the benefit of doing
|
||||||
|
things outside of pure DNS protocol with a DNS server, periodic syncs, etc are
|
||||||
|
made easier
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
tim-simmons-t
|
||||||
|
|
||||||
|
Milestones
|
||||||
|
----------
|
||||||
|
|
||||||
|
Target Milestone for completion:
|
||||||
|
Kilo
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
- Create the Agent service
|
||||||
|
- Add support for receiving NOTIFYs
|
||||||
|
- Add support for receiving AXFRs
|
||||||
|
- Decide and implement receiving messages with non-standard CLASS/RRDATA
|
||||||
|
- Add a base class backend that is called for different operations
|
||||||
|
- Port some of the existing backends, or add some new ones
|
Loading…
Reference in New Issue