[Pdns-users] Two questions about powerdns
lorens-pdns-3987 at tagged.lorens.org
Sun Jan 22 13:13:50 UTC 2006
On Sun, Jan 22, 2006 at 02:41:37PM +0200, Geoffrey Ellison wrote:
> I have a suggestion for how to make the serial number issue a lot
> easier. It would still retain backward compatibility (thinking of
> people who already have automation in place, like me) but would
> enable serials to be much simpler to manage also, even taking it to
> the point where no further serial management is required at all
> (which is actually where a databased DNS server should be). Here is
> the idea:
> You have another record in the zone, perhaps with a "SER" type. Pdns
> can ignore this record when serving zones. The name would be either
> "manual" or "auto", and the value would be the serial number.
I would put it in the domain table and not the record table,
probably less code to change. Actually, I think that all the
fields in the soa should have a seperate field in the domain
table, but backwards compatibility good-bye.
> If name is "auto" pdns should update it to a standard (RFC) serial
> number of YYYYMMDDxx, whenever there is a change to any of the
> records. At the same time, it should also update the serial number
> in the SOA string to match.
I can imagine > 100 changes a day if the updating is
automatic. Give it a few minutes if it's automatic :-)
> If you don't want to pollute the records table with non-standard
> types, perhaps another separate table might be the answer:
> table serials:
> The first 4 fields are obvious. The checksum field can be used to
> keep an MD5 hash of all the records for the zone. The last_update
> field can keep a timestamp of when the serial was last automatically
> updated. If an amount of time has elapsed since last_update stamp
> that is greater than the ttl, pdns can scan all the records and
> hash/checksum them, comparing that with the stored checksum. If the
No need for that, each record gets a change_date, just select
domain_id where there are records whose change_date > last_check
or something similar.
> checksums are different, it means the record has changed, and so a
> new serial can be generated and stored in that record, and in the
> SOA record of the records table. This means that none of the dns-
> serving code needs to change, or even be aware of the new table, it
> can just keep on serving like it used to. The watchdog for this can
> be a completely separate process, doesn't even have to be part of
> pdns (kind of like the recursor).
> Similarly the same process can look in the SOA record, and if it is
> newer than in the serials table, it can update the serials table.
> That would keep backward compatibility.
> Now that I've put all that down, I realise it can simply be done in
> in a scriptable language and stuck into a cron job, and bang - you
> never have to worry about another serial number again! I just might
> do that, unless you have big plans for doing this another way, in
> which case I'll wait a bit.
I believe it's done somewhere already :-)
While I'm writing, I'll take the opportunity to mention a few things:
I've found a (very minor) bug in the SOA code: if the e-mail
address is absent, the serial gets parsed as the e-mail
address, which I suppose is normal, but zone transfers get
a very large serial number invented from somewhere, maybe
reading past the end of the SOA buffer.
AXFR: it would be nice if super-secondaries recognized the
fact that a domain has disappeared from the master, and
deleted if from the database. This could of course be done
only when the master continues to reply "I don't carry this
domain any more" past the expiration date for the domain
AXFR again: it would be nice if a master tracked the AXFRs
made by secondaries, and resent notifies when a secondary
doesn't respond to a notify by at least an SOA serial check.
More information about the Pdns-users