[Pdns-users] Pdns-users Digest, Vol 200, Issue 15

Tue Sep 24 17:28:29 UTC 2019

Use SQL replication on all the Slave servers. Making SQL replication will
add speed.

On Tue, 24 Sep 2019 at 5:30 PM, <pdns-users-request at mailman.powerdns.com>
wrote:

> Send Pdns-users mailing list submissions to
>         pdns-users at mailman.powerdns.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mailman.powerdns.com/mailman/listinfo/pdns-users
> or, via email, send a message with subject or body 'help' to
>         pdns-users-request at mailman.powerdns.com
>
> You can reach the person managing the list at
>         pdns-users-owner at mailman.powerdns.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pdns-users digest..."
>
>
> Today's Topics:
>
>    1. How should my backend tell pdns that pdns_server that it has
>       changed the zone (jb-wisemo)
>    2. Re: PowerDNS: One Response Policy Zones refuses to update via
>       IXFR -- always uses AXFR (Otto Moerbeek)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 24 Sep 2019 00:31:30 +0200
> From: jb-wisemo <jb-powerdns at wisemo.com>
> To: pdns-users at mailman.powerdns.com
> Subject: [Pdns-users] How should my backend tell pdns that pdns_server
>         that it has changed the zone
> Message-ID: <cabf1a44-17f8-95e6-ef86-881c0520f2a2 at wisemo.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
> I am creating a custom master-mode backend for a special use. But some
> questions are left open or vague by the documentation, here is the first
> one:
>
> How shall I tell pdns_server that I have changed my zone and increased
> the zone serial in the database?
>
> Idea is to trigger notify and replication to ordinary slaves as quickly
> as possible, being able to tell code elsewhere that the changes should
> now be available in the global DNS (doing my own TTL calculations).
>
> Zone may be unsigned or NSEC3-wide, as NSEC3-narrow doesn't seem to
> support replication to slaves that don't have the ZSK private key.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860
> <https://www.google.com/maps/search/Transformervej+29,+2860?entry=gmail&source=g>
> S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 24 Sep 2019 08:04:22 +0200
> From: Otto Moerbeek <otto at drijf.net>
> To: Simon Forster <forster at deteque.com>
> Cc: pdns-users at mailman.powerdns.com
> Subject: Re: [Pdns-users] PowerDNS: One Response Policy Zones refuses
>         to update via IXFR -- always uses AXFR
> Message-ID: <20190924060422.GG86353 at clue.drijf.net>
> Content-Type: text/plain; charset=utf-8
>
> On Mon, Sep 23, 2019 at 07:07:32AM +0200, Otto Moerbeek wrote:
>
> > On Sun, Sep 22, 2019 at 07:37:29PM +0100, Simon Forster wrote:
> >
> > > Hi
> > >
> > > We have a customer consuming a bunch of Response Policy Zones using
> PowerDNS. For all bar one, all is good. However, one zone (bogons.ip.dtq)
> refuses to update via IXFR. Every update is via AXFR.
> > >
> > > In an attempt to troubleshoot, our engineer created a Docker image
> that ran PowerDNS Recursor 4.2.0 under Debian 9 (squeeze), the latest
> general release version. PowerDNS was pulled down from PowerDNS's
> repository rather than complied by us.
> > >
> > > The lua-config-file entry in recursor.conf was modified to include a
> single lua file that contained a single rpzMaster declaration:
> > >
> > >     rpzMaster("199.168.90.51",
> > > "bogons.ip.dtq",{defpol=Policy.NXDOMAIN,refresh=300})
> > >
> > > The testing ended up producing the same errors as the customer?s
> (undocumented) setup:
> > >
> > > Sep 21 20:36:55 Loading RPZ zone 'bogons.ip.dtq' from <redacted>
> > > Sep 21 20:36:55 Loaded & indexed 418 policy records so far for RPZ
> zone 'bogons.ip.dtq'
> > > Sep 21 20:36:56 Loaded & indexed 36887 policy records so far for RPZ
> zone 'bogons.ip.dtq'
> > > Sep 21 20:36:56 Unable to load RPZ zone 'bogons.ip.dtq? from
> '<redacted>': 'Unable to convert '1:0:0:0' to a netmask'. (Will try again
> in 300 seconds?)
> > >
> > > The error message regarding '1:0:0:0?  was originally thought to be a
> problem parsing one record in the bogons.ip.dtq zone: "0.0.0.1::/64?.
> However, in testing this was manually redacted and it was confirmed that
> the CIDR no longer existed in the rpz zone data we push out. The error
> message persisted in the PowerDNS resolver logs.
> > >
> > > Conclusions:
> > >
> > > ? The error has nothing to do with the CIDR 0.0.0.1::/64 being
> included in the zone.
> > > ? rpz parsing of RPZ zones has a bug. Our engineer points to IPv6
> triggers.
> > > ? Our engineer doesn?t like PowerDNS? logging. This last point
> probably is irrelevant to everyone except our engineer.
> > >
> > > I?ve been something of a PowerDNS proponent but I?ve failed to gain
> traction internally. This is not helping my case. Is this a known issue?
> > >
> > > TIA
> > >
> > > Simon
> >
> > Looking at the RPZ related issues in
> > https://github.com/PowerDNS/pdns/issues I don't see an obvious match.
> >
> > Please file an issue and include all relevant (unredacted) data,
> > including the RPZ data so that reproductioin and further investigation
> > is possible.
>
> See https://github.com/PowerDNS/pdns/pull/8340
>
>         -Otto
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/pdns-users
>
>
> ------------------------------
>
> End of Pdns-users Digest, Vol 200, Issue 15
> *******************************************
>
-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20190924/a37394b0/attachment.htm>