[ale] Anyone out here using PowerDNS?

James Sumners james.sumners at gmail.com
Mon Aug 17 13:48:21 EDT 2015


Ugh, I left the BIND garbage at the curb in total when I switch to PDNS. So
I can't say how the BIND backend would work on slaves. I'm using sqlite3 on
one slave and Postgres on my others (evidently I missed removing sqlite3
from one; I'll need to fix that).

Depending on which version of PDNS you're using, there's also the
"ALSO-NOTIFY" mechanism. I'm using PDNS 3.3.x and have these notes
regarding that method:

```
This method allows you to notify slaves that are not listed in the zone's
NS records. Any slave specified by the ALSO-NOTIFY system gets sent
notifications at the same time NS record notifications are sent. For the
AXFR transfer to succeed, the ALSO-NOTIFY servers must still be allowed to
do AXFR transfers from the server that sent them the notification.

Domain Metadata Table[edit]
For this setup to work, the following requirements must be met:

The PowerDNS backend must support DNSSEC
The PowerDNS backend database must have DNSSEC compatible tables
The PowerDNS server must enable DNSSEC via its configuration with a
'-dnssec' setting (e.g. "gpgsql-dnssec=yes")
The zone doesn't actually have to be serving DNSSEC data. PowerDNS just
chose to implement this feature in its DNSSEC capable backends. DNSSEC must
be enabled for each zone, so if a zone is not enabled for DNSSEC no DNSSEC
data will be served. But the ALSO-NOTIFY will still happen.

For each zone and slave that will be notified in the manner, a record must
be added to the supermaster's "domainmetadata" table. For example, if we
have a zone example.com with a domain id of "42" in the database, and we
want to notify nsext.example.com who's IP is 10.0.0.2, we would do:

INSERT INTO domainmetadata (domain_id, kind, content) VALUES (42,
'ALSO-NOTIFY', '10.0.0.2');
Config File[edit]
This works the same as the domain metadata table, the servers are just
listed in the PowerDNS configuration file. But this feature is only
available in PowerDNS 3.4 and later. At the time of this writing, we are
using 3.3.x so we have to use the domain metadata table method.

also-notify=10.0.0.2,10.0.0.3
only-notify=10.0.0.2,10.0.0.3
Note, this feature also adds the concept of "only-notify". With the
only-notify setting set, only those servers will be notified. Thus, an NS
records that are not listed in the only-notify setting will not be notified.
```

On Mon, Aug 17, 2015 at 1:38 PM, Scott Bragg <walkingbear at gmail.com> wrote:

> James,
>
> My configuration is as follows:
>
> 3 locations, each with 1 master + 3 slaves.    The masters use the
> postgresql backend located on a single DB in our primary location.  The
> slaves use the bind backend and store the received zone files locally.
>
> The pdns configs are correct and this system's been running for more than
> a year.
>
> I'm not using supermasters as we deploy new slaves manually and have only
> added one new slave in each location in the year+ we've been running this
> configuration.
>
> The one thing I don't have is the master IPs in the domains table for each
> zone.   I'd need to figure out if I can have multiple ips in that list
> since I have three masters serving the same zones.
>
> Scott
>
>
> On Mon, Aug 17, 2015 at 12:26 PM, James Sumners <james.sumners at gmail.com>
> wrote:
>
>> What is your configuration like? For example, I have a "master" and a
>> couple "slave" systems. When a change is made on the master system it sends
>> out a notification to the slaves that they need to pickup the update. My
>> slave systems, according to my logs, are checking in with the master
>> systems every so often to verify their data. Since no changes have
>> occurred, they report "Domain 'example.com' is fresh..." and do not
>> initiate an AXFR.
>>
>> It took me a while to wrap my head around how to configure the PDNS
>> master/slave setup. But here's a short rundown:
>>
>> Master Server
>> 1) pdns.conf has `master=yes`, `disable-axfr=no`, and `allow-axfr-ips=...`
>> 2) zones to be replicated to slaves must have "master" in their "type"
>> column in the database (assuming you're using the manual's schema)
>>
>> Slave Server
>> 1) pdns.conf has `slave=yes`
>> 2) the "supermasters" table must include a record for the supermaster
>> server. e.g. ip_col = 'ip.address.of.master', nameserver_col = 'local
>> server fqdn', account_col = 'whatever'
>>
>> Here's a special note from my internal wiki: "each zone in the "domains"
>> table on the slave systems has an entry in its "master" column with the
>> value set to the IP address of the master server. This is set automatically
>> on the initial transfer. If you change the configuration of the master,
>> remember to update this column."
>>
>> Which is to say, if you change the IP address of the master server then
>> you need to remember to update your slave tables.
>>
>> On Mon, Aug 17, 2015 at 11:28 AM, Scott Bragg <walkingbear at gmail.com>
>> wrote:
>>
>>> I have a couple of questions on how PowerDNS authoritative servers pull
>>> zones from a PostgreSQL backend.   Is it normal for them to do a full zone
>>> transfer every X minutes when the SOA TTL is set to X, even if the serial
>>> for that zone hasn't changed?
>>>
>>> Scott
>>>
>>>
>>> _______________________________________________
>>> Ale mailing list
>>> Ale at ale.org
>>> http://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>>
>>>
>>
>>
>> --
>> James Sumners
>> http://james.sumners.info/ (technical profile)
>> http://jrfom.com/ (personal site)
>> http://haplo.bandcamp.com/ (band page)
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
>>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>


-- 
James Sumners
http://james.sumners.info/ (technical profile)
http://jrfom.com/ (personal site)
http://haplo.bandcamp.com/ (band page)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150817/4d0382f0/attachment.html>


More information about the Ale mailing list