Description of problem: As the following RFC says, parent's NS record and child's NS record must be the same value. https://www.ietf.org/rfc/rfc1034.txt ~~~ As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. 6.1. C.ISI.EDU name server C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN class, and would have zones for these domains. The zone data for the root domain might be: . IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( 870611 ;serial 1800 ;refresh every 30 min 300 ;retry every 5 min 604800 ;expire after a week 86400) ;minimum of a day EDU. 86400 NS SRI-NIC.ARPA. <====================================(*)parent's NS record 86400 NS C.ISI.EDU. <====================================(*)parent's NS record The master file for the EDU zone might be stated relative to the origin EDU. The zone data for the EDU domain might be: EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( 870729 ;serial 1800 ;refresh every 30 minutes 300 ;retry every 5 minutes 604800 ;expire after a week 86400 ;minimum of a day ) NS SRI-NIC.ARPA. <====================================(*)child's NS record NS C.ISI.EDU. <====================================(*)child's NS record ~~~ In Designate, NS records comes from ns_records of pools.yaml. The default value in TripleO is ns1.example.org., ns2.example.org. and ns3.example.org. ~~~ [root@overcloud-controller-0 ~]# grep ns_records /var/lib/config-data/puppet-generated/designate/etc/designate/pools.yaml -A 6 ns_records: - hostname: ns1.example.org. priority: 1 - hostname: ns2.example.org. priority: 2 - hostname: ns3.example.org. priority: 3 (overcloud) [stack@undercloud ~]$ openstack recordset list zone0.designate.example.com. --fit +-------------------------------------+------------------------------------+------+-------------------------------------+--------+--------+ | id | name | type | records | status | action | +-------------------------------------+------------------------------------+------+-------------------------------------+--------+--------+ | 94fd335c-cf11-43dc-87e8-ba4ea8dda38 | zone0.designate.example.com. | NS | ns3.example.org. | ACTIVE | NONE | <===(*) | 4 | | | ns1.example.org. | | | <===(*) | | | | ns2.example.org. | | | <===(*) | ed6d2eaf-1453-4d1f-89bd- | zone0.designate.example.com. | SOA | ns2.example.org. | ACTIVE | NONE | <===(*) | cc898e975a47 | | | yatanaka.redhat.com. 1670322189 | | | | | | | 3545 600 86400 3600 | | | | 2ccc3643-0ad3-4ddc-8fe4-87c7d5e3d35 | test.zone0.designate.example.com. | A | 10.0.0.100 | ACTIVE | NONE | | e | | | | | | | 5f15cbd8-3486-4936-9146-b2e9dc54c23 | test2.zone0.designate.example.com. | A | 10.0.0.101 | ACTIVE | NONE | | c | | | | | | +-------------------------------------+------------------------------------+------+-------------------------------------+--------+--------+ ~~~ Therefore, ns_records of pools.yaml is really important parameter when we want to integrate Designate and the internet. If wen cannot change ns_records of pools.yaml, we cannot integrate Designate and the internet. We should be able to change ns_records of pools.yaml. However, it seems that there is no THT value to configure ns_records. tripleo-ansible : https://github.com/openstack/tripleo-ansible/blob/stable/wallaby/tripleo_ansible/roles/designate_bind_pool/templates/pools.yaml.j2#L12-L16 tripleo-heat-template : https://github.com/openstack/tripleo-heat-templates/blob/stable/wallaby/deployment/designate/designate-central-container-puppet.yaml#L224-L225 What do you think about adding a THT parameter to configure ns_records of pools.yaml? Version-Release number of selected component (if applicable): RHOSP 17.0 How reproducible: Steps to Reproduce: 1. Deploy overcloud with designate Actual results: We cannot change ns_records of pools.yaml by THT parameter. Expected results: We can change ns_records of pools.yaml by THT parameter.
*** Bug 2151290 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Red Hat OpenStack Platform 17.1.2 bug fix and enhancement advisory), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2024:0209