An entry in the blacklist is not being blocked

[metaben]

Versions

• Pi-hole: v5.18.1
• AdminLTE: v5.21
• FTL: v5.25.1

Platform

• OS and version: Debian GNU/Linux 12 (bookworm)
• Platform: Raspberry Pi 5 Model B Rev 1.0

Expected behavior

Saw a dns request for the domain "ñ_gç" in the query log and after blocking it, expected all future requests to be blocked.

Actual behavior / bug

The domain is on the blacklist but requests are not being blocked.

Steps to reproduce

Steps to reproduce the behavior:

1. saw a dns request for the domain "ñ_gç" in the query log.
2. clicked blacklist, and added it to the blacklist.
3. continue to see dns requests for "ñ_gç" in the query log
4. checked blacklist, where it has an entry, is enabled, and is for the default group, and shows "Added from Query Log".
5. all requests for this domain still offer the "blacklist" button as though it is already exists in the blacklist.

Debug Token

• URL: https://tricorder.pi-hole.net/td5oYxBB/

Screenshots

Additional context

Might be utf-8 related? It doesn't look like a legitimate dns request to me.

[rdwebdesign]

Can you please try to generate a new debug log?

Apparently there was an issue during the log creation and the last lines are not present (the log is truncated).

[DL6ER]

This domain should have been converted to Punycode encoding (xn--_g-5ia1b) automatically, like so:

[!NOTE] This screenshot is from a Pi-hole v6.0 machine, though, so it may de different from what you are seeing (I cannot test v5.x right now).

Could you quickly verify in your /var/log/pihole/pihole.log if the domain is really queried like this in UTF-8 form? This would indeed violate the DNS standard and will always fail - as the NXDOMAIN reply confirms in your case.

[metaben]

Can you please try to generate a new debug log?

Apparently there was an issue during the log creation and the last lines are not present (the log is truncated).

ok sure. I used the admin UI to generate a new token: https://tricorder.pi-hole.net/dnzRup8A/ Size on disk is 31807.

[metaben]

Could you quickly verify in your /var/log/pihole/pihole.log if the domain is really queried like this in UTF-8 form?

Here's what I'm seeing in pihole.log

Apr  3 17:08:06 dnsmasq[5130]: query[A] <name unprintable> from 192.168.88.210
Apr  3 17:08:06 dnsmasq[5130]: config <name unprintable> is NXDOMAIN

[metaben]

For this bug, have also noticed that a domain can be on the blacklist and an allowed query at the same time.

Blacklist:

Audit log:

[DL6ER]

have also noticed that a domain can be on the blacklist and an allowed query at the same time

This is intentional and actually a feature. You may want to allow a domain for certain devices and block it for others. You can achieve this by assigning different groups to the two entries.

Here's what I'm seeing in pihole.log

Apr 3 17:08:06 dnsmasq[5130]: query[A] from 192.168.88.210 Apr 3 17:08:06 dnsmasq[5130]: config is NXDOMAIN

So the illegal requests are made by whatever application is responsible for them. Non-ASCII is illegal in DNS so they'll never resolve.

[metaben]

Right, but staying on topic: why are they on the blocklist but not being blocked?

[DL6ER]

This is a good question, I assume there is some encoding issue going on, let's try to find this out.

Please try first

sqlite3 /etc/pihole/gravity.db "SELECT * FROM domainlist;"

and quote the reply as copy & paste here.

[metaben]

sqlite3 /etc/pihole/gravity.db "SELECT * FROM domainlist;"

and quote the reply as copy & paste here.

$ sqlite3 /etc/pihole/gravity.db "SELECT * FROM domainlist;"
1|1|srv.giraffic.com|1|1711993019|1711993019|Added from Query Log
2|0|cdn.jsdelivr.net|1|1712084293|1712085528|Discovery+
3|0|discovery-us.conax.cloud|1|1712084655|1712084655|Discovery+
4|0|js-agent.newrelic.com|1|1712084841|1712085521|Discovery+
5|0|cdn.cookielaw.org|1|1712084966|1712085525|Discovery+
7|1|ñ_gç|1|1712085500|1712085500|Added from Query Log
9|1|¹æº|1|1712261108|1712266215|Added from Audit Log

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.