On Mon, 30 May 2011, Charles Sprickman wrote:
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.
I found what this error is telling me. If I manually do an axfr, I see
this:
[root@pdns2 /usr/local/src]# dig @pdns1 pdnsexample.com axfr
; <<>> DiG 9.6.2-P2 <<>> @pdns1 pdnsexample.com axfr
; (1 server found)
;; global options: +cmd
. 3600 IN SOA pdns1.pdnsexample.com.
hostmaster.pdnsexample.com. 1306724880 3600 3600 10800 3600
Note that rather than the domain being the first item on that line it's
just ".". Digging the SOA directly does return the correct answer:
[root@pdns2 /usr/local/src]# dig -t soa @pdns1 pdnsexample.com
[...]
;; ANSWER SECTION:
pdnsexample.com. 3600 IN SOA pdns1.pdnsexample.com.
hostmaster.pdnsexample.com. 1306724880 3600 3600 10800 3600
So perhaps the patch did not take axfrs into account or something in PDNS
has changed since the patch was created.
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.
I cleaned up that error by simply adding the following line to
modules/gsqlite3backend/gsqlite3backend.cc at line 106:
declare(suffix,"domain-lastchange-query","", "select max(change_date)
from records where domain_id=%d");
I'll see if I can figure out the axfr issue, but I don't know much beyond
enough perl and php to be dangerous. :)
Thanks,
Charles
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
_______________________________________________
Pdns-users mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users
