PDNS run levels

[rpvw]

So v68 bought a lot of eagerly anticipated new features.......and seemed to have gone backwards at the same time.

Secondly......pdns

Every upgrade seems to reset the run-levels for bind to being enabled for levels 2345 which breaks the DNSSEC. (I run pdns)

So I have to run chkconfig named off --level 2345 and then restart pdns to get the DNS system working. I have no idea what keeps resetting the run-levels, but they don't survive an cPanel upgrade or reboot.

 

[cPanelKenneth]

Hi,

To be clear, are you using the cPanel provided PowerDNS?

 

[rpvw]

Correct - I switched from Bind to PowerDNS back when cPanel started to offer DNSSEC by going to Service Configuration >> Nameserver Selection and choosing PowerDNS and clicking Save. The change seemed to work without issue, and no errors were seen.

I have been delighted with pdns, and the DNSSEC seems to work perfectly - the only annoying thing is getting it up and running properly after a upgrade/reboot.

Typically, I see :
Errors in the reported DNSSEC keys immediately following a reboot
Slow resolution of all DNS queries
Bind (named) has reverted to runlevels 2345
Restarting pdns does not always start clean, even if I kill named first and run chkconfig named off --level 2345 - I sometimes then have to restart pdns 2 or 3 times before it starts clean.
Once a clean start has been achieved, all DNSSEC records no longer show any errors, and all DNS queries to the server are lightning fast.

It is not a show stopper by any means - I am sure it was something that may have gone wrong when I changed over to pdns some time(months?, years?) ago that has probably subsequently been addressed and therefor not easy to replicate.

 

[cPanelMichael]

Hi @rpvw,

Could you open a support ticket using the link in my signature so we can take a closer look at your system?

Thank you.

 

[rpvw]

Ticket ID: 8998673

Well I give up.

I have tried over a couple of years to help both cPanel and other users as best I can, but apparently I am now either too inept or incapable of following a simple set of instructions and get a support request authorized to help with a server.

In spite of double checking that cPanel IPs were white listed in the firewall and in Host access, all I got was timeouts during the connection checks.

My system even claims to have an open ticket Ticket ID: 8998643 Stub ticket that I see no record of in my cPanel Customer Portal list of open or closed requests....and guess what....I cant get that to authenticate either !

Very frustrating, and a horrible and stressful experience. (Not that I am expecting anyone to care)

 

[rpvw]

To update, A patient and professional support analyst JimmyB.restored my faith in there being someone out there that cared, and finally got me connected to the support system, and passed me off to a Level 2 Analyst.

In case anyone else has similar problems whilst running a SSH connection test, here are samples of results I got in my log whilst trying to test the connection from the Grant or Revoke cPanel Support’s Access page in WHM, and which only resulted in a timeout.

: error: PAM: Authentication failure for illegal user _+_+cPanel_Support_SSH_Connection_Test+_+_ from 208.74.123.98
: Failed keyboard-interactive/pam for invalid user _+_+cPanel_Support_SSH_Connection_Test+_+_ from 208.74.123.98 port 50385 ssh2
: error: PAM: Authentication failure for illegal user _+_+cPanel_Support_SSH_Connection_Test+_+_ from 208.74.121.106
: Failed keyboard-interactive/pam for invalid user _+_+cPanel_Support_SSH_Connection_Test+_+_ from 208.74.121.106 port 5822 ssh2

Anyway Jimmy was able to get us connected with the help of a command line 'fix' and handed me over to a level 2 analyst that spent some time confirming that what I had reported for months was in fact true, and that something was starting the bind server on boot which shouldn't happen if pdns was in use, and that he couldn't find what the problem was, and he was going to "escalate this inquiry to our Level 2 Analysts for a closer look." (Now I had been told this gentleman was a level 2 Technical Analyst, so I am not sure of how the escalation was going to work)

Being over 60, I find it hard to stay awake all night, but nevertheless, on the basis that cPanel could be bothered to take a look, the least I could do was to extend the courtesy of being there if they wanted anything.

Regrettably, my all night vigil was in vain. No further words of wisdom were received from cPanel, nor did anyone even log in to look.

Once again, I am left with the guilty feeling that somehow, my attempt to help and provide feedback to cPanel was regarded as a waste of their time.

Frankly the effort and frustrations of trying to be helpful have turned out to be a thoroughly disagreeable process.

 

[rpvw]

As a last attempt at trying to be helpful:

I just installed a new kernel and rebooted and the BIND server did not start, the pdns server did, and non of the run-levels have changed for either service - so - I can only logically come to the conclusion that it is something that happens during a cPanel update that is responsible for changing the named run-levels and provoking BIND to start at the next reboot.

This does not appear to happen during a normal upcp that has no cPanel upgrade content, but I shall continue to monitor and see if I can pin down what this issue is, if indeed it continues to be an issue at all.

 

[cPanelMichael]

Hello @rpvw,

Thank you for your patience while helping us to investigate this issue. It looks like our Technical Analysts have been unable to reproduce the issue on our test systems. I just made an additional attempt to reproduce the issue (matching the same environment), but was unable to replicate the behavior. It looks like we are going to open a tracking case for this issue to start tagging instances where this occurs. I'll monitor the support ticket and update this thread with the outcome and case number.

Thank you.

 

[cPanelMichael]

Hello,

To update, the internal case number is CPANEL-16787. I'll monitor this case and update this thread with more information as it becomes available. I encourage anyone else facing the issue to open a support ticket referencing this case number so we can track reports of how often this is happening and under which environments.

Thank you.

 

[cPanelMichael]

Hello,

To update, internal case CPANEL-16787 has been closed due to a lack of additional reports of this happening and an inability to reproduce the issue in a test environment. Please feel free to let us know if you experience this issue again in the future.

Thank you.