[Pdns-dev] Bind-like behavior for the sqlbackend (take II)...

Marc Jauvin marc at r4l.com
Mon Feb 21 13:41:50 CET 2005

A few days ago, I wrote the following:

> Bind allows you to refer to the same zone data file for multiple zones (using
> "generic" zones without explicit $ORIGIN reference in the zone data file).
> I would like to inquire how easy it would be to hack pdns to allow multiple
> zones for the SQL backends to share a set of RR.

And the following crap:

> The way I see it, we could have an extra field in the domain table (like
> refID) which would either be 0 (when the zone has its own set of RR) or
> another zone's ID (if it shares this zone's RR).
> Of course, that would require the records table to either NOT contain the FQDN
> in the "name" field or add code to the SQLbackend to replace the domain part
> of the source zone for the zone sharing RR.

I was "assuming" the the current gmysql backend was first doing a query from the
"domains" table to get the id for the zone... and _then_ querying the records
table with that id to find RR.

So it seems I will need to create a new backend modules to do what I want. I'm
thinking of doing the following:

  - the domains table would contain a new field (ref_id) which would point to an
existing zone (using that zone's id field).

  - The lookup() method would first query the domains table to get the id of the
zone to search RR for. The "ref_id" (if defined) would be used in place of the
"id" field.

  - the records table's "name" field would contain the "host" part of the FQDN
only, thus, allowing its records to be shared with a different zone.

Does that makes sense? Any suggestions to make this module usefull for as many
setups as possible?


Marc Jauvin

More information about the Pdns-dev mailing list