> This version assumes DNSSEC is used with PowerDNS (at least the tables
exists).
> If they don't exist this script will still work. At the top you can enter
some
> configuration options. By default it only checks domains where the
last_check
> number is at least 1 day old and after 7 failed check
On Tue, Oct 30, 2012 at 06:48:03PM +0100, Posner, Sebastian wrote:
> a b wrote:
>
> > Nevertheless, in my experience, this should be handled by the pdns
> > software.
> > I'm thinking that if pdns supermaster is capable of "persuading" a
> > superslave
> > to become a slave for a domain, and th
a b wrote:
> Nevertheless, in my experience, this should be handled by the pdns software.
> I'm thinking that if pdns supermaster is capable of "persuading" a superslave
> to become a slave for a domain, and then a transfer takes place, would it not
> be logical to expect that when said domain is
> Sent: 30 October, 2012 1:13
> > Sent: Monday, October 29, 2012 3:17 PM Op 29-10-12 15:03, Peter van
> > Dijk schreef:
> > > Hello, On Oct 29, 2012, at 9:35 , Peter van Dijk wrote:
> > >> Depending on your needs, you could write a script to do the cleanup
> > >> yourself. The last_check column is
> > We explicitly do not want to depend on any particular database
> > features for DNS records' replication.
>
> Would it be feasible to build a fully RFC 1925 (6a) [1] compliant
> solution?
>
> (1)
> Have a supermaster SM run from Oracle
>
> (2)
> Have a single superslave SS run against the s
On Mon, Oct 29, 2012 at 07:55:01PM +0100, a b wrote:
> > You could do the replication in the database (e.g. postgresql with
> > slony). Then you do not need the supermaster feature.
>
> That is something we are actually trying to avoid at all costs: we
> have Oracle doing regular notify and trans
