Ads should be blocked.
Web interface is working. IPv6 blocking is disabled. Pi hole is running on my computer and not on a Raspberry Pi. I've set up the DNS server to my computer local adress.
0bptfvrhr6 (older one)
ab4ihu6gud (newer one)
Define IPV6 blocking being disabled.
I'm asking because you DO seem to have IPV6 enabled.
IVP6 is preferred over IPV4 in a netwrok (OS level).
See if your queries resolve via IPV6 or IPV4.
Run a nslookup flurry.com even dig flurry.com
use dig flurry.com A for IPV4 query and AAAA for IPV6
See what those queries return.
For "nslookup flurry.com"
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: flurry.com
Address: 74.6.136.153
** server can't find flurry.com: NXDOMAIN
For "dig flurry.com A"
; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> flurry.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65156
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;flurry.com. IN A
;; ANSWER SECTION:
flurry.com. 300 IN A 74.6.136.153
;; Query time: 146 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: ven. nov. 02 18:04:07 CET 2018
;; MSG SIZE rcvd: 44
for "dig flurry.com AAAA"
; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> flurry.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34185
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;flurry.com. IN AAAA
;; Query time: 169 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: ven. nov. 02 18:04:15 CET 2018
;; MSG SIZE rcvd: 28
Both of these queries actually resolved flurry.com (and it shouldn't have - that is a known blocked domain).
If you however run the query via 192.168.1.2, they will be blocked which is odd, because they are on the same machine.
( dig flurry.com A @192.168.1.2)
What's the content of /etc/resolv.conf
nameserver 127.0.0.1
Change that to 192.168.1.2 and try a regular dig on that same domain.
It should resolve it to nothing (and see the hit in the admin initerface).
But it will be overwritten, won't it?
dig flurry.com A @192.168.1.2
; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> flurry.com A @192.168.1.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41134
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;flurry.com. IN A
;; ANSWER SECTION:
flurry.com. 2 IN A 0.0.0.0
;; Query time: 0 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: ven. nov. 02 18:32:59 CET 2018
;; MSG SIZE rcvd: 55
And yes, I saw the hit.
I checked on https://blockads.fivefilters.org/?pihole and I see that adblocking is working.
That because (i'm assuming) you are running resolv.conf with 192.168.1.2.
change it back to 127.0.0.1 and share the output of
dig @127.0.0.1 ch txt version.bind
dig @127.0.0.1 ch txt version.bind
; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> @127.0.0.1 ch txt version.bind
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 50642
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: EDNS query returned status NOTIMP - retry with '+noedns'
;; QUESTION SECTION:
;version.bind. CH TXT
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: ven. nov. 02 18:43:18 CET 2018
;; MSG SIZE rcvd: 30
I think this is related to dnssec and bind9 and not related to Pi-hole.
what about dig @127.0.0.1 +noedns ch txt version.bind
; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> @127.0.0.1 +noedns ch txt version.bind
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 836
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;version.bind. CH TXT
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: ven. nov. 02 18:48:54 CET 2018
;; MSG SIZE rcvd: 30
That is not a proper response. It should return the version of the resolver.
If you run dig @192.168.1.2 ch txt version.bind you will see the proper response.
What that means is that queries executed and pointed at 127.0.0.1 are bypassing Pi-hole.
You can do two things: remove bind (but with everything you are running there I think it will cause other issues) OR on your network interface, specify the sole DNS as 192.168.1.2 and that will route your queries via the IPV4 IP and not the loopback.
dig @192.168.1.2 ch txt version.bind
; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> @192.168.1.2 ch txt version.bind
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62230
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;version.bind. CH TXT
;; ANSWER SECTION:
version.bind. 2 CH TXT "dnsmasq-pi-hole-2.79"
;; Query time: 0 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: ven. nov. 02 18:55:36 CET 2018
;; MSG SIZE rcvd: 74
That's for the command and I think I will just specify the sole DNS (thinking on how to do that)
that's a proper response.
On your network card properties on the mac via settings 
Still adblocking not working. 
If you are connected to ethernet, you need to set it up there too as Ethernet is preferred over WiFi when both connected.
We know Pi-hole is working because if from your CLI you execute the query, via Pi-hole, it blocks. This issue is related to your local settings and how they are routed/processed.
I never been connected to Ethernet excepted that one time when I messed up with Pi hole config and I selected the wrong interface.
