I've opened this thread on Arch Linux forum.
Basically I have set up Pi-hole following the wiki and changed my local configuration to use it as DNS server but ads don't get filtered.
It should filter ads.
Not filtering ads.
Don't have one because running on Arch Linux on EC2.
From the Pi-hole logs in the other post @ archlinux, it looks like your running an open resolver ?
pi@noads:~ $ whois 80.82.77.139
country: SC
pi@noads:~ $ whois 52.73.169.169
Country: US
On a Linux or Mac client PC, whats outcome for below one ?
cat /etc/resolv.conf
On a Windows client PC, whats mentioned in the DNS section when run below one in a CMD prompt ?
ipconfig /all
Are they displaying the Pi-hole IP address as the only DNS server ?
Oops:
pi@noads:~ $ host pi.hole 52.214.17.59
Using domain server:
Name: 52.214.17.59
Address: 52.214.17.59#53
Aliases:
pi.hole has address 172.31.7.138
Better put a firewall on it or your going to participate in a DDOS attack!
My local Linux machine looks like it's pointing to that DNS server:
➜ ~ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 52.214.17.59
I get a different result from yours
➜ ~ host pi.hole 52.214.17.59
Using domain server:
Name: 52.214.17.59
Address: 52.214.17.59#53
Aliases:
Host pi.hole not found: 3(NXDOMAIN)
I admit I don't get what it could be used in DDOS attacks.
with Pi-hole installed, your /etc/resolv.conf should point to 127.0.0.1 (assuming Pi-hole is on the same machine as the above /etc/resolv.conf file).
Your current setting with 52.214.17.59 as your name server, is dodging the Pi-hole and sends all the DNS requests to that IP.
If that's your Public IP then unless you open port 53 in your firewall to allow inbound requests ( I wouldn't recommend that ) that IP will not work (when it comes to Ad blocking) ...
The /etc/resolv.conf file above comes from the client. The one on the Pi-hole server is pointing to 172.31.0.2. Is that correct?
Port 53 is open.
That should point to 127.0.0.1 (on the Pi-hole server).
If the client is outside of the LAN then you'd have resolv.conf point to the PUBLIC IP of the Pi-Hole server.
If the client is within the LAN, you can leave the DHCP server to hand the DNS server settings.
But running an open DNS server is really a bad idea unless you really know what you're doing and implement at least some minimal protection.
Here's some info:
https://www.incapsula.com/ddos/attack-glossary/dns-amplification.html
I've updated the /etc/resolv.conf file on the PI-hole server and it now contains
nameserver 127.0.0.1
nameserver 172.31.0.2
The second server is added by AWS I think.
Anyway, if I do host google.com 52.214.17.59 from a client pihole tail still won't log it. Also ads are not blocked on the browser.
Do you have any other idea?
Yes ... close down DNS with the firewall and only allow IP addresses that you know are yours or from friends/family!
Or setup openVPN on server and clients to do all the stuff like SSH, DNS, web etc, even on mobile devices, through a secure VPN tunnel:
https://docs.pi-hole.net/guides/vpn/overview/
You really dont want to contribute to a DDOS amplification attack on for example your local bank or hospital do you ?
After firewalling, try below one on one of your clients:
pi@noads:~ $ dig @52.214.17.59 version.bind txt chaos
;; ANSWER SECTION:
version.bind. 300 CH TXT "dnsmasq-2.79"
I've updated the security group configuration and it's now only reachable from my home.
This is the output of that dig:
➜ pi-hole.supply dig @52.214.17.59 version.bind txt chaos
; <<>> DiG 9.13.0 <<>> @52.214.17.59 version.bind txt chaos
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15721
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ecc0a2bd297cf7c3 (echoed)
;; QUESTION SECTION:
;version.bind. CH TXT
;; Query time: 5 msec
;; SERVER: 52.214.17.59#53(52.214.17.59)
;; WHEN: Wed Jul 25 19:58:42 CEST 2018
;; MSG SIZE rcvd: 53
I just found out that my Vodafone router had an option enabled called Safe DNS which prevent usage of custom DNS servers. I disabled it and now I see Pi-hole logging queries. It's still not blocking ads though 
Run these commands from both your Pi-Hole OS (in your case Arch Linux) and from a client machine that is seeing ads (substitute nslookup for dig depending on your client OS), and post results.
dig flurry.com - this checks a known ad-blocked site. Should not return an actual IP, should return the IP of your Pi-Hole.
dig flurry.com @8.8.8.8 - this checks same site on a third party DNS, bypassing your Pi-Hole. This should return the actual IP.
Both locally
➜ pi-hole.supply dig ad.flurry.com
; <<>> DiG 9.13.0 <<>> ad.flurry.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34133
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ad.flurry.com. IN A
;; ANSWER SECTION:
ad.flurry.com. 300 IN A 172.31.7.138
;; Query time: 55 msec
;; SERVER: 52.214.17.59#53(52.214.17.59)
;; WHEN: Wed Jul 25 21:10:12 CEST 2018
;; MSG SIZE rcvd: 58
and on the Pi-hole server
[root@ip-172-31-7-138 ~]# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.1
nameserver 172.31.0.2
[root@ip-172-31-7-138 ~]# dig flurry.com
; <<>> DiG 9.13.0 <<>> flurry.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51975
;; 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. 300 IN A 172.31.7.138
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 25 19:08:46 UTC 2018
;; MSG SIZE rcvd: 55
is replying with the same ip address: 172.31.7.138, which doesn't seem to be the real one anyway: Dig web interface - online dns lookup tool
On the server, in my /etc/resolv.conf I have an extra DNS server which I suspect is added by AWS: nameserver 172.31.0.2. It seems to be in the same subnet but I'm not sure what it's happening here.
Also, I checked /etc/pihole/gravity.list and flurry.com is in that list.
You only ran the dig flurry.com command, and didn't test a direct lookup to the Google servers with the second command. Please run the second command and post results.
Your Pi-Hole appears to have the IP address 172.31.7.138 (confirm by running host pi.hole). If Pi-Hole blocks a site (either from block lists or your black list), it returns the DNS address of the Pi-Hole. If the site is not blocked, Pi-Hole returns the DNS address it obtained from the third party DNS server.
In both your dig commands, the Pi-Hole returned it's own IP address, which indicates that it blocked the domain "flurry.com". The "server" address in your case is the IP address of your resolver that was previously public.
If ads are getting through to a client, I think it's a sneak path either through the second name server or in your router or on the client.
I've found the issue! It was not resolving ad-delivers domains with the Pi-hole server IP address. I fixed that in the /etc/pihole/setupVars.conf configuration file, restarted and it worked.
I also added reject rules for HTTP(S) ports and opened them in the security group, so the connections won't hang.
Good job!
pi@noads:~ $ host pi.hole 52.214.17.59
;; connection timed out; no servers could be reached
Yeah I suspected something like this happening so wanted to make sure with the dig version, it really was dnsmasq answering and not some safety mechanism on the router like rebind protection:
This means processes/scripts/tasks/programs running on this VM that depend on DNS resolution will sometimes query Pi-hole's own DNS service on the loopback interface 127.0.0.1, and sometimes they will query the other DNS 172.31.0.2.
Nothing wrong whit that but prefered is to have all DNS queries run through 127.0.0.1.
Tip: if you default the router settings @ home, and only configure the upstream DNS resolver for the router (often called WAN DNS or something) to be that of the Pi-hole IP address (no secondary DNS!), the clients, through DHCP, will be configured to use the router for DNS resolution.
And in turn, the router will forward queries to Pi-hole to have them answered.
That way you have your router caching DNS queries on your local network resulting in less traffic to the (slower) internet.
Ps. if you fiddle with DHCP settings, always make sure the client DHCP leases get renewed.
Disconnect & reconnect network on the clients or reboot them.
Does that mean that ads could not be filtered depending on which server is used?
Exactly.
Run below one on Pi-hole to figure out where that 172.31.0.2 address is configured:
sudo grep 172.31.0.2 -R /etc/ | grep -v gravity
If you find it, you could try replace it with 127.0.0.1 and reboot to check:
cat /etc/resolv.conf
Ps. I changed title a little bit for others to find.