> Hello. I'm realy need this. I'm apply this patch, but how can i get master
> zones list running this command on slave? Or how can i decide which
> domain i need to remove on slave, that absent on master?
Hello Vasily,
With this patch you don't get all information yet as far as I know. If you
Hello. I'm realy need this. I'm apply this patch, but how can i get master
zones list running this command on slave? Or how can i decide which domain
i need to remove on slave, that absent on master?
2012/11/13 Mark Scholten
> Hello Ruben,
>
> > I would like some feedback on this, as there are
Hello Ruben,
> I would like some feedback on this, as there are a number of options:
> - Change list-all-zones to also show last_check (how would we format?)
> - Change show-zone to output more information about the zone (this was
> also suggested in ticket #608)
> - Create a delete-old-zones comm
> > We're planning to drop the pdns_control implementation and only keeping the
> > pdnssec implementation.
>
> I have not even started to study DNSSEC yet, so I have no idea what the
> implications of the above are. Anyone?
pdnssec is a wrongly/badly selected name for the tool. The plan is to
> We're planning to drop the pdns_control implementation and only keeping the
> pdnssec implementation.
I have not even started to study DNSSEC yet, so I have no idea what the
implications of the above are. Anyone?
__
Sorry, small mistake in the e-mail:
On Sat, Nov 10, 2012 at 11:00:53AM +0100, Ruben d'Arco wrote:
> Hi,
>
> Picking up on this older message, because this relates to the ticket #608.
>
> I've created a patch as a fix for #608. The patch can be found here:
> https://github.com/cyclops1982/powerdn
Hi,
Picking up on this older message, because this relates to the ticket #608.
I've created a patch as a fix for #608. The patch can be found here:
https://github.com/cyclops1982/powerdns/compare/master...608.diff
At the moment, this simply includes a list-all-zones and delete-zone command
for
> So it can be done then? Use NOTIFY and not have data loss on the slaves?
A packet lost in transit is not "data loss on slave". If the data
never gets there, slave can't lose it. Inconsistency would be more
of a correct term here.
Such inconsistencies can be monitored for very well, and if you
> If you are afraid of losing a notify, you are free to force your Supermaster
> to periodically notify all Superslaves about *all* zones. If Superslave hasn't
> yet heard of a zone due to a missed NOTIFY, it'll pull it from the master.
So it can be done then? Use NOTIFY and not have data loss on
> > Many protocols for distribution of data have a certain ordering and an
> > acknowledgement
> > mechanism. NOTIFY does have an acknowledgement mechanism (but PowerDNS
> > masters don't
> > do a lot with it) but no ordering. It's easier to lose things with NOTIFY
> > than with
> > other rep
> Many protocols for distribution of data have a certain ordering and an
> acknowledgement mechanism. NOTIFY does have an acknowledgement mechanism (but
> PowerDNS masters don't do a lot with it) but no ordering. It's easier to lose
> things with NOTIFY than with other replication protocols.
T
On 08.11.2012 22:48, a b wrote:
> Using purely DNS for zone replication (supermaster) is nice and sounds
> great, but also has disadvantages, e.g. it is not reliable: If the
> NOTIFY could not be delivered to the slave, then the slave is
> inconsistent. So, you need another mechanism to ver
Hello,
On Nov 8, 2012, at 22:48 , a b wrote:
> > Using purely DNS for zone replication (supermaster) is nice and sounds
> > great, but also has disadvantages, e.g. it is not reliable: If the
> > NOTIFY could not be delivered to the slave, then the slave is
> > inconsistent. So, you need anothe
> Using purely DNS for zone replication (supermaster) is nice and sounds
> great, but also has disadvantages, e.g. it is not reliable: If the
> NOTIFY could not be delivered to the slave, then the slave is
> inconsistent. So, you need another mechanism to verify and update slaves
> which failed
On 29.10.2012 19:55, 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 transfer requests on port 53.
Il 31/10/2012 21:17, Peter van Dijk ha scritto:
This idea pushes all my buttons with regards to having PowerDNS
provide the right infrastructure and leaving the glue to the user.
Would you write a ticket at wiki.powerdns.com about it so we can have
a more targeted discussion there? Tickets tend
> instead of adding the requested feature to PowerDNS, is possible to add
> 2 feautures to pdns_control:
>
> 1) pdns_control list_domains, which will return all domains managed by
> PowerDNS
>
> 2) pdns_control delete $domain, which will perform the zone deletion
>
> These two function will he
Hello Andrea,
On Oct 31, 2012, at 20:23 , Andrea Cappelli wrote:
> Il 31/10/2012 10:00, Peter van Dijk ha scritto:
>> I responded to that about 10 hours after you first asked it. Was anything in
>> my response unclear? Kind regards,
>
> Hello Peter,
> instead of adding the requested feature to
Il 31/10/2012 10:00, Peter van Dijk ha scritto:
I responded to that about 10 hours after you first asked it. Was
anything in my response unclear? Kind regards,
Hello Peter,
instead of adding the requested feature to PowerDNS, is possible to add
2 feautures to pdns_control:
1) pdns_control l
Hello,
On Oct 30, 2012, at 19:18 , k...@rice.edu wrote:
> It would be hideously ugly, but you could leverage a special content DNS
> record to allow the super master to tell the slave that the domain is or
> will be deleted. It would require a little bit of smarts/timing and
> cooperation
> but
Hello,
On Oct 30, 2012, at 14:50 , a b wrote:
> My main question still remains unanswered though: one of the main reasons we
> ditched BIND was the supermaster / superslave functionality.
>
> If I open a request for enhancement, how much impetus inside of PowerDNS is
> there to implement this
> 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
> 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 a decent indicator of master
> >> uptime
> 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 transfer requests on port 53.
We explicitly do not want to depend
Hi,
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 a decent indicator of master
uptime, in the current implementation. Note that THIS MIGHT
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 a decent indicator of master uptime, in the current
> implementation. Note that THIS MIGHT CHANGE.
If someone happens to have, or in
On 28.10.2012 23:13, a b wrote:
> > How to get PowerDNS to delete zones that are deleted on a Supermasters?
>
> I don't think that is possible: you'll have to delete zones manually
> from your PowerDNS `domains` and `records` tables.
If I have a large PowerDNS deployment, let us say one su
Hello,
On Oct 28, 2012, at 23:13 , a b wrote:
> > > How to get PowerDNS to delete zones that are deleted on a Supermasters?
> >
> > I don't think that is possible: you'll have to delete zones manually
> > from your PowerDNS `domains` and `records` tables.
>
> If I have a large PowerDNS deployme
> > How to get PowerDNS to delete zones that are deleted on a Supermasters?
>
> I don't think that is possible: you'll have to delete zones manually
> from your PowerDNS `domains` and `records` tables.
If I have a large PowerDNS deployment, let us say one supermaster and ten
superslaves, I'm exp
> How to get PowerDNS to delete zones that are deleted on a Supermasters?
I don't think that is possible: you'll have to delete zones manually
from your PowerDNS `domains` and `records` tables.
-JP
___
Pdns-users mailing list
Pdns-users@mailman.
Hey guys,
I'm running a PowerDNS setup with some Supermasters. This is a great
feature and does work as it should. The problem is, that I cannot find a
way to automatically delete a zone on PowerDNS when it is deleted on
Supermaster.
PowerDNS gets notified when zone is deleted on Supermaster.
36 matches
Mail list logo