Hi all, thanks for such a great product!
I currently have my router set to send all DNS traffic to my Pi-Hole (a RPi3), and everything is working wonderfully. I'd like to get a sense for how to allow one machine in my internal network to bypass the Pi3 and go directly to the upstream DNS servers, without clogging the logs.
Would iptables be the place to start? The machine handles automated content searches, and isn't a machine that does any 'browsing,' so I don't have a need for ad-blocking.
If iptables on my Pi-Hole machine isn't the right place to work on something like this, can anyone point me in the right direction?
on the machine you would like to use for example google instead of your pi. go into the internet adapter settings and tell it not to use the DHCP supplied DNS i would be happy to walk you through this process should you have issues also googling how to manually set a DNS on your operating system will work too
Thanks, I edited the /etc/resolv.conf file in the FreeNAS jail running the machine in question, rebooted the jail, but didn't see any change in the volume of queries in the Pi-Hole log...
To give more concrete info, I'm seeing multiple queries from xxxxx.plex.direct (long session/plex server key before the .plex.direct) and it's skewing my pi-hole data to give a large number of overall queries, when I'm really interested in actual browsing queries/blocks...
Any other advice??
so the one machine you would like to use only the upstream?
what OS is it
that will help me get you where you want to be
also have you blocked in your router all outgoing port 53 except from your pihole IP? if you did this which is recommended you can set whatever you want on the one machine but it will not work
No, the machine has traffic both up & down.
It's a FreeNAS (FreeBSD) jail.
I haven't blocked port 53 on my router. I've sent my DNS server in my router to my Pi-Hole, but I haven't blocked anything.
Often you'll find that the /etc/resolv.conf file is automatically generated, and any manual changes to it are overwritten when the state of the interface changes, like in a reboot. Check the /etc/resolv.conf file again and see if it's been reverted back to the DHCP supplied values. (And if you can check the file for any comments that may shed light on the process that generates it, that would help.) It's been a while since I've been on a BSD variant however.
https://forums.freebsd.org/threads/39986/ This thread in the top post has a quoted text that you may find useful as well
Thanks for chiming in!
Commented out: Generated by resolvconf
nameserver 10.0.0.1 (which is set at the host server level)
I commented out 10.0.0.1 and added OpenDNS primary and Secondary DNS servers
nameserver 208.67.222.222
nameserver 208.67.220.220
saved the changes and rebooted the jail (same as rebooting the machine, in this case).
The .plex.direct queries were still showing up in the logs after that.
Okay, every time you reboot, any changes to /etc/resolv.conf will be overwritten with what the DHCP server is sending out. You would need to look at /etc/resolvconf.conf which is the configuration file for resolvconf which is the damon that keeps overwriting your changes to /etc/resolv.conf. It's a big circle...
Thanks Dan- the changes to /etc/resolv.conf currently survive the jail/machine reboot (i.e. resolvconf.conf isn't overwriting).
I'm going through the paces again, and will let you know if the issue resolves. At the present, my resolv.conf file persists, I've commented out the resolvconf generated dns server, which leads back to my Pi-Hole, in favor of OpenDNS servers, with the hopes of making the Pi-Hole query/log data being a lot more useful! At present, despite the saved changes and machine reboot, I am still seeing plex.direct queries in the log, which makes me think my resolv.conf file in the jail isn't actually bypassing my router/Pi-Hole DNS.
Thanks everyone.
No new news, .plex.direct is still showing up in my Pi-Hole logs, leading me to believe my FreeNAS jail might not be respecting its internal resolv.conf file.
Based on forum posts over in the FreeNAS forums, I would have thought I'd be good to go, but perhaps things have changed:
Any other thoughts?
From the jail command line, try dig google.com and see what DNS server is listed for the lookup. That will tell us where it's going by default.
dig google.com
Query time: 11 msec
SERVER: 208.67.222.222
So it looks like outbound DNS requests are going directly to OpenDNS, which is my desired behavior.
Again, the flooding query is xxxx.plex.direct, and references the IP address of my internal PlexServer Jail in the query line. It looks like this: 10-x-x-64.xxxx.plex.direct, with 10.x.x.64 being the same as my PlexServer Jail, and xxxx referring to Plex's reference ID for my specific server (since Plex registers every server through their Plex TV service). These queries are both A and AAAA types, and tend to occur in batches of 6-12 queries in the same second, every minute or two. I'm thinking this is Plex.TV checking in on the status of my server, which is why I'd like the constant query to be handled outside of Pi-Hole.
I also realize this may be outside the realm of Pi-Hole, and may be best asked on FreeNAS/Plex forums... any additional/last thoughts??
Are you able to determine the source of the query? Or is it just localhost that is doing the lookups? It sounds as it it may be a client trying to check the Plex server to see it's status, but it may be something from Plex directly. I'm wondering if it may not be the Plex server that is doing the lookups however.
I have 3 local clients, and I've set all of their dns servers to OpenDNS as well, and am still getting flooding from the same xxxx.plex.direct query.
At this point, I'm really not sure what else I have control over! I'll post on the plex forums to see if they have any ideas as to where the large number of queries are coming from.
EDIT: One additional note. When I open the XML info for a specific file in Plex, I get the same 10-x-x-64.xxxx.plex.direct style address like I'm seeing in my query log.
Plex Forums have been zero help- 40-something views and 0 comments...
That being said, I believe I'm seeing the majority of the queries when I am streaming Plex from outside my home network. My guess is that the Plex.TV servers are the cause, which is outside of my control.
Thanks to everyone who offered ideas!
im not that familiar with plex but i have done some work with video servers in past(think jumbotron) does plex broadcast to your network and could that be causing this ?
to be more clear i mean does it use the broadcast address of your network
My Plex setup is a server internal to my network- it hosts all of my media. I then have local and remote clients that access my server to view the media. Plex, as a company, does "host" a domain that essentially serves as a gatekeeper- i.e. rather than remote clients connecting directly to my domain, they connect through the Plex.TV service, which handles the secure connection (and before you ask, yes, I can access my server through my own domain, via a secured reverse proxy). I could view my media via a browser window (pointed at my domain), but it seems that the actual Plex apps (like on an iphone, for example) only use the negotiated connection through the Plex.TV service, which directs clients to my external IP and a securely negotiated port.
Based on all this, and the fact that I know I've directed my Plex server and internal clients to bypass my Pi-Hole, my only guess is that the Plex.TV service is causing the log flooding. I can understand why the service may be talking to my server a couple of times a minute when I'm remotely streaming, but I can't understand why it would be talking to my machine at the same rate when I'm not viewing anything...
the only thing i could suggest is force all of your remote clients to disconnect or turn those devices off and see if the behavior stops ... maybe you have already done that ... just thinking out loud...
also thanks for the explanation thats how i thought it worked but wasnt 100% sure
Thanks- I'll have to wait for the weekend to shutoff all of my remote clients. We'll see what happens then!