On Sun, 29 May 2011, Charles Sprickman wrote:
Hello all,
I am just becoming a daily poster here, aren't I?
I'm having some issues with the auto serial generation. The docs say that if
I have a serial of "0" specified in the SOA record, PDNS will look at the
most recent "change_date" entry in the records table and auto-generate a
serial for the zone based on that.
I had some trouble digging this up, but it appears this bug is still open:
http://wiki.powerdns.com/trac/ticket/301
The patch for svn applied to 3.0-RC2 and at least on the master side it
works correctly:
;; ANSWER SECTION:
pdnsexample.com. 3600 IN SOA pdns1.pdnsexample.com.
hostmaster.pdnsexample.com. 1306724880 3600 3600 10800 3600
However, a slave running gsqlite3 backend and without the patch does not
like the answer it receives:
May 30 04:43:51 pdns2 pdns[90220]: AXFR started for 'pdnsexample.com',
transaction started
May 30 04:43:51 pdns2 pdns[90220]: Remote 207.99.117.38 tried to sneak in
out-of-zone data ''|SOA during AXFR of zone 'pdnsexample.com', ignoring
May 30 04:43:51 pdns2 pdns[90220]: AXFR done for 'pdnsexample.com', zone
committed
In that case, everything gets updated, but the SOA record.
If I run the patched binary on the slave, then it looks like the patch has
not fixed up everything needed to make the gsqlite3 backend work
correctly:
May 30 04:51:45 pdns2 pdns[65150]: Master/slave communicator launching
May 30 04:51:45 pdns2 pdns[65150]: Caught an exception instantiating a
backend, cleaning up
May 30 04:51:45 pdns2 pdns[65150]: TCP server is unable to launch backends
- will try again when questions come in: Undefined but needed argument:
'gsqlite3-domain-lastchange-query'
May 30 04:51:45 pdns2 pdns[65150]: About to create 3 backend threads for
UDP
May 30 04:51:45 pdns2 pdns[65150]: Caught an exception instantiating a
backend, cleaning up
May 30 04:51:45 pdns2 pdns[65150]: Caught an exception instantiating a
backend, cleaning up
May 30 04:51:45 pdns2 pdns[65150]: Communicator thread died because of
error: Undefined but needed argument: 'gsqlite3-domain-lastchange-query'
I'm going to try some rough hacks on
modules/gsqlite3backend/gsqlite3backend.cc to see if I can fix this up.
Charles
I'm currently not seeing that happen. Here's my pgsql records structure and
an example SOA record:
id | domain_id | name | type | content
| ttl | prio | change_date | ordername | auth
----+-----------+-----------------+------+-----------------------------------------------------------------+------+------+-------------+-----------+------
1 | 1 | pdnsexample.com | SOA | pdns1.pdnsexample.com
hostmaster.foo.com 0 3600 3600 10800 3600 | 3600 | 0 | 1306724744 |
|
(1 row)
"change_date" is an integer with a default of "EXTRACT(EPOCH FROM
CURRENT_TIMESTAMP);" and it's currently populated with unix timestamp values
as shown above.
Even after purging the cache, I still get this:
[root@pdns1 /home/spork]# dig @x.x.x.38 -t soa pdnsexample.com
;; QUESTION SECTION:
;pdnsexample.com. IN SOA
;; ANSWER SECTION:
pdnsexample.com. 3600 IN SOA pdns1.pdnsexample.com.
hostmaster.pdnsexample.com. 0 3600 3600 10800 3600
Note the "zero" for the serial line.
Am I doing something wrong? Is "change_date" supposed to be a different
type?
Thanks,
Charles
_______________________________________________
Pdns-users mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users
_______________________________________________
Pdns-users mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users
