Pools¶
Contents:
Overview¶
In designate we support the concept of multiple “pools” of DNS Servers.
This allows operators to scale out their DNS Service by adding more pools, avoiding the scalling problems that some DNS servers have for number of zones, and the total number of records hosted by a single server.
This also allows providers to have tiers of service (i.e. the difference between GOLD vs SILVER tiers may be the number of DNS Servers, and how they are distributed around the world.)
In a private cloud situation, it allows operators to separate internal and external facing zones.
To help users create zones on the correct pool we have a “scheduler” that is responsible for examining the zone being created and the pools that are available for use, and matching the zone to a pool.
The filters are pluggable (i.e. operator replaceable) and all follow a simple interface.
The zones are matched using “zone attributes” and “pool attributes”. These are key: value pairs that are attached to the zone when it is being created, and the pool. The pool attributes can be updated by the operator in the future, but it will not trigger zones to be moved from one pool to another.
Note
Currently the only zone attribute that is accepted is the pool_id attribute. As more filters are merged there will be support for dynamic filters.
Managing Pools¶
In mitaka we moved the method of updating pools to a CLI in designate-manage
There is a YAML file that defines the pool, and is used to load this information into the database.
---
- name: default
# The name is immutable. There will be no option to change the name after
# creation and the only way will to change it will be to delete it
# (and all zones associated with it) and recreate it.
description: Default PowerDNS Pool
# Attributes are Key:Value pairs that describe the pool. for example the level
# of service (i.e. service_tier:GOLD), capabilities (i.e. anycast: true) or
# other metadata. Users can use this information to point their zones to the
# correct pool
attributes: {}
# List out the NS records for zones hosted within this pool
ns_records:
- hostname: ns1-1.example.org.
priority: 1
- hostname: ns1-2.example.org.
priority: 2
# List out the nameservers for this pool. These are the actual PowerDNS
# servers. We use these to verify changes have propagated to all nameservers.
nameservers:
- host: 192.0.2.2
port: 53
- host: 192.0.2.3
port: 53
# List out the targets for this pool. For PowerDNS, this is the database
# (or databases, if you deploy a separate DB for each PowerDNS server)
targets:
- type: powerdns
description: PowerDNS Database Cluster
# List out the designate-mdns servers from which PowerDNS servers should
# request zone transfers (AXFRs) from.
masters:
- host: 192.0.2.1
port: 5354
# PowerDNS Configuration options
options:
host: 192.0.2.1
port: 53
connection: 'mysql+pymysql://designate:password@127.0.0.1/designate_pdns?charset=utf8'
# Optional list of additional IP/Port's for which designate-mdns will send
# DNS NOTIFY packets to
also_notifies:
- host: 192.0.2.4
port: 53
Designate Manage Pools Command Reference¶
Update Pools Information¶
designate-manage pool update [options]
Options:¶
--file Input file (Default: /etc/designate/pools.yaml
)--dry_run Simulate an update. (Default: False) --delete Delete Pools that are not in the input file (Defaults: False)
Warning
--delete True
can be extremely dangerous.--delete True
we recommend operators run with--delete True --dry_run True
to view the outcome.