[Pdns-users] 3.0-RC2 state of auto serial?

[Charles Sprickman]

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 at 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 at 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 at 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
>> Pdns-users at mailman.powerdns.com
>> http://mailman.powerdns.com/mailman/listinfo/pdns-users
>> 
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users
>