[ale] Anyone out here using PowerDNS?

Mon Aug 17 14:01:21 EDT 2015

I'm running 3.2 on the masters and 3.3 on the slaves.   For 'Reasons(tm)'
 I can't yet update the DB schema and move everything up to 3.4.    We're
not using DNSSEC at all.

However, I think we're getting pretty far afield of my original question.
In much more detail, the behavior I'm seeing is as follows:

My TTL in my SOA records for my zones is 2 minutes.
Every two minutes, my masters poll the DB and pull the SOA records to see
if the serial as been incremented.
Even if the serial has not changed, it still initiates a pull from the DB
of the entire zone file.   It does not initiate a a notify to the slaves.

This results in 200GB+ in bandwidth per day between the database and the
three masters.   If I do the following calculation:   $Size_of_Zones *
$num_masters * $num_polls_per_hour * 24 == approx bandwidth in use.
 Since my zone files are about 100mb total with three masters polling and
pulling every 2 minutes, my calculations show the same thing that my
network monitors show; ie... ~ 200GB / day.

Scott

On Mon, Aug 17, 2015 at 1:48 PM, James Sumners <james.sumners at gmail.com>
wrote:

> 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)
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150817/2cd7fdd6/attachment.html>