I’ll start with the obligatory “I know enough to be dangerous, but not much beyond that”… and I may use some terminology incorrect so any corrections are welcomed to help me better learn and understand.
I have pfsense set up at home with add blocking via pfblockerNG, and a wireguard setup so I can tunnel back into my LAN and access my homelab webUI’s and SSH etc. The question is… while I am away from my LAN and connected with wireguard, how do I get hostname resolution?
Option 1 which I believe to be the only option I understand, would be to point wireguard at my pfsense for DNS. That way when I try and SSH to my.local.server, pfsense knows that IP and will resolve it correctly (and I will also get add blocking this way). But the downside is that I am no pointing back to my house for DNS and that is a fair bit slower than going out to say 1.1.1.1. It is not drastic (actually, how would I run an actual test on this? Right now I just “feel” it being slow) but it is noticeable.
Option 2: well I am not sure what option 2 would be. Is there another way to do this? I can think of potentially spinning up a docker container on my macbook with pihole, somehow tell it that my.local.server domain lives within my homelab subnet, and somehow that would give me add blocking and resolution of hostnames? I am not entirely sure, and spinning up a pihole on my laptop just for this seems a bit over the top.
Any ideas? Obviously this wheel has already been invented and I am just late to the party - what is the norm for this type of thing? Should I add DNS lookups manually on my laptop? But then if they end up changing or I add new servers I would need to remember to update them which seems like would happen.
You understand 1 correctly. If you are connecting to your home network anyway, you can push the dns traffic that way. There will be a little more ms but…
Otherwise start some remote VPS which will replace your local network in terms of dns. But the end result will be similar or more ms.
You can use the HOST file on the laptop to block domains.
You can purchase a small sbc and wear it as a mobile dns / blocker.
Yes, that is more or less correct. I currently am pushing DNS up through my wireguard VPN back to my home LAN and letting pfsense resolve requests which provides add blocking + human readable host name resolution for servers within my house. Which is what I want to be happening, I just was trying to figure out if there was a way to not incur the latency penalty of going to my home for DNS. I guess it isn’t that big a deal, just was not sure if there was another way to do this.
If these services are all http/https based you can setup a socks proxy and tell your browser to use it only for a certain domain(s). If you want to be extra ambitious you can also setup a proxy pac file (wpad) file.
If you want to use home location, the answer is no. There is no magic solution to reduce the lag. Extra path always generates extra run time. Same rule as if you were going from A to C and suddenly want to A-B-C and have the same KM / Miles as A-C.
Simply put.
If you want to reduce packet runtime then you need to have a dns / filter as close to the source as possible. So some container / VM on a laptop or an additional device that will act as your mobile router and pi-hole, and thus you will connect to the network.
Whatever the location, it will generate some runtime… Depending on whether it’s your home or some other place. The rule is simple, the closer you are to something, the better.
There can be extreme situations, for example
Your dns / pfng (home) located in the USA and you will travel to England and from there you will connect to your home and use pfng. In such a situation, you will have a lot of unnecessary lag in comparison if you would do these services on, say, a rented server in the UK. It’s all about the simple concept of distance… but of course not always the physical location will match the effectiveness of an online location. The topology of the network is important and sometimes it may be that even a physical location quite close may be slower than another location physically further away.
