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"
1 Like
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
1 Like
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.
1 Like
There is no trace in /etc:
[root@ip-172-31-7-138 ~]# ag 172.31.0.2 /etc
[root@ip-172-31-7-138 ~]#
I've tweeted the creator of the Arch Linux image for EC2.
How is the IP configured on this EC2 VM ? Is it static or acquired through DHCP ?
Is dhcpcd5 installed ?
apt-cache policy dhcpcd5
Whats in the dhcpcd.conf file ?
grep -v '#\|^$' /etc/dhcpcd.conf
If no static IP details are set in dhcpcd.conf, you could try add below two lines at the end of the dhcpcd.conf file and reboot to check:
nohook resolv.conf
static domain_name_servers=127.0.0.1
Ohw ps. all these options are described on the man page if dhcpcd5 is installed:
man dhcpcd.conf
EDIT: Not sure about the nohook so also try without the 'nohook resolv.conf'.
I've updated my /etc/dhcpcd.conf file in this way:
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
noipv4ll
# Disable ARP probes, allows us to take our lease sooner.
noarp
nohook resolv.conf
static domain_name_servers=127.0.0.1
[root@ip-172-31-7-138 ~]#
restarted the whole vm but still getting nameserver 172.31.0.2 in my /etc/resolv.conf
Looks like the VM is set to acquire IP details etc via DHCP.
Try only below one:
nohook resolv.conf
And manually edit resolv.conf to have only 127.0.0.1 as nameserver.
See if that survives a reboot.
EDIT: or one could remove the "option domain_name_servers" from dhcpcd.conf to prevent resolv.conf from being overwritten by the DHCP process.
I solved by editing the files in /etc/systemd/network folder by setting UseDNS=no.
1 Like
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.