-
Epic
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
designate stub zones
-
False
-
-
False
-
Committed
-
Proposed
-
To Do
-
OSPRH-4410 - Designate support for RHOSO (Target 18.0 FR1)
-
Committed
-
Proposed
-
75% To Do, 0% In Progress, 25% Done
-
OSPPlanningCycle3, 2023Q1, 2023Q2, 2024Q4
-
Networking; VANS
The designate-operator will need to configure the unbound stub zones if they are provided by the deployer.
This is one of three BZs covering configuring unbound.
"stub-zone:" section (recommend /etc/unbound/conf.d/designate-stubs.conf?)
If the deployer sets a list of TLDs that they plan to delegate to Designate, we can setup stub-zones for those that point to the Designate BIND instances. This reduces load on the customers resolvers and improves the performance for looking names up for these zones.
Note: The list of TLDs provided in the new tripleo setting described below should also be automatically added to Designate via the API if they do not already exist.
Note: We will need to know the list of Designate BIND IPs before creating this file.
For each TLD (optionally) provided by the customer: <<<< This will be a new tripleo configuration option for deployers.
stub-zone:
name: "<the TLD such as mycloud.redhat.com>"
stub-addr: <Designate BIND IP addr>
stub-addr: <Designate BIND IP addr2> (i.e. one per BIND instance in cloud)
stub-prime: yes
stub-first: yes