[Pdns-users] Two questions about powerdns

[Lorens Kockum]

On Sun, Jan 22, 2006 at 02:41:37PM +0200, Geoffrey Ellison wrote:
> Bert,
> 
> 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:
> domain_id,mode(manual/auto),serial,ttl,checksum,last_update
> 
> 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.

HAND everybody