Merge "Alias Records Spec"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
30a332bf73
|
|
@ -0,0 +1,268 @@
|
|||
..
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
===============
|
||||
Alias Records
|
||||
===============
|
||||
|
||||
https://blueprints.launchpad.net/designate/+spec/alias-records
|
||||
|
||||
ALIAS records (aka ANAME's, root CNAME's, root domain redirect, zone
|
||||
apex CNAME's) are a relatively new "addition" to DNS. These pseudo
|
||||
Resource Records (RR) are used to bypass restrictions placed within
|
||||
the DNS protocol that forbid the presence of a CNAME RR next to any
|
||||
other RR. This prevents some modern usage of DNS, for example, many
|
||||
CDNs or other static-content hosting sites like GitHub Pages will
|
||||
require users to CNAME e.g. "www.example.org." towards their frontend
|
||||
load balancers. A CNAME is used to ensure the provider can easily make
|
||||
infrastructure changes without requiring every customer to implement
|
||||
DNS changes in-sync with their deployment schedule.
|
||||
|
||||
As this is not a true feature within the DNS protocol, support for
|
||||
ALIAS RR's must be implemented entirely within the end users
|
||||
authoritative DNS infrastructure.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
DNS RFCs do not support a CNAME record set for the root domain:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
example.com IN CNAME example.github.com
|
||||
|
||||
As a result, this capability is not widely supported by DNS backends.
|
||||
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Designate will expose a new "ALIAS" record set type via API; the
|
||||
record set will be flattened on a periodic basis into an "A" or "AAAA"
|
||||
record set for propagation to DNS backends. This solution is
|
||||
backend-independent and complies with RFCs implementations.
|
||||
|
||||
Acceptance Criteria
|
||||
-------------------
|
||||
- An end user can create an "ALIAS" record set in the API and see that
|
||||
record set through all other API requests (e.g. get record sets,
|
||||
export zone, import zone)
|
||||
- All "ALIAS" records will be flattened to "A/AAAA" record sets for
|
||||
all backends.
|
||||
- An IP change to example.github.com will result in an update the IP
|
||||
address of the flattened "A" or "AAAA" record sets available on the
|
||||
backend.
|
||||
- Operators can configure a custom caching name sever to use for
|
||||
resolution and flattening of ALIAS record sets.
|
||||
- Operators can set the polling interval for the flattening process.
|
||||
|
||||
.. note:: Not recommended for use with CDN implementations.
|
||||
|
||||
|
||||
API Changes
|
||||
-----------
|
||||
|
||||
RRSets with the "visible" value (described below) set to "mdns" will
|
||||
be filtered from view within the API.
|
||||
|
||||
Additionally, ALIAS RRSets will not be visible in the V1 API. Instead,
|
||||
a dynamically generated TXT record will be included to indicate the
|
||||
existence of the the ALIAS record that is only editable via the V2
|
||||
API.
|
||||
|
||||
|
||||
**Example ALIAS record set creation request:**
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
POST /v2/zones/2150b1bf-dee2-4221-9d85-11f7886fb15f/recordsets HTTP/1.1
|
||||
Host: 127.0.0.1:9001
|
||||
Accept: application/json
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"name" : "example.org.",
|
||||
"description" : "This is an example ALIAS record set.",
|
||||
"type" : "ALIAS",
|
||||
"ttl" : 3600,
|
||||
"records" : [
|
||||
"example.github.com."
|
||||
]
|
||||
}
|
||||
|
||||
|
||||
Flatten Task
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The process of "flattening" the ALIAS record can be triggered by the
|
||||
user. For example, if a user starts getting error messages the
|
||||
resolution isn't working, the user can make an API request to force an
|
||||
update.
|
||||
|
||||
**Example Manual Flatten Request:**
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
POST /v2/zones/<zone_id>/recordsets/<recordset_id>/tasks/flatten HTTP/1.1
|
||||
Host: 127.0.0.1:9001
|
||||
Accept: application/json
|
||||
|
||||
|
||||
The request body should be empty. Also, it is recommended the user
|
||||
configure rate limits on this endpoint accordingly. This rate limiting
|
||||
is outside the scope of this spec.
|
||||
|
||||
|
||||
Exporting
|
||||
~~~~~~~~~
|
||||
|
||||
When a zone is exported as a zone file, the export should contain two
|
||||
lines, the ALIAS record, commented out, and the most recent A record.
|
||||
|
||||
For example:
|
||||
|
||||
::
|
||||
|
||||
; example.com. IN ALIAS example.org.
|
||||
example.com. IN A 192.0.2.1
|
||||
|
||||
This allows the user to have a valid zone file to import, while
|
||||
providing visibility that the A record was generated from an ALIAS
|
||||
record.
|
||||
|
||||
|
||||
Central Changes
|
||||
---------------
|
||||
|
||||
Central's create and update RecordSet methods will be updated to call
|
||||
a new RPC method implemented on the Zone Manager service to trigger
|
||||
immediate ALIAS flattening when ALIAS RRSets are created /
|
||||
updated. If the resolution fails, the record will be placed in the
|
||||
`ERROR` status.
|
||||
|
||||
Central's delete RecordSet method will be updated to remove the
|
||||
associated flattened `A` and `AAAA` RecordSets - the mechanism for
|
||||
identifying these related RRSets is detailed in Zone Manager Changes.
|
||||
|
||||
Additionally, ALIAS RRSets will be treated somewhat similarly to
|
||||
CNAMEs. It will be invalid to place an ALIAS RRSet next to an A or
|
||||
AAAA RecordSet. The recordset placement validation will be updated to
|
||||
handle this case.
|
||||
|
||||
|
||||
MiniDNS Changes
|
||||
---------------
|
||||
MiniDNS will be updated to display RRSets with the "visible" field
|
||||
(described below) set to 'mdns' or 'all', ensuring no attempt is made
|
||||
to include non-RFC compliant RRSets within `AXFRs`.
|
||||
|
||||
|
||||
Zone Manager Changes
|
||||
--------------------
|
||||
|
||||
First, for each zone it manages, `designate-zone-manager` service will
|
||||
find any ALIAS recordsets associated with the zone. The zone manager
|
||||
will then issue a successful A/AAAA DNS query to get the IP
|
||||
addresses associated with the ALIAS target. Designate's database
|
||||
will be updated to the "real" values, incrementing the SOA serial to
|
||||
trigger an AXFR towards the public facing nameservers.
|
||||
|
||||
If this query fails and the ALIAS target can't be resolved, the
|
||||
A/AAAA records will not be updated and the ALIAS RR will be put in
|
||||
STALE status.
|
||||
|
||||
The interval at which ALIAS records are flattened will be
|
||||
configurable, defaulting to 1800 seconds (30 minutes).
|
||||
|
||||
Finally, a new RPC method will be implemented to trigger immediate
|
||||
ALIAS flattening for a specific Zone, allowing for newly created ALIAS
|
||||
RR's to be usable before the first periodic interval is hit. This RPC
|
||||
method will also be utilized by the ALIAS RRset flattening task
|
||||
endpoint.
|
||||
|
||||
|
||||
Storage Changes
|
||||
---------------
|
||||
|
||||
Recordsets: update column "type"
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Add "ALIAS" to "type".
|
||||
|
||||
|
||||
Recordsets: New Column
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
+---------+----------------------------+------+-----+---------+---------+
|
||||
| Field | Type | Null | Key | Default | Extra |
|
||||
+---------+----------------------------+------+-----+---------+---------+
|
||||
| visible | enum('all', 'api', 'mdns') | NO | MUL | 'all' | |
|
||||
+---------+----------------------------+------+-----+---------+---------+
|
||||
|
||||
|
||||
Sample data
|
||||
-----------
|
||||
|
||||
For the example scenario described above, corresponding database values are the
|
||||
following (columns omitted for brevity):
|
||||
|
||||
|
||||
Recordsets Table
|
||||
~~~~~~~~~~~~~~~~
|
||||
+------+-----------+---------------------+-----------+-------+---------+
|
||||
| id | domain_id | name | tenant_id | type | visible |
|
||||
+------+-----------+---------------------+-----------+-------+---------+
|
||||
| 1230 | 768 | example.github.com. | 391 | ALIAS | 'api' |
|
||||
+------+-----------+---------------------+-----------+-------+---------+
|
||||
| 0100 | 768 | example.org. | 391 | A | 'mdns' |
|
||||
+------+-----------+---------------------+-----------+-------+---------+
|
||||
|
||||
|
||||
Records Table
|
||||
~~~~~~~~~~~~~
|
||||
+------+--------------+--------------+---------+-----------------------+---------------------+
|
||||
| id | recordset_id | data | managed | managed_resource_type | managed_resource_id |
|
||||
+------+--------------+--------------+---------+-----------------------+---------------------+
|
||||
| 3211 | 1230 | example.org. | 0 | NULL | NULL |
|
||||
+------+--------------+--------------+---------+-----------------------+---------------------+
|
||||
| 3212 | 0100 | 192.168.1.10 | 1 | ALIAS | 3211 |
|
||||
+------+--------------+--------------+---------+-----------------------+---------------------+
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Some DNS backends support flattening processes (e.g. PowerDNS). An
|
||||
alternative implementation is to create a new record set type called
|
||||
"ALIAS" that integrates with each respective backend's implementation.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
**Assignee(s)**
|
||||
|
||||
Primary assignee:
|
||||
Eric Larson <eric.larson@rackspace.com>
|
||||
|
||||
**Milestones**
|
||||
|
||||
Target Milestone for completion:
|
||||
Mitaka-1
|
||||
|
||||
**Work Items**
|
||||
|
||||
* Implement support for hiding RRSets in the API and MiniDNS
|
||||
* Implement the periodic ALIAS flattening within the `designate-zone-manager`
|
||||
service
|
||||
* Update Central's CUD RecordSet methods for ALIAS support
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
Loading…
Reference in New Issue