neutron

Generic DNS Subsystem

Registered by John Voss on 2014-04-20

This blueprint has been superseded. See the newer blueprint "External DNS Resolution" for updated plans.

This blueprint describes a generic DNS subsystem, which provides a basic DNS resolving service and an ability to communicate within a tenant or outside the cloud using fully qualified domain name. Further, it provides an ability to add a pluggable DNS service provider.

The blueprint addresses the following use cases:

A cloud user wants to provide a basic DNS resolving service to the VMs out of the box. Following requirements should be considered:
● The VMs must be automatically configured to use the internal DNS servers
● The user should not be required to specify external DNS servers when creating a new network however, free to specify external DNS servers in addition to that provided by the cloud
● The DNS services must be provided in a highly available manner, including configuration of both a primary and a secondary DNS

A cloud user wants to use fully qualified domain names for VM to VM communication within a tenant. Following requirements should be considered:
● Each new VM in a tenant must automatically get a set of corresponding DNS records in a per-tenant DNS zone (optionally in a shared one)
● The user must be able to create additional (e.g. CNAME, TXT, MX) records in the DNS zone on demand using CLI
● VMs must get automatically configured with a proper DNS suffix
● The policy for DNS zone access restriction must be configurable by a cloud operator
● The format of address records must be defined by means of a template/pattern specified by a cloud operator
● IPv6 address records should be supported

A cloud user wants to use fully qualified domain names to access VMs from outside the cloud. Following requirements should be considered:
● For each floating IP address assigned to a VM a set of appropriate DNS records must be created in an corresponding DNS zone (per-tenant-network / per-floating-pool / shared zone)
● IPv6 address records should be supported.
● The format of the address records (A/CNAME) must be defined by means of a template/pattern specified by a cloud operator
● A cloud user must be able to create additional DNS records on demand using CLI/API

In addition, a cloud operator should be able to select a backend to provide the DNS services appropriate for a particular OpenStack environment. Following requirements should be considered:
● A default dnsmasq-based implementation should be available.

Blueprint information

Status:: Complete

Approver:: None

Priority:: Undefined

Drafter:: John Voss

Direction:: Needs approval

Assignee:: John Belamaric

Definition:: Superseded

Series goal:: None

Implementation:: Unknown

Milestone target:: None

Completed by: Armando Migliaccio on 2015-12-12

Related branches

Related bugs

Sprints

ahmed

Whiteboard

(mestery): Please do not set milestones until the BP is approved in neutron-specs.

Clear design is needed here to avoid lots of redundant and possibly soon obsolete code.

Are we using DNS 'views' per se here? Or is the outside network going to interpenetrate the network the servers are on, with no NAT, like IPv6? What is typically done in IPv4 seems to cross up how IPv6 is laid out with no NAT. Clarity in the network design going forward is required as this influences how this DNS code is implemented.

Stateful filtering and using an 'internal' sub domain are the best way of handling RFC1918 and IPv6 ULA. DNS views are not implied by the IPv6 RFCs and examples in RFCs. Access control by source address can be implemented on the 'internal' sub-domain and reverse zones. 'Views' are not a good idea AFAIK as double servicing/configuration maintenance needed.

Above you have:

1) Resolver configuration

2) Available Internal DNS - see above.

3) External DNS

Coding for DNS 'Views' and IPv6 network models can create a lot of spaghetti and nooks and crannies in the code if not implemented properly. IPv4 NAT with DNS views is quite common in a private type cloud set up, but things are changing. That may be important for the next few years, but it has to be properly designed, and easily removed from the code in about 5 years.

A zone layout that reflects IPv6 network design practise, with 2 DNS resolver search path entries is also quite important, and will get more use as dual stack networks are deployed. It is easier to do both IPv4 and IPv6 with no NAT. Eg, mending internal host name resolution and reverse lookup using hosts files (they can't do dual v4 and v6 addressing on the same name) inside IPv4 NAT does not work that well when you do dual stacking as well!

(?)