[Pdns-users] RE ignoring non-query opcode 6

[Jake Hansen]

Hello kind gents,

Someone turned me on to pdns_recursor and i'm trying to deploy it.  I have
a pair of A-10 Load balancers front ending and now the logs are spamming

Ignoring non-query opcode 6 from xx.xx.xx.xx on server socket!

I was googling around and found that sometime ago, a patch was added to
drop non zero opcodes.  I suspect that the opcodes are some sort of keep
alive check by the load balancers.  Should I be worried about this?

Thanks for any info.

Regards,

Jake
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] (PDNSException): Database failed to start transaction: Could not execute mysql statement

[Steve Zeng via Pdns-users]

Hi,

Our PDNS environment is setup on Centos 7 + PDNS Authoritative 4.0.5 + 
mysql-community 5.7

It is noticed that there are regular PowerDNS failure logs below:

2018-02-04T04:29:07.193742+01:00 mpdns.example.com pdns_server[40761]: Feb 04 
04:29:07 Unable to AXFR zone ‘lom.example.com' from remote ‘x.x.x.x:53' 
(PDNSException): Database failed to start transaction: Could not execute mysql 
statement: delete from records where domain_id=?: Lock wait timeout exceeded; 
try restarting transaction

I looked at PowerDNS list of settings at 
https://doc.powerdns.com/md/authoritative/backend-generic-mysql/ 
 and do not 
see any configurable settings for it. Our correct pdns.conf can be seen below:

launch=gmysql
gmysql-host=y.y.y.y
gmysql-user=auser
gmysql-dbname=pdns
gmysql-password=
gmysql-timeout=0

not sure if this cause is on PowerDNS side or MySQL database side. can anybody 
shed a light here? 

Thanks,
Steve

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] Why the rectify-zone? increase-serial?

[Steve Atkins]

> On Feb 6, 2018, at 12:29 AM, Sander Smeenk via Pdns-users 
>  wrote:
> 
> Quoting Sander Smeenk via Pdns-users (pdns-users@mailman.powerdns.com):
> 
>> Could this not be handled by some logic that compares the serial
>> to the last-rectified serial and rectifies it on the fly when needed?
>> This might not work for super huge zones perhaps, performance wise,
>> but i dont think i would notice anything in my workload. ;-)
> 
> Heh. According to da interweps, this was 'discussed' on list earlier.
> http://powerdns.13854.n7.nabble.com/How-do-you-rectify-zones-tt8633.html#none
> But that thread just boils down to "Yea, you got to rectify-zone yourself." ;)


There is an API call to rectify a zone, so any automation / web front end
could do that as it's final operation when updating a zone, making it
transparent to the user.

On a related note, does anyone know of a good way to check whether a
zone is valid, or not? It's something I'd like to monitor, but I'm not sure
how best to do that. 

Cheers,
  Steve
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] Why the rectify-zone? increase-serial?

[Sander Smeenk via Pdns-users]

Quoting Sander Smeenk via Pdns-users (pdns-users@mailman.powerdns.com):

> Could this not be handled by some logic that compares the serial
> to the last-rectified serial and rectifies it on the fly when needed?
> This might not work for super huge zones perhaps, performance wise,
> but i dont think i would notice anything in my workload. ;-)

Heh. According to da interweps, this was 'discussed' on list earlier.
http://powerdns.13854.n7.nabble.com/How-do-you-rectify-zones-tt8633.html#none
But that thread just boils down to "Yea, you got to rectify-zone yourself." ;)

Rgds,
Sndr.
-- 
| Junk is something you've kept for years and throw away three weeks
| before you need it.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] Why the rectify-zone? increase-serial?

[Sander Smeenk via Pdns-users]

Hi,

Today one of my customers was complaining that his NODATA-proof is
failing after adding CAA-records to a signed domain.
I quickly rectified the zone, flushed the caches, all is well again.

This makes me think about the 'why' behind the rectify-zone command.

We've scripted triggers that rectify a zone after a customer changes
records, most probably that trigger failed in this case, but why
actually do we have to do this manually? Are there any situations
where we do NOT want to rectify-zone after a change? ;-)

Could this not be handled by some logic that compares the serial
to the last-rectified serial and rectifies it on the fly when needed?
This might not work for super huge zones perhaps, performance wise,
but i dont think i would notice anything in my workload. ;-)

| "Volgens Marco Davids, Technisch Adviseur bij SIDN, is het vergeten
| van de rectify-zone-opdracht een van de meest voorkomende fouten
| van dit moment."

Regards,
-Sander.
-- 
| Spend some time trying hard not to think about giraffes.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users