Please explain: Difference in blocking IPv4 and IPv6?

I just retrieved an update for the web interface, installed and cleared the cache.


mouseover on the (blocked domain), tooltip says 'Click to show only queries with domain....'

When I click …

Also notice the blocked and allowed domain name are the same (this time both A entries)...

The best way to help us debug and add features would be to use a stock system, installed via our installer command, and starting fresh. If that shows issues then it's something for us to investigate. If you can not duplicate the situations with a known base that everyone can access then it's likely not an issue we can resolve.

Maybe because there is no match with the text you clicked. There is no domain that contains ' a.b.c (blocked x.y.z)'.
The domains are 'a.b.c' and 'x.y.z'.

Good assumption. I fixed this now.

So you have some information this time? If you see such strange queries on a regular basis, you can leave the debug flag enabled all the time. It will increase the amount of data written to the SD card, however, it has no other consequences than logging so there is no slowdown involved here.
I even have this flag set to true on all my Pi-holes from the very beginning of this flag and never disabled it again. Haven't had any issues nor any dead SD card or whatsoever.

unfortunately NO. I've reconfigured to no longer use tmpfs for logging and have enabled the debug flag. Will leave it on now.

This happens all the time, for www.msn.com, all I need to do is close Edge and reopen it -> bingo. Unfortunately, it's not the only domain that shows these queries. Yesterday (screenshot), was the only time I noticed both entries being A.

Don't know if this is possible, NOT an sql query specialist. Would it be possible to write a query that reports two consecutive queries to the same domain with different result, so I don't have to search the query log over and over again?

Questions I have been asking myself (probably stupid - NOT a experienced programmer)?

  • Could this be an original dnsmaq bug (v2.80)?
  • Could this be a recursive routine problem (use of global / local variable OR simply writing out the result twice)?

There is a filter option in the Query Log. If you use that to filter one domain you can see the (different) results of those queries.

I think that would not be simple to do in SQL. The results of a query have to parsed to compare results.
Query Log looks like an almost one to one representation of the database table so it takes less time to use Query Log.

How I find them:

sql script:

.mode csv
.output /home/pi/cnames.csv
select * from queries where status=9;
.output stdout
.quit

run:

sqlite3 /etc/pihole/pihole-FTL.db < /home/pi/cnames.sql

now open the pihole web interface, select Long Term Data / Query Log, select Date Range today and enter the domain from the csv file, you want to check, in the search box.

The problems, if any will be visible immediately, since they should be either all red (blocked) OR all green (allowed)

If you want to check another domain, all you need to do is enter a new domain name in the search box, the page refreshes immediately, without any other actions.

I've deleted /etc/pihole/pihole-FTL.db and the logs, after stopping pihole_FTL. This will ensure I'll only see records, that have been logged while the debug query logging was active. Now, wait and hope for a problem to appear soon (www.msn.com is a sure hit for me - using Edge, but that log was already submitted)...

caught one, using the above method, make sure you read the entire post, something else I noticed, explained before the second screenshot..


relevant FTL debug data (13:53:56):

[2020-01-31 13:53:56.719 28875] **** new UDP query[A] "ctldl.windowsupdate.com" from 192.168.2.228 (ID 1737, FTL 936, src/dnsmasq/forward.c:1571)
[2020-01-31 13:53:56.719 28875] ctldl.windowsupdate.com is known as not to be blocked
[2020-01-31 13:53:56.720 28875] **** got cache answer for ctldl.windowsupdate.com /  / <unknown> (ID 1737, src/dnsmasq/rfc1035.c:1714)
[2020-01-31 13:53:56.720 28875] **** forwarded ctldl.windowsupdate.com to fdaa:bbcc:ddee:2::5552 (ID 1737, src/dnsmasq/forward.c:566)
[2020-01-31 13:53:56.721 28875] **** forwarded ctldl.windowsupdate.com to 127.10.10.2 (ID 1737, src/dnsmasq/forward.c:558)
[2020-01-31 13:53:56.721 28875] ctldl.windowsupdate.com is known as not to be blocked
[2020-01-31 13:53:56.721 28875] CNAME ctldl.windowsupdate.com
[2020-01-31 13:53:56.721 28875] **** got reply ctldl.windowsupdate.com is (CNAME) (ID 1737, src/dnsmasq/cache.c:487)
[2020-01-31 13:53:56.722 28875] audownload.windowsupdate.nsatc.net is known as not to be blocked
[2020-01-31 13:53:56.722 28875] CNAME ctldl.windowsupdate.com ---> audownload.windowsupdate.nsatc.net
[2020-01-31 13:53:56.722 28875] **** got reply audownload.windowsupdate.nsatc.net is (CNAME) (ID 1737, src/dnsmasq/cache.c:487)
[2020-01-31 13:53:56.722 28875] wu.azureedge.net is not known
[2020-01-31 13:53:56.723 28875] CNAME audownload.windowsupdate.nsatc.net ---> wu.azureedge.net
[2020-01-31 13:53:56.723 28875] **** got reply wu.azureedge.net is (CNAME) (ID 1737, src/dnsmasq/cache.c:487)
[2020-01-31 13:53:56.723 28875] wu.ec.azureedge.net is not known
[2020-01-31 13:53:56.724 28875] CNAME wu.azureedge.net ---> wu.ec.azureedge.net
[2020-01-31 13:53:56.724 28875] **** got reply wu.ec.azureedge.net is (CNAME) (ID 1737, src/dnsmasq/cache.c:487)
[2020-01-31 13:53:56.724 28875] wu.wpc.apr-52dd2.edgecastdns.net is not known
[2020-01-31 13:53:56.725 28875] CNAME wu.ec.azureedge.net ---> wu.wpc.apr-52dd2.edgecastdns.net
[2020-01-31 13:53:56.725 28875] **** got reply wu.wpc.apr-52dd2.edgecastdns.net is (CNAME) (ID 1737, src/dnsmasq/cache.c:487)
[2020-01-31 13:53:56.725 28875] hlb.apr-52dd2-0.edgecastdns.net is not known
[2020-01-31 13:53:56.726 28875] CNAME wu.wpc.apr-52dd2.edgecastdns.net ---> hlb.apr-52dd2-0.edgecastdns.net
[2020-01-31 13:53:56.726 28875] **** got reply hlb.apr-52dd2-0.edgecastdns.net is (CNAME) (ID 1737, src/dnsmasq/cache.c:487)
[2020-01-31 13:53:56.726 28875] cs11.wpc.v0cdn.net is not known
[2020-01-31 13:53:56.726 28875] Blocking cs11.wpc.v0cdn.net as domain is gravity blocked
[2020-01-31 13:53:56.726 28875] CNAME hlb.apr-52dd2-0.edgecastdns.net ---> cs11.wpc.v0cdn.net
[2020-01-31 13:53:56.727 28875] **** new UDP query[AAAA] "ctldl.windowsupdate.com" from 192.168.2.228 (ID 1738, FTL 937, src/dnsmasq/forward.c:1571)
[2020-01-31 13:53:56.727 28875] ctldl.windowsupdate.com is known as not to be blocked
[2020-01-31 13:53:56.728 28875] **** forwarded ctldl.windowsupdate.com to fdaa:bbcc:ddee:2::5552 (ID 1738, src/dnsmasq/forward.c:566)
[2020-01-31 13:53:56.730 28875] ctldl.windowsupdate.com is known as not to be blocked
[2020-01-31 13:53:56.730 28875] CNAME ctldl.windowsupdate.com
[2020-01-31 13:53:56.730 28875] **** got reply ctldl.windowsupdate.com is (CNAME) (ID 1738, src/dnsmasq/cache.c:487)
[2020-01-31 13:53:56.730 28875] audownload.windowsupdate.nsatc.net is known as not to be blocked
[2020-01-31 13:53:56.731 28875] CNAME ctldl.windowsupdate.com ---> audownload.windowsupdate.nsatc.net
[2020-01-31 13:53:56.731 28875] **** got reply audownload.windowsupdate.nsatc.net is (CNAME) (ID 1738, src/dnsmasq/cache.c:487)
[2020-01-31 13:53:56.731 28875] au.download.windowsupdate.com.edgesuite.net is known as not to be blocked
[2020-01-31 13:53:56.731 28875] CNAME audownload.windowsupdate.nsatc.net ---> au.download.windowsupdate.com.edgesuite.net
[2020-01-31 13:53:56.732 28875] **** got reply au.download.windowsupdate.com.edgesuite.net is (CNAME) (ID 1738, src/dnsmasq/cache.c:487)
[2020-01-31 13:53:56.732 28875] a767.dscg3.akamai.net is known as not to be blocked
[2020-01-31 13:53:56.732 28875] CNAME au.download.windowsupdate.com.edgesuite.net ---> a767.dscg3.akamai.net
[2020-01-31 13:53:56.732 28875] **** got reply a767.dscg3.akamai.net is 2a02:26f0:ed::5c7a:3512 (ID 1738, src/dnsmasq/cache.c:487)
[2020-01-31 13:53:56.732 28875] a767.dscg3.akamai.net is known as not to be blocked
[2020-01-31 13:53:56.733 28875] CNAME a767.dscg3.akamai.net
[2020-01-31 13:53:56.733 28875] **** got reply a767.dscg3.akamai.net is 2a02:26f0:ed::5c7a:352b (ID 1738, src/dnsmasq/cache.c:487)

My method reveals another point of interest:
The list reveals this is NOT always happening. Sometimes the query simply has a forwarded status.

I'm also including the debug log for the event at 12:24:53 (forwarded), this may clarify somethings.

[2020-01-31 12:24:53.963 28875] **** new UDP query[A] "ctldl.windowsupdate.com" from 192.168.2.228 (ID 27, FTL 26, src/dnsmasq/forward.c:1571)
[2020-01-31 12:24:53.963 28875] ctldl.windowsupdate.com is not known
[2020-01-31 12:24:53.964 28875] **** forwarded ctldl.windowsupdate.com to fdaa:bbcc:ddee:2::5552 (ID 27, src/dnsmasq/forward.c:566)
[2020-01-31 12:24:53.965 28875] ctldl.windowsupdate.com is known as not to be blocked
[2020-01-31 12:24:53.965 28875] CNAME ctldl.windowsupdate.com
[2020-01-31 12:24:53.965 28875] **** got reply ctldl.windowsupdate.com is (CNAME) (ID 27, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.965 28875] audownload.windowsupdate.nsatc.net is not known
[2020-01-31 12:24:53.966 28875] CNAME ctldl.windowsupdate.com ---> audownload.windowsupdate.nsatc.net
[2020-01-31 12:24:53.966 28875] **** got reply audownload.windowsupdate.nsatc.net is (CNAME) (ID 27, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.966 28875] au.download.windowsupdate.com.edgesuite.net is not known
[2020-01-31 12:24:53.966 28875] CNAME audownload.windowsupdate.nsatc.net ---> au.download.windowsupdate.com.edgesuite.net
[2020-01-31 12:24:53.967 28875] **** got reply au.download.windowsupdate.com.edgesuite.net is (CNAME) (ID 27, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.967 28875] a767.dscg3.akamai.net is not known
[2020-01-31 12:24:53.967 28875] CNAME au.download.windowsupdate.com.edgesuite.net ---> a767.dscg3.akamai.net
[2020-01-31 12:24:53.967 28875] **** got reply a767.dscg3.akamai.net is 2.17.107.33 (ID 27, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.967 28875] a767.dscg3.akamai.net is known as not to be blocked
[2020-01-31 12:24:53.967 28875] CNAME a767.dscg3.akamai.net
[2020-01-31 12:24:53.968 28875] **** got reply a767.dscg3.akamai.net is 2.17.107.18 (ID 27, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.968 28875] **** new UDP query[AAAA] "ctldl.windowsupdate.com" from 192.168.2.228 (ID 28, FTL 27, src/dnsmasq/forward.c:1571)
[2020-01-31 12:24:53.968 28875] ctldl.windowsupdate.com is known as not to be blocked
[2020-01-31 12:24:53.969 28875] **** forwarded ctldl.windowsupdate.com to fdaa:bbcc:ddee:2::5552 (ID 28, src/dnsmasq/forward.c:566)
[2020-01-31 12:24:53.975 28875] ctldl.windowsupdate.com is known as not to be blocked
[2020-01-31 12:24:53.975 28875] CNAME ctldl.windowsupdate.com
[2020-01-31 12:24:53.976 28875] **** got reply ctldl.windowsupdate.com is (CNAME) (ID 28, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.976 28875] audownload.windowsupdate.nsatc.net is known as not to be blocked
[2020-01-31 12:24:53.976 28875] CNAME ctldl.windowsupdate.com ---> audownload.windowsupdate.nsatc.net
[2020-01-31 12:24:53.976 28875] **** got reply audownload.windowsupdate.nsatc.net is (CNAME) (ID 28, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.976 28875] auto.au.download.windowsupdate.com.c.footprint.net is not known
[2020-01-31 12:24:53.977 28875] CNAME audownload.windowsupdate.nsatc.net ---> auto.au.download.windowsupdate.com.c.footprint.net
[2020-01-31 12:24:53.977 28875] **** got reply auto.au.download.windowsupdate.com.c.footprint.net is 2001:1900:2326:2f03::1fe (ID 28, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.977 28875] auto.au.download.windowsupdate.com.c.footprint.net is known as not to be blocked
[2020-01-31 12:24:53.977 28875] CNAME auto.au.download.windowsupdate.com.c.footprint.net
[2020-01-31 12:24:53.977 28875] **** got reply auto.au.download.windowsupdate.com.c.footprint.net is 2001:1900:2324:2f00::1fe (ID 28, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.977 28875] auto.au.download.windowsupdate.com.c.footprint.net is known as not to be blocked
[2020-01-31 12:24:53.977 28875] CNAME auto.au.download.windowsupdate.com.c.footprint.net
[2020-01-31 12:24:53.978 28875] **** got reply auto.au.download.windowsupdate.com.c.footprint.net is 2001:1900:2324:1c00::1fe (ID 28, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.978 28875] auto.au.download.windowsupdate.com.c.footprint.net is known as not to be blocked
[2020-01-31 12:24:53.978 28875] CNAME auto.au.download.windowsupdate.com.c.footprint.net
[2020-01-31 12:24:53.978 28875] **** got reply auto.au.download.windowsupdate.com.c.footprint.net is 2001:1900:2324:5011::1fe (ID 28, src/dnsmasq/cache.c:487)
[2020-01-31 12:24:53.978 28875] auto.au.download.windowsupdate.com.c.footprint.net is known as not to be blocked
[2020-01-31 12:24:53.978 28875] CNAME auto.au.download.windowsupdate.com.c.footprint.net
[2020-01-31 12:24:53.978 28875] **** got reply auto.au.download.windowsupdate.com.c.footprint.net is 2001:1900:2326:2f12::1fe (ID 28, src/dnsmasq/cache.c:487)

Just to clarify things since there are cache hits on this, are you still using a redis cache for name resolution?

running pihole branch new/CNAME_inspection_details + unbound v1.9.6 (compiled from source) + redis v5.0.3

pihole-FTL cache-size=10000

This should NOT affect the blocking logic. A domain is either blocked OR allowed, doesn't really matter where the reply comes from.

I'm NOT the only person having reported this problem. Arno originally reported the problem, I just noticed the same problem and reported it, thus being an independent source.

Arno, are you still seeing this issue?

I'm using two forwarders in my pihole configuration:

server=127.10.10.2#5552
server=fdaa:bbcc:ddee:2::5552#5552

All the queries for this domain have been forwarded to the same unbound resolver (fdaa:bbcc:ddee:2::5552#5552 - see screenshot below), in fact, of all the queries performed since the restart this morning, 56.2% have been answered by the IPv6 resolver, 6.6% cached and 36.9% blocklist. Currently, pihole doesn't like the IPv4 (127.10.10.2#5552) resolver very much (slower).

Not related to this issue but you don't need to use IPv6 over a local connection to the same host. Just use the 127 address. You're over complicating a lot of things.

Didn't watch it since the patch. Never saw different results of same query.
Only saw difference between A and AAAA.

And clicking on blocked cname gives no matches.

1 Like

Thanks, so your questions have been answered?

DL6ER did release an update for the branch new/CNAME_inspection_details this morning, run pihole -up and don't forget to clear the browser cache. Since the update, clicking on the domain in the query log shows the relevant queries.

in the query log:


click on the domain:

I would really appreciate if you also list your configuration, and use my method to identify a recent occurrence of the problem we have been seeing. If NOT, I'm afraid the bug report will be closed without further investigation (independent source).

Was on v5.0 Beta, now on

pihole checkout ftl new/CNAME_inspection_details
pihole checkout web new/CNAME_inspection_details

  Pi-hole version is v4.3.2-391-ge0b3405 (Latest: v4.3.2)
  AdminLTE version is v4.3.2-363-g90a09d1c (Latest: v4.3.2)
  FTL version is vDev-122a701 (Latest: v4.3.1)

Resolver configuration? unbound or other?

Please run the sql script and evaluate the results in the csv, really easy, doesn't take up to much of your time.

Unbound 1.9.4-2+b1