<div dir="ltr"><div>I&#39;m running 3.2 on the masters and 3.3 on the slaves.   For &#39;Reasons(tm)&#39;  I can&#39;t yet update the DB schema and move everything up to 3.4.    We&#39;re not using DNSSEC at all.  </div><div><br></div>However, I think we&#39;re getting pretty far afield of my original question.   In much more detail, the behavior I&#39;m seeing is as follows: <div><br></div><div>My TTL in my SOA records for my zones is 2 minutes.  <br>Every two minutes, my masters poll the DB and pull the SOA records to see if the serial as been incremented.  </div><div>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.  <br><br>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.   <br><br>Scott</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 1:48 PM, James Sumners <span dir="ltr">&lt;<a href="mailto:james.sumners@gmail.com" target="_blank">james.sumners@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ugh, I left the BIND garbage at the curb in total when I switch to PDNS. So I can&#39;t say how the BIND backend would work on slaves. I&#39;m using sqlite3 on one slave and Postgres on my others (evidently I missed removing sqlite3 from one; I&#39;ll need to fix that).<div><br></div><div>Depending on which version of PDNS you&#39;re using, there&#39;s also the &quot;ALSO-NOTIFY&quot; mechanism. I&#39;m using PDNS 3.3.x and have these notes regarding that method:</div><div><br></div><div>```</div><div><div>This method allows you to notify slaves that are not listed in the zone&#39;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.</div><div><br></div><div>Domain Metadata Table[edit]</div><div>For this setup to work, the following requirements must be met:</div><div><br></div><div>The PowerDNS backend must support DNSSEC</div><div>The PowerDNS backend database must have DNSSEC compatible tables</div><div>The PowerDNS server must enable DNSSEC via its configuration with a &#39;-dnssec&#39; setting (e.g. &quot;gpgsql-dnssec=yes&quot;)</div><div>The zone doesn&#39;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.</div><div><br></div><div>For each zone and slave that will be notified in the manner, a record must be added to the supermaster&#39;s &quot;domainmetadata&quot; table. For example, if we have a zone <a href="http://example.com" target="_blank">example.com</a> with a domain id of &quot;42&quot; in the database, and we want to notify <a href="http://nsext.example.com" target="_blank">nsext.example.com</a> who&#39;s IP is 10.0.0.2, we would do:</div><div><br></div><div>INSERT INTO domainmetadata (domain_id, kind, content) VALUES (42, &#39;ALSO-NOTIFY&#39;, &#39;10.0.0.2&#39;);</div><div>Config File[edit]</div><div>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.</div><div><br></div><div>also-notify=10.0.0.2,10.0.0.3</div><div>only-notify=10.0.0.2,10.0.0.3</div><div>Note, this feature also adds the concept of &quot;only-notify&quot;. 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.</div></div><div>```</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 1:38 PM, Scott Bragg <span dir="ltr">&lt;<a href="mailto:walkingbear@gmail.com" target="_blank">walkingbear@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">James, <div><br></div><div>My configuration is as follows: <br><br>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.  <br><br>The pdns configs are correct and this system&#39;s been running for more than a year.   <br><br>I&#39;m not using supermasters as we deploy new slaves manually and have only added one new slave in each location in the year+ we&#39;ve been running this configuration.    </div><div><br></div><div>The one thing I don&#39;t have is the master IPs in the domains table for each zone.   I&#39;d need to figure out if I can have multiple ips in that list since I have three masters serving the same zones.   <span><font color="#888888"><br><br>Scott<br><br></font></span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 12:26 PM, James Sumners <span dir="ltr">&lt;<a href="mailto:james.sumners@gmail.com" target="_blank">james.sumners@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What is your configuration like? For example, I have a &quot;master&quot; and a couple &quot;slave&quot; 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 &quot;Domain &#39;<a href="http://example.com" target="_blank">example.com</a>&#39; is fresh...&quot; and do not initiate an AXFR.<div><br></div><div>It took me a while to wrap my head around how to configure the PDNS master/slave setup. But here&#39;s a short rundown:</div><div><br></div><div>Master Server</div><div>1) pdns.conf has `master=yes`, `disable-axfr=no`, and `allow-axfr-ips=...`</div><div>2) zones to be replicated to slaves must have &quot;master&quot; in their &quot;type&quot; column in the database (assuming you&#39;re using the manual&#39;s schema)</div><div><br></div><div>Slave Server</div><div>1) pdns.conf has `slave=yes`</div><div>2) the &quot;supermasters&quot; table must include a record for the supermaster server. e.g. ip_col = &#39;ip.address.of.master&#39;, nameserver_col = &#39;local server fqdn&#39;, account_col = &#39;whatever&#39;</div><div><br></div><div>Here&#39;s a special note from my internal wiki: &quot;each zone in the &quot;domains&quot; table on the slave systems has an entry in its &quot;master&quot; 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.&quot;</div><div><br></div><div>Which is to say, if you change the IP address of the master server then you need to remember to update your slave tables.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Aug 17, 2015 at 11:28 AM, Scott Bragg <span dir="ltr">&lt;<a href="mailto:walkingbear@gmail.com" target="_blank">walkingbear@gmail.com</a>&gt;</span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir="ltr">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&#39;t changed?  <span><font color="#888888"><div><br>Scott</div><div><br></div></font></span></div>
<br></span>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><span><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div>James Sumners<br><a href="http://james.sumners.info/" target="_blank">http://james.sumners.info/</a> (technical profile)</div><div><a href="http://jrfom.com/" target="_blank">http://jrfom.com/</a> (personal site)</div><div><a href="http://haplo.bandcamp.com/" target="_blank">http://haplo.bandcamp.com/</a> (band page)</div></div></div></div></div>
</span></div>
<br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div>James Sumners<br><a href="http://james.sumners.info/" target="_blank">http://james.sumners.info/</a> (technical profile)</div><div><a href="http://jrfom.com/" target="_blank">http://jrfom.com/</a> (personal site)</div><div><a href="http://haplo.bandcamp.com/" target="_blank">http://haplo.bandcamp.com/</a> (band page)</div></div></div></div></div>
</div>
</div></div><br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><br></div>