Confused about DNS forwarding and local domains
-
Hello folks
I think Split-DNS is quiet common for homelabs or personal use and I even saw big corporations doing it. In my homelab I use "local.mydomain.tld" for all internal services and "mydomain.tld" for some public facing services. All with one dynamic public IPv4 Address. Internally I use separate networks/subnets for PC/Laptops, Servers, IOT, DMZ etc. For professional use however, I would recommend at least two public IP Addresses. One for hosting the external facing stuff and one for your regular internet access. If you wanna selfhost e-mail, a dedicated static IP is mandatory.
On the pfsense side I did the following steps to set this up:
-
Disable NAT-Reflection
-
enter "local.mydomain.tld" to System->General Setup
-
enter your preferred upstream DNS-Servers in System->General Setup
-
"DNS Server Override" and "Disable DNS Forwarder" are both unchecked
-
Enable "DNS Query Forwarding" in Services->DNS Resolver->General Setup
-
Set "System Domain Local Zone Type" to "Static" in Services->DNS Resolver->General Setup
-
Enter A-Records for all Services in the Custom Options:
server:
local-zone: "local-only-service1.local.mydomain.tld" redirect
local-data: "local-only-service1.local.mydomain.tld 3600 IN A 192.168.10.10"
server:
local-zone: "local-only-service2.local.mydomain.tld" redirect
local-data: "local-only-service2.local.mydomain.tld 3600 IN A 192.168.10.10"
server:
local-zone: "public-service1.mydomain.tld" redirect
local-data: "public-service1.mydomain.tld 3600 IN A 10.0.10.10"etc...
-
For the internal networks you can now block all DNS Traffic to other DNS-Servers than the Firewall it self:
Allow Source: * * -> Destination: "LAN address" 53
Block: Source: * * -> Destination: * 53
Everything seems to be working fine and i think for home use or even really small businesses this setup should be ok.
@the experts:
Please correct me if I did anything wrong or overlooked/missed something.Cheers
foofighter77
-
-
You understand that host overrides can just be done in the gui right...
And why are you forwarding - why not just resolve... I fail to understand the fascination of users to hand over all their dns queries to a specific company... But then scream my dns is leaking... Yeah your freaking leaking everything you do to company X ;) hehehehe on purpose!!
-
@johnpoz said in Confused about DNS forwarding and local domains:
And why are you forwarding - why not just resolve... I fail to understand the fascination of users to hand over all their dns queries to a specific company...
It's a neat situation of pros and cons. If we resolve, it's done in plaintext so ISP and bad guys can see the queries. If we forward, it hands all our lookups to a 3rd party, but at least those are encrypted and we can choose which 3rd party to trust. So neither option can provide all the benefits. I'd say either option is reasonable depending on the situation.
-
Yeah - my dns resolving is too fast... Let me slow it up!!! and put in a tcp tunnel... Cuz you know that ISP I pay for internet, and handles all my traffic and sees every IP I go too... Sure and the F wouldn't want them know I did a query for google.com..
If your concerned with your isp spying on you - then tunnel all your traffic through them... Forwarding dns to some specific company is not solving anything other than slowing up your dns and handing them everything you do on a silver freaking platter.
But sure have fun with that!
-
when I first tried to set this up it didn't work as expected with the host-overrides in the GUI. But it's quiet possible that other things were wrong configured at that time ;-)
I send my DNS lookups to https://dns.digitale-gesellschaft.ch/ via DOT. I did not mention this before for the sake of simplicity. Sure you have to trust that they keep word with their Privacy Notice. But I trust them way more than I trust my ISP or any other commercial companies like Google, Cloudflare, Quad9 etc...
-
@foofighter77
"any other commercial companies like Google, Cloudflare, Quad9 etc..."If you are resolving these companies are not part of the equation. You are directly querying the root servers.
If you don't trust your ISP using DOT doesn't completely solve your problem due to SNI. Server Name Indication (SNI) exposes the hostname the client is connecting to when establishing a TLS connection. So unless you have encrypted SNI or tunnel all your traffic thru your ISP you don't have privacy.
-
@ahking19 You're right I mixed things up a bit. Google, Cloudlare etc. are not relevant in this case. Except you explicitly use them as your DNS Provider. What they literally do in every other YouTube Tutorial ;-)
Total privacy an is not my goal here. And like you said there are always pros and cons in every situation. For me the most important thing is to keep the internet as decentralized as possible and as private as possible, and DoT with a thrust worthy DNS-provider seems like a reasonable compromise to me. For sure better than browsers with DoH via Cloudflare or Google enabled by default. ;-)
But thanks anyway for your correction and your addition about SNI. I was not fully aware about that little detail :-)
-
@foofighter77
Encrypted SNI is still being drafted but hopefully we will have it soon in all web browsers, although you can use it in Firefox - https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/Good article from Cloudflare on Encrypted SNI if you are interested - https://blog.cloudflare.com/encrypted-sni/
-
@ahking19 Thank you. Sounds interesting, especially the Encrypted SNI together with DOT. The Problem with DoH is, that it uses Port 443. And obviously you cannot block Port 443 at Firewall level. Therfore any device or software with hardcoded DNS over HTTPS settings can bypass your DNS Resolver/Forwarder.
-
not sure about the other user, but one use case was getting the green lock sign for https so you stop getting nagged that your https cert is invalid
https://www.youtube.com/watch?v=qlcVx-k-02E
so instead you do what wolfgang proposes, using the dns for local only, for the purpose of getting a valid working https cert using letsencrypt to work for a local only environment.
it also solves the issue of using digit lan ips and port numbers, and switch to some simple standard url but for local use.
and to make things cleaner, use a proxy manager like nginx proxy manager so you can reduce the usage of ports in the url.
not sure the security implications of this, but this is what wolfgang and technotim in their youtube said to do for local users running their own self hosting services to access their app web services locally.
-
@Jeremy11one said in Confused about DNS forwarding and local domains:
Here's a 2018 Microsoft page I found with contrary advice: link. I'm interested in your opinion to see if there's something that article hasn't taken into consideration.
While generally @johnpoz does have a point on the issues with leaky DNS when using public domains internally, it should be noted it only happens if mistakes are made in internal DNS setup (like fx. Transparent vs. Static, and searchdomains and such).
There are a lot of arguments for using a public internal domain when it comes to user transparency/understanding and just generally making lives easier because of “easy use” of short hostnames instead of FQDN. Also, I highly disagree with the argument that a private domain internally makes things easier - it does not in the majority of management cases with large userbases. It will create a lot of double maintenance in DNS, proxies and firewall setups (reflection) if your userbase generally are using webbased tools in their interaction with company ressources that are a mix of internally and externally hosted servers. Much easier to maintain with a public internal domain, and no need for NAT reflection which is a PITA.
So both solutions works and each have their advantages. It’s safe to assume MS made that recommendation from years of support and understanding what problems was caused by each model.
Yes, a private domain is the “correct” technical solution, but ease of use and maintenance has a tendency to win ;-)
It should be noted as we increasingly move towards SAAS in cloudservices, the public internal domain advantage in maintenance does “diminish” as those require you to make double maintenance in DNS if they are named in the public domain.
