Proposed also-notify support

[anon]

Summary

"also-notify" is a configuration parameter in BIND that tells the DNS server to send a NOTIFY packet to servers other than the ones listed as authoritative for the zone. So when the DNS server sends out NOTIFY to the NS set, it also sends NOTIFY to any additional hosts listed in the configuration file. We use this in our environment because we use hidden distribution masters which are not in the NS set.

I noticed that there was a stub for supporting also-notify in PowerDNS, but that there was no implementation on any of the backends.

Since it did not seem too tricky, I implemented this for the generic SQL backend. I think it should work for any of the databases supported by this backend.

Details

Here's how it works:

• The administrator creates a new table, "alsonotify", like this:

  CREATE TABLE alsonotify (
      ip VARCHAR(128) NOT NULL,
      domain VARCHAR(255) NOT NULL,
      PRIMARY KEY (ip, domain)
  );
  CREATE INDEX alsonotify_d_idx ON alsonotify (domain);
  

• By default an SQL query that returns no values is used (for compatibility reasons, see discussion below). In order to tell PowerDNS to look up in the alsonotify table the query needs to be set in the pdns.conf configuration file, like this:

  gpgsql-also-notifies-query=select ip from alsonotify where domain='%s'
  

• If the administrator wants notifies sent to additional hosts when a zone is updated, an entry is added to the table:

  INSERT INTO alsonotify (domain, ip) VALUES ('example.com', '192.0.2.1:5353');
  INSERT INTO alsonotify (domain, ip) VALUES ('example.com', '[2001:db8::1]:5353');
  

  Note that a non-standard port can be used (53 is the default if none is specified).
• Whenever PowerDNS would send a NOTIFY, it will perform the lookup and send notifies to the additional hosts, just like it would to the hosts in the NS-set.

Schema

Unfortunately this requires an incompatible SQL schema change. It would be possible for PowerDNS to check to see if the necessary SQL query works and only use also-notify if this is working, but I don't know if PowerDNS does this kind of thing. If that makes sense, I can add the code for this.

The schema does not use the "id" column from the "domains" table, it simply uses the name. There is no special reason for this, but since the "name" column is unique I did not see much benefit to using the "id", and it would require a JOIN on every also-notify query.

I did not set the "alsonotify" table to cascade on deletes from the "domains" table, but it probably should.

Documentation

I didn't add any documentation about the feature. Of course this should be done, but I figured it would be best to wait until the details were discussed.

Shane Kerr
shane@…

[anon]

For consistency with the records table I think it'd be nicer to use the id (instead of the name). The join should be pretty cheap. Indeed for a Very Large database it might even be better because the alsonotify table will be smaller.

Speaking of smaller - if you want the primary key to span ip and name, it should be the other way around -- that way the InnoDB tables will cluster the data by name (as you set it up the data will be clustered by IP, which i don't think is useful for the query).

• Ask Bjørn Hansen <ask@…>

[anon]

added bind also-notify too

[ahu]

This has been fixed differently in 3.0 via the domainmetadata table, which is more generic.

Thanks!