Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dnsdist: disabled servers return latency as 'null' which breaks webinterface #7461

LordGaav opened this issue Feb 7, 2019 · 1 comment · Fixed by #7586

dnsdist: disabled servers return latency as 'null' which breaks webinterface #7461

LordGaav opened this issue Feb 7, 2019 · 1 comment · Fixed by #7586


Copy link

LordGaav commented Feb 7, 2019

  • Program: dnsdist
  • Issue type: Bug report

Short description

The dnsdist webinterface breaks when a server is marked as down using getServer(x):setDown(). The reason for this is that the 'latency' value from /api/v1/servers/localhost is returned as null, which in turn is read by the webinterface. The webinterface tries to show this value as a two decimal number, which causes an JS error. This causes the entire servers table to not be updated, until the server is marked as up again.

Servers that are marked as down by dnsdist itself do not show this behaviour.


  • Operating system: Ubuntu 14.04 + Firefox 65 and Chrome 71
  • Software version: dnsdist 1.3.3
  • Software source: PowerDNS Debian package for Ubuntu 18.04

Steps to reproduce

  1. Load any config with at least one server and enable webinterface and client socket.
  2. Open webinterface in browser, see that the servers table is updated as normal.
  3. Use dnsdist -c to connect to the running dnsdist instance and set the server down using getServer(0):setDown().
  4. The servers table in the webinterface is now broken, and JS errors are show in the browser console.

Expected behaviour

The table should not break when servers are marked as down.

Actual behaviour

The table breaks when a server is marked as down.

Other information

We should either not return the latency value as null from the API, or have the JS properly handle this case. Seeing as no other values are returned as null when a server is marked down, the first solution seems the most elegant.

Specifically, this line probably causes the behaviour : . I don't agree that hiding the latency for servers that are down is a good idea. If the server has been up, then the latency shown is for when it was responding. Otherwise, we should also null queries, dropRate and sendErrors to be consistent.

Copy link

Well, it seems misleading to me to send a value that is not updated when the backend is down, see #4689 for example. I do agree it might make sense to do the same for qps and dropRate, which are not meaningful for a disabled server. On the other hand sendErrors is a counter so it might make sense to keep it as it is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging a pull request may close this issue.

2 participants