On Wed, 17 Jan 2007, Augie Schwer wrote: > On 1/16/07, Andy Rabagliati <[EMAIL PROTECTED]> 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! _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
