[Pdns-users] Two questions about powerdns

Geoffrey Ellison pdns-lists at brandedinternet.co.za
Sun Jan 22 12:41:37 UTC 2006


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.

If name is "manual" pdns shouldn't ever change the content field of 
this value, but whenever it is found to be changed, it should update 
the serial number in the SOA string to match.

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'm not sure what mechanism is in place to track changes, that may 
be a whole other discussion. Although the separate table idea below 
would provide such a mechanism if it didn't exist.

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 
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.


On 22 Jan 2006 at 13:14, Oded Arbel wrote:

> On Sunday, 22 January 2006 12:52, bert hubert wrote:
> > On Sun, Jan 22, 2006 at 12:43:43PM +0200, Oded Arbel wrote:
> > > It kind of annoying, because the SOA serial is stuck in the middle
> > > of the SOA record that is stored textually in the records table -
> > > so I can't easily automate it. In moving to power dns, I was hoping
> > > to get rid of all the specially crafted text parsing that had to be
> > > done to manage bind domains, and apparently that is not the case.
> >
> > It is something I want fixed ASAP indeed.
> I think it would be a good thing :-) How do you plan on doing that ? I 
> was thinking about automatically generating it from the newest update 
> time of all the records for a domain, but of course the SOA record 
> itself will not be updated - and I'm not sure what will the impact of 
> that be.
> > There is an RPM on the snapshots page, you could try it.
> Thanks - is there a source RPM or spec file that I could look at ? I 
> don't particularly like to deploy unknown RPMs on my systems.
> > "Soon", but no promises, sorry.
> Cool. "soon" as in "as soon as its ready" is good for me :-)
> -- 
> Oded
> ::..
> All extremists should be taken out and shot.
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users
> !DSPAM:43d3770a20056292379414!

More information about the Pdns-users mailing list