Include "SLAVE" type zones when querying catalog members

[ikoula]

This pull request aims to close issue #12135, which describes a similar problem.

When the PowerDNS authoritative server hosts a zone of type "SLAVE" and the "catalog" option is set, the "SLAVE" zone is not added to the corresponding catalog. This causes issues when PowerDNS is used as an intermediate server, for example, to provide secondary DNS services.

RFC 9432 (which defines catalog zones) states that catalog zones are used for management. This fix aims to allign PowerDNS with other DNS server implementations (Knot for example) to allow users to add "slave" (secondary) zones to catalogs.

Short description

Checklist

I have:

• read the CONTRIBUTING.md document
• read and accepted the Developer Certificate of Origin document, including the AI Policy, and added a "Signed-off-by" to my commits
• compiled this code
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[coveralls]

Pull Request Test Coverage Report for Build 23653434430

Details

• 5 of 17 (29.41%) changed or added relevant lines in 11 files are covered.
• 14051 unchanged lines in 117 files lost coverage.
• Overall coverage decreased (-7.8%) to 63.152%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
modules/gmysqlbackend/gmysqlbackend.cc	0	1	0.0%
modules/gpgsqlbackend/gpgsqlbackend.cc	0	1	0.0%
modules/gsqlite3backend/gsqlite3backend.cc	0	1	0.0%
pdns/dnsbackend.cc	1	2	50.0%
pdns/resolver.cc	0	1	0.0%
pdns/tcpreceiver.cc	1	2	50.0%
modules/lmdbbackend/lmdbbackend.cc	0	2	0.0%
pdns/json.cc	0	4	0.0%

Files with Coverage Reduction	New Missed Lines	%
modules/geoipbackend/geoipinterface.hh	1	0.0%
modules/ldapbackend/ldapauthenticator.hh	1	0.0%
modules/pipebackend/coprocess.hh	1	0.0%
modules/tinydnsbackend/tinydnsbackend.hh	1	0.0%
pdns/backends/gsql/ssql.hh	1	56.52%
pdns/bindparserclasses.hh	1	92.31%
pdns/zoneparser-tng.hh	1	90.91%
pdns/dnsdistdist/dnsdist-async.cc	2	79.59%
pdns/iputils.hh	2	75.09%
pdns/json.hh	2	0.0%

Totals
Change from base Build 23652805431:	-7.8%
Covered Lines:	116604
Relevant Lines:	168117

---

💛 - Coveralls

[ikoula]

Addendum: forgot to add the -s to my commit. The last push should fix it.

[miodvallat]

I'm afraid this does not sound right to me. With your change, secondary zones would be listed both as producer and consumer, and I doubt this is the right thing to do.

[ikoula]

The goal of this commit is to add the corresponding zone to the producer catalog if the catalog is set for a zone as a producer, even if the zone is of type “SLAVE.” Without this contribution, when PowerDNS acts as both a catalog producer and a secondary server, its secondary instances cannot receive zones that are defined as “SLAVE” on PowerDNS. According to RFC 9432, this behavior is problematic since catalogs are meant for zone propagation regardless of zone type on PowerDNS.

For example, if you configure PowerDNS as the producer for “catalog.internal” and other DNS servers as consumers, and you also configure PowerDNS as a secondary server for “example.com” (from a Bind9 server, for instance) and add that zone to the “catalog.internal” catalog, the zone “example.com” will not be present in the catalog, so the secondary nodes will not be able to serve it.

[mind04]

This is not how catalog zones was intended. Real solution is to use multiple catalogs, one for the primary zones on each primary server and chain/send those catalogs to the secondaries.

According to RFC 9432, this behavior is problematic since catalogs are meant for zone propagation regardless of zone type on PowerDNS.

For the record, rfc9432 has no opinion on this.

[ikoula]

Thanks for your feedback, mind04.

I do understand that a setup with multiple catalogs would be ideal in some specific cases. Unfortunately, this is not the case for every deployment.
There are scenarios where you can’t control the “True primary”, rendering the multi-catalog design impossible. This would apply if you provided “secondary DNS as a service” (as shown on the diagram above) where customers will have their own managed DNS server.

If you believe that PowerDNS should not publish a zone to a catalog (as a catalog producer) that is set as “SLAVE”, then why PowerDNS does allow other DNS servers to perform a zone transfer if the zone is set as “SLAVE”?

RFC 9432 tells us that “Secondary name servers can then add, remove, or modify the zones they serve in accordance with the changes to the catalog zone.” , “[…] catalog zones only contain information for the management of a set of authoritative name servers.”, “Catalog zones simplify zone provisioning by orchestrating zones on secondary name servers from a single data source: the catalog” and “Member zone: A DNS zone whose configuration is published inside a catalog zone.”

I believe that it does not exclude zones that are stored as “SLAVE” in the catalog producer DNS server.

Besides, other DNS server implementations like Knot and Technitium allow us to add zones stored as secondary, on the catalog (as a catalog producer).
Also, this change would not change anything if the “SLAVE” zone is not present in the catalog (as this PR aims brings more flexibility to PowerDNS deployments).