Hello Adrian,
On Apr 29, 2013, at 3:22 , Adrian Pasa wrote:
> I was wondering if any of the backends, ideally the remote or the pipe
> backend, would pass along additional information (A SIP URI) sent in the
> RDATA portion of an [EDNS0] OPT RR as outlined in
> http://tools.ietf.org/html/draft
Hello James,
On May 13, 2013, at 22:35 , James Cloos wrote:
> PvD> As far as I can tell, the time of day does not come into play in slaving
> decisions.
>
> Doesn't the slave re-create sigs?
For a slave to create sigs, it needs the private keys. Only a native (MySQL
replication for example) sl
> "PvD" == Peter van Dijk writes:
>> When using axfr slaving, how much lack of tod sync can pdns tolerate?
>>
>> Centiseconds? Deciseconds? Seconds? Dekaseconds? Hectoseconds?
PvD> As far as I can tell, the time of day does not come into play in slaving
decisions.
Doesn't the slave r
On Mon, May 13, 2013 at 6:18 PM, Peter van Dijk
wrote:
> We have spoken to Google and their investigation has uncovered a bug in their
> validator, causing this behaviour. They will fix it. Thank you for your
> report!
…and the world became a better place, again. :-)
Great!
g
Hello Christof,
On May 7, 2013, at 10:39 , Christof Meerwald wrote:
> Note that there is no "ad" flag and the TTL is set to 0 - but
> powerdnssec.org on the other hand appears to be fine:
> Does anyone have any insights into this behaviour?
We have spoken to Google and their investigation has u
Hello James,
On May 11, 2013, at 2:52 , James Cloos wrote:
> When using axfr slaving, how much lack of tod sync can pdns tolerate?
>
> Centiseconds? Deciseconds? Seconds? Dekaseconds? Hectoseconds?
As far as I can tell, the time of day does not come into play in slaving
decisions.
Kind r
Hello Thomas,
On May 13, 2013, at 12:11 , Thomas Mieslinger wrote:
> To be able to understand these problems in a live system I would like to have
> some sort of tracing facility in pdns_recursor which can be turned on and off
> without restarting the service.
>
> Ideally pdns_recursor would p
Dear PowerDNS Developers,
every now and then one of our internal customer calls and says "this and
that record doesn't resolve whereas it works when using google opendns
or dig +trace".
And they are right :-( For example
dig -x 194.95.67.2
pdns_recursor 3.3 sometimes only reports the cname
