dearsky/numa
1
0
Fork 0
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases 25 Wiki Activity

Dashboard doesn't count forwarded queries #144

New Issue
Closed
opened 2026-04-24 05:43:11 +08:00 by waspoza · 5 comments
waspoza commented 2026-04-24 05:43:11 +08:00 (Migrated from github.com)
Copy Link

This screnshot shows 0% forwards despite lots of forwards being there:

Image Image

This is my setup. Lan domain is handled by dnsmasq:

[server]
bind_addr = "192.168.0.222:53"
api_port = 5380

[upstream]
mode = "forward"                              # "forward" (default) — relay to upstream
address = "https://9.9.9.9/dns-query"   # DNS-over-HTTPS (encrypted)
fallback = ["8.8.8.8", "1.1.1.1"]            # tried only when all primaries fail

[[forwarding]]
suffix = "lan"
upstream = "127.0.0.1:5353"

[[forwarding]]
# This covers 192.168.0.x reverse lookups
suffix = "168.192.in-addr.arpa"
upstream = "127.0.0.1:5353"
This screnshot shows 0% forwards despite lots of forwards being there: <img width="1367" height="788" alt="Image" src="https://github.com/user-attachments/assets/1b216339-9ca6-4574-af5a-1cd4049e4d45" /> <img width="980" height="750" alt="Image" src="https://github.com/user-attachments/assets/09c42f96-e390-40d4-9c96-d70c40e5a9b5" /> This is my setup. Lan domain is handled by dnsmasq: ``` [server] bind_addr = "192.168.0.222:53" api_port = 5380 [upstream] mode = "forward" # "forward" (default) — relay to upstream address = "https://9.9.9.9/dns-query" # DNS-over-HTTPS (encrypted) fallback = ["8.8.8.8", "1.1.1.1"] # tried only when all primaries fail [[forwarding]] suffix = "lan" upstream = "127.0.0.1:5353" [[forwarding]] # This covers 192.168.0.x reverse lookups suffix = "168.192.in-addr.arpa" upstream = "127.0.0.1:5353" ```
razvandimescu commented 2026-04-24 17:15:47 +08:00 (Migrated from github.com)
Copy Link

Thanks for the detailed report - the screenshots help a lot.

A bit of naming context first, because I think part of what you're seeing is expected: since v0.14.1 numa splits queries that hit a [[forwarding]] suffix rule (tagged FORWARD) from queries that fall through to the default [upstream] pool (tagged UPSTREAM). In your config, 9.9.9.9 DoH is the default upstream, and the .lan / 168.192.in-addr.arpa rules point at dnsmasq. So:

  • A query for printer.lan -> FORWARD (matched the rule)
  • A query for google.com -> UPSTREAM (default pool)

Your query log screenshot only shows the second kind — all visible entries are google.com, gstatic.com, brave.com, etc., no .lan names at all. That's consistent with devices on your LAN resolving .lan via dnsmasq directly (or via mDNS), so those queries never reach numa. If that's the case, "0% forwards" is accurate, not a counter bug.

That said, one thing in your dashboard does look off: the Upstream row is missing from the Resolution Paths chart entirely (the dashboard hides rows where the counter is exactly 0). But the query log clearly shows many UPSTREAM entries with NOERROR and ~20 ms latency, so the upstream counter shouldn't be 0.

I spun up v0.14.2 in docker with your exact forwarding shape (numa + dnsmasq on a private subnet, two [[forwarding]] rules for lan and 168.192.in-addr.arpa) and sent a mix of .lan + external queries. Both counters incremented correctly and both bars rendered:

{
  "total": 75,
  "forwarded": 5,
  "upstream": 12,
  "cached": 58,
  ...
}

-> Forward 6.7%, Upstream 16.0%, Cached 77.3% — all visible. So the counter and dashboard filter aren't broken in the general case.

To pinpoint what's different on your side, could you share:

  1. curl -s http://127.0.0.1:5380/stats | jq .queries — raw counter values, especially whether upstream is literally 0.
  2. numa --version (or just the top of the numa logs on startup).
  3. One query log line (if any) for something like router.lan. Easiest repro from the numa host: dig @127.0.0.1 router.lan and then check Recent Queries for a FORWARD entry.

That will tell us whether this is a counter bug, a version skew, or just devices bypassing numa for LAN names.

Thanks for the detailed report - the screenshots help a lot. A bit of naming context first, because I think part of what you're seeing is expected: since v0.14.1 numa splits queries that hit a `[[forwarding]]` suffix rule (tagged **FORWARD**) from queries that fall through to the default `[upstream]` pool (tagged **UPSTREAM**). In your config, `9.9.9.9` DoH is the default upstream, and the `.lan` / `168.192.in-addr.arpa` rules point at dnsmasq. So: - A query for `printer.lan` -> **FORWARD** (matched the rule) - A query for `google.com` -> **UPSTREAM** (default pool) Your query log screenshot only shows the second kind — all visible entries are `google.com`, `gstatic.com`, `brave.com`, etc., no `.lan` names at all. That's consistent with devices on your LAN resolving `.lan` via dnsmasq directly (or via mDNS), so those queries never reach numa. If that's the case, "0% forwards" is accurate, not a counter bug. That said, one thing in your dashboard *does* look off: the **Upstream** row is missing from the Resolution Paths chart entirely (the dashboard hides rows where the counter is exactly 0). But the query log clearly shows many UPSTREAM entries with NOERROR and ~20 ms latency, so the upstream counter shouldn't be 0. I spun up v0.14.2 in docker with your exact forwarding shape (numa + dnsmasq on a private subnet, two `[[forwarding]]` rules for `lan` and `168.192.in-addr.arpa`) and sent a mix of `.lan` + external queries. Both counters incremented correctly and both bars rendered: ``` { "total": 75, "forwarded": 5, "upstream": 12, "cached": 58, ... } ``` -> Forward 6.7%, Upstream 16.0%, Cached 77.3% — all visible. So the counter and dashboard filter aren't broken in the general case. To pinpoint what's different on your side, could you share: 1. `curl -s http://127.0.0.1:5380/stats | jq .queries` — raw counter values, especially whether `upstream` is literally `0`. 2. `numa --version` (or just the top of the numa logs on startup). 3. One query log line (if any) for something like `router.lan`. Easiest repro from the numa host: `dig @127.0.0.1 router.lan` and then check Recent Queries for a FORWARD entry. That will tell us whether this is a counter bug, a version skew, or just devices bypassing numa for LAN names.
👀 1
waspoza commented 2026-04-24 20:36:28 +08:00 (Migrated from github.com)
Copy Link
piotr@nexus ~> curl -s http://127.0.0.1:5380/stats | jq .queries
{
  "total": 50044,
  "forwarded": 16,
  "upstream": 2161,
  "recursive": 0,
  "coalesced": 981,
  "cached": 42533,
  "local": 34,
  "overridden": 0,
  "blocked": 648,
  "errors": 3671
}
$ numa --version
numa 0.14.2

Yes, .lan queries show up as forwards:

Image

So looks like it's working as intended and UPSTREAM path doesn't have its own bar at all? Strange, bc i remember when i first installed numa queries that went to https://dns.quad9.net/dns-query were in the FORWARD category. I remember seeing that red bar being there. Did something change in the meantime or did i meesed up something in the config?

``` piotr@nexus ~> curl -s http://127.0.0.1:5380/stats | jq .queries { "total": 50044, "forwarded": 16, "upstream": 2161, "recursive": 0, "coalesced": 981, "cached": 42533, "local": 34, "overridden": 0, "blocked": 648, "errors": 3671 } $ numa --version numa 0.14.2 ``` Yes, .lan queries show up as forwards: <img width="1001" height="181" alt="Image" src="https://github.com/user-attachments/assets/ce1655e7-99ab-4e57-9e58-27f39fca87de" /> So looks like it's working as intended and UPSTREAM path doesn't have its own bar at all? Strange, bc i remember when i first installed numa queries that went to https://dns.quad9.net/dns-query were in the FORWARD category. I remember seeing that red bar being there. Did something change in the meantime or did i meesed up something in the config?
razvandimescu commented 2026-04-24 20:53:53 +08:00 (Migrated from github.com)
Copy Link

Good catch and the Upstream row missing is a real issue - but on your side it's a stale cache of the dashboard HTML, not a counter bug. Your /stats output is correct (upstream: 2161, forwarded: 16), and the binary is genuinely 0.14.2. The dashboard HTML, though, is served from / with no Cache-Control header, so when you upgraded numa your browser kept serving the pre-0.14.0 version - which is why (a) the Upstream row isn't there and (b) Recursive/Override still render at 0.0% despite the zero-filter that landed in 0.14.0.

Confirm by hard-refreshing the dashboard or open in a private window. You should get a new row for Upstream at ~4.3% and Recursive/Override should disappear entirely.

On the naming question: yes, this changed. Pre-0.14.0 both suffix-rule matches and default-pool queries were tagged FORWARD, so everything going to 9.9.9.9 showed up on the red bar. In 0.14.0 I split them — FORWARD now means "matched a forwarding rule" (i.e. dnsmasq for you) and UPSTREAM means "default pool" (Quad9 DoH). Same resolution, clearer accounting.

I'll ship a fix so the dashboard actually refreshes across upgrades without needing a hard reload.

Good catch and the Upstream row missing is a real issue - but on your side it's a stale cache of the dashboard HTML, not a counter bug. Your `/stats` output is correct (`upstream: 2161, forwarded: 16`), and the binary is genuinely 0.14.2. The dashboard HTML, though, is served from / with no Cache-Control header, so when you upgraded numa your browser kept serving the pre-0.14.0 version - which is why (a) the Upstream row isn't there and (b) Recursive/Override still render at 0.0% despite the zero-filter that landed in 0.14.0. Confirm by hard-refreshing the dashboard or open in a private window. You should get a new row for Upstream at ~4.3% and Recursive/Override should disappear entirely. On the naming question: yes, this changed. Pre-0.14.0 both suffix-rule matches and default-pool queries were tagged FORWARD, so everything going to `9.9.9.9` showed up on the red bar. In 0.14.0 I split them — FORWARD now means "matched a [[forwarding]] rule" (i.e. dnsmasq for you) and UPSTREAM means "default pool" (Quad9 DoH). Same resolution, clearer accounting. I'll ship a fix so the dashboard actually refreshes across upgrades without needing a hard reload.
razvandimescu commented 2026-04-24 20:55:08 +08:00 (Migrated from github.com)
Copy Link
Image
<img width="1550" height="1184" alt="Image" src="https://github.com/user-attachments/assets/182cce64-3737-4a2d-8f77-cbb962f36040" />
waspoza commented 2026-04-24 21:03:22 +08:00 (Migrated from github.com)
Copy Link

Oh damn, i din't thought about refreshing!

Image

Red bar is back! :) I'm sorry for wasting your time. Should thought about it earlier.

Oh damn, i din't thought about refreshing! <img width="1351" height="773" alt="Image" src="https://github.com/user-attachments/assets/6177b12c-9030-45e3-8cfa-caa9d17d7b51" /> Red bar is back! :) I'm sorry for wasting your time. Should thought about it earlier.
🎉 1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something isn't working
 dependencies
Pull requests that update a dependency file
 docker
Pull requests that update docker code
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 github_actions
Pull requests that update GitHub Actions code
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 rust
Pull requests that update rust code
 wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dearsky
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dearsky/numa#144
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?