Confused about DNS forwarding and local domains

Jeremy11one · Mar 10, 2020, 5:32 PM

My pfSense DNS server is forwarding queries for LAN hosts to a public DNS server when I don't want it to. It also appends the local "domain" to queries when it shouldn't. I'm not sure how to fix it.

My configuration:

hosts run Windows
private LAN domain = internal.mydomain.com
example private host = webserver.internal.mydomain.com 192.168.1.11
public website = www.mydomain.com
wildcard on my public DNS server (Google Domains) = *.mydomain.com 1.2.3.4

Demonstration of problem:

nslookup missinghost-> forwards to my public DNS server and returns "missinghost.internal.mydomain.com 1.2.3.4" but I want pfSense to return nxdomain without forwarding
nslookup www.otherdomain.com -> forwards to my public DNS server and returns "www.otherdomain.com.internal.mydomain.com 1.2.3.4" but I want it to go to otherdomain.com's DNS server to query host "www" instead of mydomain.com's DNS server.

I think I want this behavior:

nslookup webserver -> should return "192.168.1.11" without forwarding
nslookup webserver.internal.mydomain.com -> should return "192.168.1.11" without forwarding
nslookup missinghost -> should return "nxdomain" without forwarding
nslookup missinghost.internal.mydomain.com -> should return "nxdomain" without forwarding
nslookup www -> should return "nxdomain" without forwarding
nslookup www.mydomain.com -> should be forwarded to the public DNS server for mydomain.com and return public IP "1.2.3.4"
nslookup www.otherdomain.com -> should be forwarded to the public DNS server for otherdomain.com and return public IP "5.6.7.8"

I've read about "Local-Zone types", domain overrides, and split DNS, but I can't get the behavior right. It works better if I append "." to the end of the query like "nslookup www.otherdomain.com." but I'm hoping to fix this without always having to append ".".

Thank you

Jeremy11one · Mar 10, 2020, 7:05 PM

I think if I can just get pfSense to be authoritative for internal.mydomain.com, it might solve all the problems. That way, it won't forward queries from LAN hosts for missinghost.internal.mydomain.com or www.google.com.internal.mydomain.com to public DNS servers. But it would go out to public DNS servers for everything else, like www.mydomain.com and www.google.com.

I found this page where someone tried to fix this problem using two DNS servers running on pfSense at once, but jimp said that's not allowed.

johnpoz · Mar 10, 2020, 7:33 PM

@Jeremy11one said in Confused about DNS forwarding and local domains:

nslookup missinghost-> forwards to my public DNS server and returns "missinghost.internal.mydomain.com 1.2.3.4" but I want pfSense to return nxdomain without forwarding

Set your zone in pfsense to static vs transparent...

https://nlnetlabs.nl/documentation/unbound/unbound.conf/

static
If there is a match from local data, the query is answered.
Otherwise, the query is answered with nodata or nxdomain.
For a negative answer a SOA is included in the answer if
present as local-data for the zone apex domain.

as to this
nslookup www.otherdomain.com -> forwards to my public DNS server and returns

It would only do that if your client is adding the suffix, this has zero to do with unbound.. Its just doing what was asked if.. But if you set static as your zone type its not possible for this to happen even if your client asks for whatever.something.whatever.domain.com If your using domain.com internally and you have public.

This is one of the reasons why its not a good idea to use the same internal domain as you do public.. You should use something that is not public, or with a tld that does not resolve, etc..

as to this
nslookup www.mydomain.com -> should be forwarded to the public DNS server for mydomain.com and return public IP "1.2.3.4"

Why would you want that??? What it should return is your internal IP that www.domain.com is served off of - ie split dns.. If that is some some IP that is not pfsense and actual wan... Then you have the whole issue of trying to use the wrong domain internally for ZERO reason... Just use something different internally for your domain.

SteveITS · Mar 10, 2020, 7:38 PM

Normally with a Windows networking domain you don't want the router to resolve DNS for PCs because any PC pointing to it will have trouble connecting to the domain (slow logins, errors, retries, etc.).

Does missinghost.internal.mydomain.com actually exist on the internal network? Or is the error that it is returning an IP address?

Assuming you're querying from Windows what are the advanced TCP/IP settings (DNS tab) on the network connection? (e.g. for appending DS suffixes) However that should only affect "unqualified names" without a domain (your "missinghost" query).

Jeremy11one · Mar 10, 2020, 8:35 PM

@johnpoz said in Confused about DNS forwarding and local domains:

@Jeremy11one said in Confused about DNS forwarding and local domains:

nslookup missinghost-> forwards to my public DNS server and returns "missinghost.internal.mydomain.com 1.2.3.4" but I want pfSense to return nxdomain without forwarding

Set your zone in pfsense to static vs transparent...

I tried that before and it didn't seem to work, but now I understand that it DID work. With it set to Static, pfSense properly returns nxdomain. But then my WINDOWS computer decided to send a separate query directly to mydomain.com, which is what confused me when I saw a final result of 1.2.3.4. I thought pfSense did it, but it was actually Windows. So setting it to Static is the correct solution, and I just need to see about getting Windows to quit sending followup queries up the FQDN chain until it gets a successful result. Thank you again.

nslookup www.otherdomain.com -> forwards to my public DNS server and returns
It would only do that if your client is adding the suffix, this has zero to do with unbound.. Its just doing what was asked if.. But if you set static as your zone type its not possible for this to happen even if your client asks for whatever.something.whatever.domain.com If your using domain.com internally and you have public.

Thank you. I was just reading about that. I was taught that a FQDN was "www.google.com", but now I understand a FQDN is actually "www.google.com.".

This is one of the reasons why its not a good idea to use the same internal domain as you do public.. You should use something that is not public, or with a tld that does not resolve, etc..

I've read in so many places that a fake domain like ".internal" is bad and everyone recommends using a subdomain of a real domain that we own, like "corp.mydomain.com" or "internal.mydomain.com". Now I have no idea what the best practice is if you're saying that advice is wrong.

nslookup www.mydomain.com -> should be forwarded to the public DNS server for mydomain.com and return public IP "1.2.3.4"
Why would you want that??? What it should return is your internal IP that www.domain.com is served off of.

I always did that for simplicity reasons so everyone accessing a site uses the same IP to do it. Can I ask why you recommend using an internal IP to access our public website? Is it to get slightly better DNS performance before the query gets cached, not relying on an external DNS server, not relying on our ISP being up, and not having to run all the web traffic through the firewall?

Thank you

Jeremy11one · Mar 10, 2020, 8:39 PM

@teamits said in Confused about DNS forwarding and local domains:

Normally with a Windows networking domain you don't want the router to resolve DNS for PCs because any PC pointing to it will have trouble connecting to the domain (slow logins, errors, retries, etc.).

Good advice. This is not a Windows domain network, just my home network. At work with our Windows domain, all clients point to the AD integrated DNS server.

Does missinghost.internal.mydomain.com actually exist on the internal network? Or is the error that it is returning an IP address?

missinghost is just a fake name I made up that is intended to get a nxdomain result. The unwanted actual nslookup result is our public IP address. So it goes client > pfSense > public DNS (wildcard CNAME) > pfSense > client. What I would like to happen is client > pfSense (sees that it's a query for an internal host on internal.mydomain.com and it doesn't exist in the pfSense cache so it returns nxdomain) > client.

I now learned that setting pfSense Resolver to "Static" instead of "Transparent" does solve the problem as far as pfSense is concerned; it duly responds with nxdomain like an authoritative DNS server for internal.mydomain.com. The remaining problem is that Windows sees that nxdomain and then follows up by removing one piece of the FQDN and sending a new query, for example missinghost.mydomain.com, and pfSense duly passes that non-authoritative query out to the public DNS.

Assuming you're querying from Windows what are the advanced TCP/IP settings (DNS tab) on the network connection? (e.g. for appending DS suffixes)

It uses DHCP so the GUI is blank, but ipconfig says the interface has a "Connection-specific DNS Suffix . : internal.mydomain.com" (mydomain is my censored version for this forum, not what it actually says). Do people normally just not have a search domain? Would pfSense (or NetBIOS) still reliably resolve "webserver" for me if I don't have a search domain?

However that should only affect "unqualified names" without a domain (your "missinghost" query).

My understanding is that it affects EVERY query unless the query is a true FQDN (which ends with a period). So it will affect "google.com" and "mywebserver", but not "google.com." or "mywebserver.". I found a workaround on a different forum that says to make "." the first value in the list of search domains, which will tell Windows to attempt to resolve things exactly as entered first, and only if that fails, then append the other search domains. It's a neat idea but since it's not the standard Windows behavior, I'd guess it's not best practice. I wish it was the default behavior though.

Thank you

SteveITS · Mar 10, 2020, 8:49 PM

@Jeremy11one said in Confused about DNS forwarding and local domains:

a fake domain like ".internal" is bad and everyone recommends using a subdomain of a real domain that we own

This is for Windows...long ago MS recommended using .local or whatever else, and now with more TLDs, if .local is ever allowed then someone could get it and create secure certs on your Windows domain network name. Plus I think .local is used for Bonjour, IIRC.

@Jeremy11one said in Confused about DNS forwarding and local domains:

public DNS (wildcard CNAME)

Ah so it's a valid answer from DNS.

If you're on a workgroup then my comments about domain DNS don't apply, as you noted. Windows should be able to resolve PC names on the local network without DNS.

Keep in mind Windows will cache DNS results on the PC (DNS cache service), as will a caching DNS server. On Windows, ipconfig /flushdns clears the cache.

Is the internal.mydomain.com domain configured in pfSense? Usually with DHCP Windows will get that from the DHCP server, though it can be configured.

It is "more correct" to end FQDNs with dots but that doesn't affect lookups here against our Windows DNS server, or in our data center against pfSense from Linux nslookup. Usually I run into that if someone has tried to add a CNAME or MX record to DNS and used "example.com" instead of "example.com." with the dot, since the DNS server assumes the "example.com" is in that same zone.

Jeremy11one · Mar 10, 2020, 9:13 PM

I learned a lot today. Here's a summary for anyone else who is interested. This assumes your DNS Suffix is internal.mydomain.com:

Changing pfSense Resolver's "System Domain Local Zone Type" setting from "Transparent" to "Static" does make pfSense behave as if it's authoritative for the domain set in General > Setup. So if you query pfSense for nonexistinghost.internal.mydomain.com, pfSense will immediately respond with nxdomain without trying to send the query out to an external DNS Server. If it's still set to Transparent, pfSense will assume that the value is just missing from its cache so it will pass the query along to the external DNS server.
Using nslookup in Windows does DNS differently than ping. With nslookup, if you query for host1, it will first send a query for host1.internal.mydomain.com, and if that receives nxdomain, Windows will then send a followup query for host1.mydomain.com. However, with ping, if you ping host1, it will attempt to resolve host1 by querying host1.internal.mydomain.com, and if that receives nxdomain, it will stop right there without attempting to resolve host1.mydomain.com.
A FQDN always ends with a period. "myhost.mydomain.com" is not a FQDN. "myhost.mydomain.com." is a FQDN. This matters because nslookup will treat those two hostnames differently. With the partially QDN, it will append the DNS Suffix to the query so the computer ends up wasting time by querying craziness like www.google.com.internal.mydomain.com. With the FQDN, it will not append the DNS Suffix but will send the query as you typed it, so you'd get a nice clean query for www.google.com.
If you want to troubleshoot DNS on Windows, run "nslookup", then type "set debug", then type your query. That will tell you exactly what Windows is doing, including the multiple unexpected queries mentioned above, and exactly which response comes from which server. If you just run the usual "nslookup google.com" command then you may be confused by the oversimplified answer.

Thank you for your help!

johnpoz · Mar 11, 2020, 7:19 PM

@Jeremy11one said in Confused about DNS forwarding and local domains:

everyone recommends using a subdomain of a real domain that we own

This is HORRIBLE advice - just horrible!!! If you want to use a domain that you own fine - just make sure nothing is served up public on it.

Pretty sure MS even retracted that advice, or clarified how to do it, etc... There is just zero reason to use the same domain internally - none! Back what like 25 years ? Wow!!! time goes fast! ;) Even back then when young and stupid and moving to AD in company I worked for then... We used domain.net internally for our AD domain, while all or public stuff was domain.com..

While you can for sure do, it just takes more work - its just easier to use different internally than you use externally so you don't run into such issues. Its also easier when you don't have users accessing your public stuff hosted in the same location they are accessing stuff from... Via a port forward or something... You shouldn't host stuff to the public from the network your users are on, nor even the same public IP they go out on, etc.. Mom and Pop shops have problems with this sort of stuff.. For an enterprise is not that big of deal.. Because they normally have their own public space, and their IT staff knows what they are doing, etc. etc..

Lets be clear on something... Its great that you own the domain your going to use internally.. Doesn't mean you should serve stuff to the public on the same domain.. This way your pretty clear that if you merge with another company you don't have to worry about same domain names, etc.

Also keep in mind that AD dns will be authoritative for that domain... So it would never forward something that doesn't exist in its name space. This is way different than what pfsense default setting is.. That is where the problem is - things change when you control the authoritative NS for the domain.. So even if you use the same domain locally, since your clients would all be pointing to your AD ns, you would never have to worry about them forwarding to public space and finding something that is not local - unless you specifically put in the record for that..

To be honest - the default for unbound should prob be static vs transparent.. But netgate would know better their normal users typical use cases. I personally don't get why it defaults to transparent - But I have not thought out all the possible use cases.. To be honest I would think most of their users just end up with the default localdomain as their tld ;) And anyone knowing what they should setup for a domain, should really already understand the implications if they are changing it.. But that is me with 30+ years experience in the field.. And a personal passion for DNS in general ;)

Mine has always been static, like fist thing changed ;) And I don't even use anything that could ever be public - I use local.lan for my internal domain. There is just no reason for unbound to try and resolve something that I only use internally - it would just be noise going out to the public net..

I own multiple public domains, but I just don't see a valid reason to try and use one of those locally.. I host multiple things using different domains, just none of it host here... Now I do have a domain I use that points to my public IP, I use this to access my public IP for different things. But its not the local name for anything - its just the public facing domain.. And I don't host the authoritative NS locally.. Its hosted publicly either at the registrar, domain service I have, and even my own vpses that I use to play with dnssec and bind in general that is public facing, etc.

I could talk about dns all day ;) So if you have dns questions - I will more than likely chime in ;) hehehe

Jeremy11one · Mar 11, 2020, 7:23 PM

@johnpoz said in Confused about DNS forwarding and local domains:

I could talk about dns all day ;) So if you have dns questions - I will more than likely chime in

It's fantastic that knowledgeable people like you are willing to share advice with everyone, especially so quickly. Thank you again.

This is HORRIBLE advice - just horrible!!!

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.

To summarize the article:
||*Microsoft used to advise everyone use a domain like "mycompany.local" or "mycompany.lan" (and NetGate seems to still recommend using .lan or .mylocal in their documentation and default values).

But about 10 years ago, MS changed their recommendation. Now they recommend against those domains because those domains are not officially reserved, so some day people might be able to buy domains with those TLDs or use them for other things, exactly like Apple did by registering .local to use for their mDNS feature. Everyone who previously used .local got burned when that happened, and there's nothing to guarantee that the same won't happen with .lan or .internal.

So now Microsoft recommends specifically using a subdomain of a domain we own. A less recommended option is what you mentioned, using .net for internal and .com for public, so that's ok too.*||

Here's the list of IANA "special use" domains: link. .lan and .internal are not on that list (yet)

Here are some more sites that agree that it's best to use an owned subdomain: spiceworks, serverfault, random blog, stack overflow, random blog, random blog, random forum, reddit

Using pfSense "Virtual IPs" and Reverse NAT, one can set the lan hosts to use IP#1 and the DMZ servers to use IP#2, avoiding the problem of an infected lan host getting an email server blacklisted.

I'd guess the reason "Transparent" is the default is to avoid breaking DNS for people and leaving them in total panic and confusion. People wouldn't expect pfSense to take over their DNS domain by default since it's "just a firewall". I like the idea of Transparent being the default but there should be a big message below it explaining the purpose of "Static" instead of the current mention (not even a link) to a webpage that isn't easy to understand.

Fun!

johnpoz · Mar 11, 2020, 7:45 PM

@Jeremy11one said in Confused about DNS forwarding and local domains:

exactly like Apple did by registering .local to use for their mDNS feature.

This is not an official TLD... Where do you think they registered it at? It is part of https://tools.ietf.org/html/rfc6762 its not a "apple" thing per-say... its a mdns thing.. You don't have to be an apple product to use mdns.

Sure there could be some change in direction and .lan or .internal could be used.. Then you switch to something else.. But doubt .lan would ever be used as public tld.. Nor internal since they make no sense in that context..

Sure someone could prepose use of .whatever -- it will be either accepted or rejected by the community... Which is the whole point of the RFC process.

Using the same exact domain you use internally as publicly to access stuff is bad idea... Nowhere in their documents do they spell out that you should host shit on that domain as well as use it internally... They just state you should own it.. Which sure is fine... But don't try and host shit on it to the public as the same time as using it internally..

People just read that into it... Where do they say you should host your site on www.domain.com, and then use site.domain.com for your AD? Its just that small ma and pa shops or users think own I own domain.com I will use that as my AD... Not good idea!!

Subdomains are used all the time for any location of a domain, or as way to differentiate.... I use dmz.local.lan, wlan.local.lan for example..

Sure you could do internal.domain.com for your internal stuff if you wanted.. You just have to understand how dns works, and what your client could be doing as it adds suffix, etc. etc. Again its not a problem when your running an authoritative NS.... But it still is just easier and less likely to cause new users problems if they just use something different for their internal domain, that has no possible way to resolve publicly...

bb77 · Mar 13, 2020, 2:12 PM

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

johnpoz · Mar 13, 2020, 3:56 PM

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!!

Jeremy11one · Mar 13, 2020, 3:59 PM

@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.

johnpoz · Mar 13, 2020, 4:08 PM

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!

bb77 · Mar 13, 2020, 4:47 PM

@johnpoz:

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...

ahking19 · Mar 13, 2020, 5:26 PM

@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.

bb77 · Mar 13, 2020, 6:11 PM

@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 :-)

ahking19 · Mar 13, 2020, 6:51 PM

@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/

bb77 · Mar 13, 2020, 7:50 PM

@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.