If there actually isn't an existing solution out there to capture the info you're looking for, you could roll your own pretty easily.<br><br>You could check your database dump/backup files into svn and configure hooks to email diffs.<br>
This will definitely work but has some drawbacks:<br>1. Dump files are often difficult to clearly read (dumping full insert statements will help with this but the problem still exists in general)<br>2. Your reporting is only as granular as your backups (e.g. daily backups might be enough but daily reports on changes might not)<br>
3. There's a decent amount of scripting that still needs to be done to turn this into a usable report<br><br>You could also run ordered selects against records on a domain-by-domain basis, writing these to disk and checking these files directly into svn. Then make with the email diff hooks as mentioned above.<br>
<br>I would instead recommend that you create two audit tables, something along these lines (this is scratch SQL and is in postgresql compliant format, tune/mysql-ify to taste):<br><br>CREATE TABLE domains_changes(<br> timestamp TIMESTAMP NOT NULL DEFAULT now(),<br>
operation VARCHAR(10) NOT NULL, --- this would be one of insert, update, delete<br> old_name VARCHAR(255),<br> new_name VARCHAR(255),<br> old_type VARCHAR(6),<br> new_type VARCHAR(6)<br>
);<br><br>CREATE TABLE records_changes(<br> timestamp TIMESTAMP NOT NULL DEFAULT now(),<br> operation VARCHAR(10) NOT NULL,<br> old_name VARCHAR(255),<br> new_name VARCHAR(255),<br> old_type VARCHAR(6),<br>
new_type VARCHAR(6),<br> old_content VARCHAR(255),<br> new_content VARCHAR(255)<br> --- etc....<br>);<br><br>Then attach a trigger to the domains table and another to the records table which updates the appropriate table (domains_changes, records_changes) after every operation performed on these two tables. You can then select out of these *_changes table based on day/hour/etc to see any and all changes (you're basically done with your reporting at this point also). You can also use these tables to step back in time in certain situations.<br>
<br>Most of the time, questions about auditing tend to focus more on making sure someone doesn't accidentally fat-finger one or more of your core domain names out of existence than they tend focus on keeping your finger on the pulse of name services in general. Knowing that your intern admin brought down your production web presence is nice but you still went down. For this situation I again suggest triggers as the option way to go. A "pre" trigger on your records and domains table which does a regex or an id check against any records being changed and then discards changes made to sensitive records (perhaps along with an alert email) is pretty simple to construct and could save you some serious headaches. In situations where the sensitive records actually do need to be updated, the trigger can be temporarily dropped<br>
<br>-s<br><br> <br><br><div class="gmail_quote">On Sun, Oct 18, 2009 at 12:55 PM, Xavier Valentino <span dir="ltr"><<a href="mailto:xavier.valentino@gmail.com">xavier.valentino@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Nils,<br><br>I suspected as much, to be honest. I was just throwing it out there and hoping somebody would have a better suggestion; the interface still seemed a little more polished than PowerDNSAdmin's which is, at best, minimalistic. I'm fine with that, though.<br>
<br>The more pressing matter is that I need to have some accounting/revision reporting going on. If somebody adds something to a zone that shouldn't be there, or deletes a whole bunch of records on accident, or anything of that nature, I'd like to be able to tell what it was so I can reverse it. Any suggestions?<div>
<div></div><div class="h5"><br>
<br><div class="gmail_quote">On Sun, Oct 18, 2009 at 8:38 AM, Nils Breunese (Lemonbit) <span dir="ltr"><<a href="mailto:nils@lemonbit.com" target="_blank">nils@lemonbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Xavier Valentino wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I also see a PowerDNSAdmin alternative called TUPA; does anyone have any thoughts on the comparison between the two, or suggestions of another web-based frontend (more) suitable for users?<br>
</blockquote>
<br></div>
The latest news item on <a href="http://www.tupa-dns.org/" target="_blank">http://www.tupa-dns.org/</a> is dated April 3 2006. Looks like a dead project to me.<br>
<br>
Nils.<br>
_______________________________________________<br>
Pdns-users mailing list<br>
<a href="mailto:Pdns-users@mailman.powerdns.com" target="_blank">Pdns-users@mailman.powerdns.com</a><br>
<a href="http://mailman.powerdns.com/mailman/listinfo/pdns-users" target="_blank">http://mailman.powerdns.com/mailman/listinfo/pdns-users</a><br>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
Pdns-users mailing list<br>
<a href="mailto:Pdns-users@mailman.powerdns.com">Pdns-users@mailman.powerdns.com</a><br>
<a href="http://mailman.powerdns.com/mailman/listinfo/pdns-users" target="_blank">http://mailman.powerdns.com/mailman/listinfo/pdns-users</a><br>
<br></blockquote></div><br>