[Pdns-dev] Proposal: Backend API adjustments for authoritative 3.0

Maik Zumstrull maik.zumstrull at rz.uni-karlsruhe.de
Mon Jul 19 14:19:15 CEST 2010


Given that 2.9 => 3.0 will be something of a break in backend API
anyway, due to the introduction of DNSsec, I would suggest taking the
opportunity to get rid of some legacy peculiarities in the interface.

Let me make the main counter-argument myself immediately: this would
mean that existing backends would stop working without (minor)
adjustments. Currently, it seems that existing backends will continue
to work with 3.0, just without DNSsec.

1) The "prio" field

This is obviously a design flaw. Sensible data models are either
expanding every record type completely, or having fields just for owner
name and data. Taking one field that exists in two kinds of records (MX
and SRV) and giving it its own field for no reason is strange and
requires special-case handling in quite a few places. It's especially
weird for SRV, which has several numerical fields, but only one is
pulled out.

I suggest killing the prio field and putting everything in the rdata
string.

2) Empty non-terminals

Currently, PowerDNS cannot tell the difference between a name that
doesn't exist and a name that exists, but doesn't have any records of a
particular type (or any type). There is simply no way to report the
difference from the backend: either way, lookup() doesn't return
anything, and get() returns false on the first call.

Suggested fix: Make lookup() bool, not void. Return true if the name
exists, even if it has no records, false otherwise. So for an empty
non-terminal, lookup() would return true, and get() would immediately
return false.

3) Split and rename startTransaction()

As of now, startTransaction() does two different things: it begins a
transaction, and it deletes all records for a given zone.

Suggested fix: Replace startTransaction() with two functions
beginTransaction() and clearZone(). Begin would make a better
counterpart to commitTransaction() because of the obvious SQL relation,
and splitting out clearZone() means that the functions actually do
what the name suggests, instead of having a completely unrelated
additional effect. (I'm not sure about the clearZone name, maybe
something more verbose like clearAllZoneRecords.)


Comments? Any other ideas?


More information about the Pdns-dev mailing list