[Pdns-users] Reverse DNS - sqlite backend

[Andy Rabagliati]

On Wed, 17 Jan 2007, Augie Schwer wrote:

> On 1/16/07, Andy Rabagliati <andyr at wizzy.com> wrote:
> >INSERT INTO domains 
> >VALUES(1,'78.21.196.in-addr.arpa','196.21.78.18',NULL,'SLAVE',NULL,NULL);
> 
> The thing that jumps out to me is the above; if you don't specify a
> master for the slave zone or a supermaster, then the backend probably
> won't know who to query for updates, or whom to accept notifies from.

The table was created as follows :-

  create table domains ( id INTEGER PRIMARY KEY, name VARCHAR(255) NOT
  NULL, master VARCHAR(20) DEFAULT NULL, last_check INTEGER DEFAULT NULL,
  type VARCHAR(6)+NOT NULL, notified_serial INTEGER DEFAULT NULL, account
  VARCHAR(40) DEFAULT NULL );

Thus the name is 78.21.196.in-addr.arpa, and the master is 196.21.78.18.

I have been reading RFC 2317, and I do not believe I need to slave the
entire class C 196.21.78.* in order to be authoritative for our /28, and
I have contacted our upstream to see if we can drop that.

They still need to slave our zone 16-31.78.21.196.in-addr.arpa according
to RFC 2317.

Regarding " Remote 196.21.78.18 sneaked in out-of-zone data
   'kingklip.aims.ac.za' during AXFR of zone '78.21.196.in-addr.arpa'"

I believe this is out-of-zone Glue that is being tossed in with the zone
transfer - something South African ISPs have been doing for a while. It
might have been useful when connectivity was poorer last decade, but I
do not think there is a place for it now. Glue is only needed when
nameservers are in-zone, I think.

This is all legacy stuff, and I think it has all been here for a while
because it worked-and-dont-fix-it - if we drop slaving the Class C many
of these issues become moot.

Cheers,   Andy!