No. I think that was question on some conference, DNS-OARC perhaps.

The proposal was what if bind9, unbound, knot-resolver and pdns-recursor could create the same format for their statistics. So prometheus could have only one statistics parser code. It might be exported to different path in filesystem and that should be enough. Only path and content should be different for different services. Format should ideally stay compatible. Then it would require less code as glue between statistics dashboards used and the DNS service itself.

I think such common format would be great. I would prefer something json based. I can describe only bind9 and unbound statistics. Their format is very different, although quite a lot numbers could be similar.

This is main statistics refactoring issue at bind9

https://gitlab.isc.org/isc-projects/bind9/-/issues/38

I am not sure where exactly did they talk about requirements for a new format, sorry. I think it was mentioned after some talk at some OARC recording, but do not remember which one.

On 21/11/2025 16:02, Paul Wouters wrote:
On Fri, 21 Nov 2025, Petr Menšík via Unbound-users wrote:

Such topic were recently started also on BIND9. If you can document what different statistics is in use now, it might be used to create one common format used by any DNS service. It is silly when each have different format, which can be transformed by some external module into format common on some monitoring service.

I am not sure unbound should offer it on HTTP service socket

Do you mean one of these:

unbound-control stats_noreset
unbound-control stats

Paul

Yes. It would be nice, if it could serve only subtree. Hmm, would be cool, if it could serve CH answer.num.stats. TXT? query? Although that would need some ACL protection.

The then you want to put this into some graph usually. That needs to pick specific fields from these and map them to some graph lines. Every implemetation seems to have very different statistics output format.

Systemd people like Varlink format. That could be usable too.

Petr

--
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

Reply via email to