New Pi-Hole installation blocks bt does not log

[deemon10]

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

Expected Behaviour:

_[ I expect that when blocks occur that activity would be logged and thus visible in the query log or dashboard on the admin web page.

Pi-hole version is V5.2.4
AdminLTE version is V5.4
FTL version is V5.7
SQLite version is 3.27.2

Pi-hole Host
Hardware = Raspberry Pi Zero WH
OS= Name="Raspbian GNU/Linux", Version_ID="10",VERSION_CODENAME=buster
Networking is Wifi using DHCP from an AT&T modem/router which has the Pi-hole host IP address "Allocated"/ Reserved.

OS is up to date as of 2/20/21

Client used for testing:
Hardware = Raspberry Pi 4
OS = Name "Raspbian GNU/Linux 10 (buster), Version_ID=10,
OS is up to date as of 2/20/21
Networking is wired ethernet and DHPC where the DNS to be used from the DHCP query is over ridden from the following entry into /etc/dhcp/dhclient.conf "supersede domain-name-servers 192.168.1.184;" where the local .184 address is that of the Pi-hole server.

Actions thus far beyond updating everything:
1) Noted /etc/pihole/setupVars.conf shows QUERY_LOGGING=true
2) Used web admin interface to disable/enable query logging
3) Used web admin interface to flush logs
4) Re-created FTL database vi:
a) service pihole-FTL stop
b) mv pihole-FTL.db pihole-FTL.db.old
c) service pihole-FTL start
5) issued and completed "pihole -r" command
6) Confirmed both Pihole server and Pihole client obtained the same results from "nslookup flurry.com"

 7-9) A lot of praying, cussing, chanting...... the usual stuff when faced with my many limitations :-)

]

Actual Behaviour:

_[
The client used for testing seems to have ads blocked but no entries show up in the web interface other than what appear to be unrelated entries from "localhost". There are no entries other than those from localhost.

It may or may not be worth noting, because I am definitely not a database guy...... But curiosity got the better of me so I went into the sqlite3 database, opened the pihole-FTL.db database, and listed, to the screen, the contents of "name" in the "network_addresses" table and while the list was as long as the output I recieved from "ip" in the same table, BUT all the lines in the output were blank except for one which had the value of "localhost".

Hopefully I have given you enough information to be able to let me know what in the world I've done wrong or missed. I would definitely be grateful for any assistance, because Pi-Hole looks extremely COOL.....

Last Note, Wow didn't expect getting the token would do all that. I thought it would simply give me some number or such.... Man you guys have really got your stuff together....

Thank You
Dee
]_

Debug Token:[ https://tricorder.pi-hole.net/yqa21j441m ]

[Bucking_Horn]

Your debug log shows Pi-hole to be operational, but none of your clients seem to use it for DNS (apart from Pi-hole itself):

*** [ DIAGNOSING ]: contents of /var/log
-rw-r--r-- 1 pihole pihole 15141 Feb 22 11:49 /var/log/pihole-FTL.log

   -----tail of pihole-FTL.log------
   [2021-02-22 11:49:59.175 492M] Imported 7 queries from the long-term database
   [2021-02-22 11:49:59.176 492M]  -> Total DNS queries: 7
   [2021-02-22 11:49:59.176 492M]  -> Cached DNS queries: 0
   [2021-02-22 11:49:59.176 492M]  -> Forwarded DNS queries: 7
   [2021-02-22 11:49:59.176 492M]  -> Blocked DNS queries: 0
   [2021-02-22 11:49:59.176 492M]  -> Unknown DNS queries: 0
   [2021-02-22 11:49:59.177 492M]  -> Unique domains: 5
   [2021-02-22 11:49:59.177 492M]  -> Unique clients: 1
   [2021-02-22 11:49:59.177 492M]  -> Known forward destinations: 1

Since this is a first time install, I'd suggest to have a read through our docs, specifically on how to make your network take advantage of Pi-hole.
You may want to check prerequisites as well.

[deemon10]

Thank you very much for the quick response and reply.

Yes, my intention was that I would turn the dhcp functions off in the AT&T router (and had confirmed it was possible.. ya never know with AT&T) However I figured I had better take it a step at a time before risking a riot from the household members so I thought to override the DNS server provided by the AT&T router on my test client only. Which seems to have taken me down a rabbit hole......

You are indeed correct in that the AT&T device is being pointed to. My apologies for having missed that. And.....( In case it might assist someone else here is how I got here or perhaps it's where I am....)........
I didn't think to look as the test client was getting the ads blocked and while I did do a comparison between the results of nslookup flurry.com on both the pi-hole server and the test client.. I failed to note those results were BOTH from the AT&T router. So I took a look at /etc/resolv.conf and the AT&T DNS server was there but not the Pi-hole...........

The method I used in my attempt to override the DNS info provided by AT&T DHCP server was to add the following line at the bottom of the /etc/dhcp/dhclient.conf file:

supersede domain-name-servers 192.168.1.184

That entry is "supposed" to tell the system to use the .184 address instead of the one provided by DHCP. Since it didn't I started looking through various scripts and such and found a /etc/dhcp/debug script which by changing a variable at the beginning from a "no" to "yes" it would output the values of all the variables used by the other dhpc scripts. That output, placed in a file in /tmp, did show the superceded .184 address has the one to use. I went a little further down the rabbit hole and found the script /sbin/dhclient-script which apparently (maybe more like supposed to) is executed at boot and is the one which does the automagic build of /etc/resolv.conf. In that script I could see that, yes it does wipe out and then build the /etc/resolv.conf file using the variable shown in the debug output from DHCP. So... regretting having gone down this rat hole I ran the "dhclient -v eth0" command again to generate a new log file.........and after I time I looked at the /etc/resolv.conf file again and it seems that running the dhclient command cause the .184 nameserver entry to be appended to resolv.conf......

And while I have likely misinterpreted something or messed up in another way. but at the moment I wouldn't bet my money that something with DHCP isn't goofed up in the Raspberrypi_OS.....

In any case I think I've gone down the rabbit hole about as far as legally permitted in the federal "Limitations of Fun" laws so I'll save that for another day and get back to the Pi-hole. Since it doesn't rebuild the resolv.conf until reboot I should be able to simply change it manually for my testing. Once I've got a handle on the filtering I can get DHCP fired up on the Pi-hole server and turn the AT&T DHCP off so everybody in the house can enjoy the benefits.

One thing I can't quite explain is how or why did the Ads get blocked on the test client when it wasn't using it for DNS lookups. I mean if I understand the secret sauce in this it's that anyting in the blacklist just don't get the actual address sent back to the requesting client........ so if it was bypassing the pi-hole...how.... Example: On the test client, using the browser I went to http://cnczone.com which has Ads in it prominently at the top of the page. Doing this on my main system I get the Ads, doing so on the test client I don't get the Ads......... which again is one of my excuses for not having caught the issue with resolv.conf.

Anyway, let me get this tested as I'm sure once I get that fixed it will work fine. I apologize for the lengthy play-by-play but maybe it will help someone else and you'll be able to make up for the time lost by reading all this.

Thank You ...... and I'll send confirmation on the impending success.....
Dee

[deemon10]

Back Again, so soon........

Yes, I manually chenged the resolv.conf file and used the broswer to go to the test sites with Ads I had been using and the query log picked up all the activity. Sweet. And yes the Ads were still being blocked....... just as they were before correcting resolv.conf....... Ya know that's gonna give me a headach if I think about it too much. I'll take the WIN, I got to learn a bit more of how the new liinux world works and didn't have to jury rig something to make it work (which drives me nuts not to find the "correct" solution) since I'm going to turn off the AT&T DHCP as soon as I get everything vetted and fire up DHPC on Pi-hole.

Thank you very much again

[Bucking_Horn]

resolv.conf just defines where outbound DNS requests of the Zero itself go. The same is true for domain_name_servers in dhcpcd.conf.

Pi-hole itself does not consider your Zero's DNS servers at all.
It will only ever use its configured upstream DNS servers to forward DNS requests to.

It's a good idea to have your Zero's DNS pointing at some additional public DNS server, as this would allow your machine to still resolve names if Pi-hole would be inoperable. You would still be able to update packages or run pihole -r scripts to repair or reconfigure your installation.

Your clients are also unaffected by your Zero's DNS configuration, as their inbound DNS requests will reach Pi-hole, where they get filtered first and then be forwarded to one of Pi-hole's upstreams eventually.

[deemon10]

Thank you.

I knew that /etc/resolv.conf didn't have anything to do with DNS services itself etc..... What I hadn't realized is that having multiple nameserver entries would use the extra nameservers as fallback. That's good to know.

An FYI, last night after what appeared to be a successful configuration of Pi-hole with both blocking Ads and logging I went the extra step and turned DHCP OFF on the ATT&T device and turned it on the Pi-hole server. Initially I thought it was all working on the 1st shot..... that was before the wheels came off. Pretty much every Android device was dead in the water, my main system, a Manjaro, system was able to go to some websites but not others. For example I could go to Google but not to eBay, not to the Discourse Forum. Since logging was now working in Pi-hole I could see it wasn't because those were being blocked. Since the switch to hosting DHCP on the Pi was the only new element vs the testing configuration I figured that was the likely source of the problem so I went to find the DHCP logs..... After about an hour I came to the conclusion DHCP must be logging to /var/log/pihole.log..... well there is just too much to go into it all here, lets just say I've some homework to do.

Being a bit embarrassed about having difficulties setting up something which seems like it shouldn't be tough at all. I mean the documentation is good, clear, and straight forward. That embarrassment compels me to make excuses

I'm a bit of a newbie, and at the same time I'm probably in much worse shape than the typical newbie. Folks just starting out don't know any better, they have a clean slate to write on. I, on the other hand, started on Linux back before the 1st "Distro" ever came out. At that time you had to download the kernel from the university of Helsinki, the GNU utils from GNU, for networking you had to download the "Net 2 Tapes" from Berkley, Xwindows from MIT, the Xfree code from the university of Australia.... etc... (FYI, since there weren't any "websites or browsers" we used utilities such as gopher and archie etc...) At any rate once you had all that you downloaded a floppy image from a guy named "Hlu" that you could boot and start a Linux in a ramdisk with enough utilities to format a drive and compile and link the code..........

But about the time Linux switched to Elf binaries I had to put Linux down and concentrate on Vax/VMS and RSX-11. Since then I've been in and out of the Linux world but the last 20 years or so it's been mostly Linux. I haven't had a Windows machine since maybe .. hell what maybe 2000 or so...... donno. So I've been in the Linux world a long time but I was a bit handicapped as I worked for a large aerospace and defense company which is doubly bad as big corporations tend to stay behind the curve to a large degree. Even worse, Red Hat is dominant in those settings, so being tied to Red Hat who stay behind the curve to great extent and being on older versions of Red Hat even due to the speed at which bureaucracy allows for keeping up with the times..... So while I'm not a newbie I'm probably worse than a newbie as I "know" how it's done

However time changed and I just retired and can now play with all the new toys!! For the past good number of years I was the lead architect for HPC computing at that Aerospace firm mostly designing HPC systems and overseeing their construction so I didn't get a lot of hands on even with the ancient Red Hat systems. So I've got to do a lot of catchup and homework......... It's a very cool new world and I'm having a blast. and at the same time I'm getting frustrated at not being able to do even the simplest thing with the need to go down a rabbit hole...... Hell it took me 45 minutes this morning to figure out that netstat is passe' in favor of "ss". ss was one of the pleasant surprises, simple, intuitive with a lot of functionality....... on the other hand, systemd..... I know/knew Linux was going to have to find another way as we're long past a handful of daemons with those having much more complicated interactions. but come on, systemd what in hell were they thinking...... And lastly who in hell thought it was a good idea to put syslog and such in some kind of binary form.. Isn't there a law against allowing Microsoft employees work on Linux....... just saying....... so there's some very good stuff in the "modern Linux's and there's some very bad stuff...... but hey I'm old.

At any rate now you have the driver behind my difficulties when combined with a natural tendency to be IQ deficient in the 1st place....you should understand if you hear from me again before I get this figured out. I'm pretty sure my current issue is probably DNS and DHCP....... but I'm gonna have to pretty deep down that rat hole cause it doesn't seem to be as straightforward as it once was. It seems like there may be way too many outside processes outside mechanisms manipulating what used to be pretty simple configurations. I'm sure there are reasons for it and maybe I'll see why after figuring out more of it....... (I half suspect systemd monkeys with stuff, why it would need to play a major role in it beyond managing startup, shutdown and inner function coordination is beyond me but it seems to want to be everything to everything which generally means it isn't good at anything .......

Anyhow my apologies for being long winded on a subject I'm sure you shouldn't have a lot of interest in. it is born of frustration and embarrassment. I'm sure I'll need help before it's over but I think before I can ask for it I need to figure out what exactly it is I need help with. I can't make use of the exercise if I just cry "Help it doesn't work and I want you to do the work for me" So let me see what I can figure out what's what here and if I need help I'll open another thread which would be entitled more appropriately to the current situation as it now is logging just fine thanks to your help.

Thanks
Dee