Allow non-primaries to be members of a catalog zone?

[omoerbeek]

Currently the SQL enumerating the members of a catalog zone requires them to be of type 'MASTER'. e.g.

pdns/modules/gpgsqlbackend/gpgsqlbackend.cc

Line 143 in 965ba47

declare(suffix, "info-producer-members-query", "", "select domains.id, domains.name, domains.options from records join domains on records.domain_id=domains.id and records.name=domains.name where domains.type='MASTER' and domains.catalog=$1 and records.type='SOA' and records.disabled=false");

For the typical case---sending a list of candidate secondaries to a secondary auth---that is fine.

In the case of using a catalog zone to send to a recursor (for defining forwards) that's too restrictive. A NATIVE zone could be perfectly fine for that. Maybe even a secondary zone could be used.

We should reconsider this strict approach, IMO.

[omoerbeek]

I'm sure @mind04 has an opinion :)

[klaus-nicat]

I agree, every type of zone could be a catalog member*. Especially with secondary-do-renotify it makes sense to allow secondary-zones beeing part of a catalog. Type native allows outoing AXFR but does not sent NOTIFYs, so it may sound a bit strange but I am sure someone will find a use case too.

• I wonder if catalog zones could/should be recursive and type catalog is a valid type too. For example you have a catalog per customer, and a meta-catalog with all the customer-catalogs. So if you have a new customer, you create a catalog for that customer and add that customer-catalog zone to the meta-catalog zone. That way, catalogs may be partitioned and smaller which may improve speed for catalog creation, AXFR and consuming.