Unresolvable DNS Entries
-
First off: I've been running pfsense now at our office of about 80 people for several months now and I'm loving it!
My issue though is that I don't want unresolvable address requests from the internal LAN side to redirect to my domain name. This seems like it'd be a pretty easy feature to turn off, but I haven't had much success.
I like being able to cache DNS info and that pfsense will search there first. I like being able to setup some static maps since I've got many devices on static IP. I like that if an address can't be found locally, or in memory, then it'll go to the DNS servers I've specified.
I just don't like that when a user puts in an address that doesn't exist that they get forwarded to our website… I'd much rather they go to an error page.
Any help would be greatly appreciated.
-
Tell us more about your DNS settings, because that is not the normal behavior.
a) DNS servers in System->General Setup (and anything special they are doing - e.g. I have an account with DynDNS and it does some content filtering for me)
b) DNS Forwarder settings, are you putting extra hosts in Host Overrides, and/or do you have Domain Overrides to point queries for your local domain names to an internal DNS server?
c) What is the internal DNS server? Does it do special stuff when it does not know a name? (e.g. returns the address of your default web site?) -
Tell us more about your DNS settings, because that is not the normal behavior.
a) DNS servers in System->General Setup (and anything special they are doing - e.g. I have an account with DynDNS and it does some content filtering for me)
b) DNS Forwarder settings, are you putting extra hosts in Host Overrides, and/or do you have Domain Overrides to point queries for your local domain names to an internal DNS server?
c) What is the internal DNS server? Does it do special stuff when it does not know a name? (e.g. returns the address of your default web site?)a) We're using our company website for the domain name, and currently using google's DNS addresses for two default DNS servers. DNS list override is enabled. "Do not use the DNS Forwarder as a DNS server for the firewall" is not checked.
b) I haven't changed a thing in the DNS forwarder settings (running version 2.1 of pfsense) except I've added a few host overrides for static IPv4 maps, though I noticed this "issue" before ever adding those. But here's a run down:
"Enable DNS forwarder" - Checked
"Register DHCP leases in DNS forwarder" - Checked
"Register DHCP static mappings in DNS forwarder" Not checked, but thinking about it, maybe I should?
"Resolve DHCP mappings first" Not Checked
"Query DNS servers sequentially" Not Checked
"Require domain" Not checked (I thought this might fix it, but made no difference)
"Do not forward private reverse lookups" Not Checked
"Listen Port" Empty
"Strict Interface Binding" Not CheckedAdvanced I haven't touched at all.
c) Currently when the DNS can't resolve an address (like say you went to hhtp://www.rgrgrgsdferfr.com) it goes to our website, that I'm using as the domain name. The reason we use our website for the domain is so that I can easily access registered static DNS maps in a logical fashion. I like the idea of being able to tell non-tech people that they can point their browser to: wiki.ourcompanywebsite.com and they'll get our internal wiki.
I've been told by our web admin that it's possibly due to the fact that we have a wildcard subdomain, which obviously we're not going to fuss with in order to fix internal routing issues.
-
Hmmm - I am struggling to think how pfSense can be injecting that sort of redirection.
If you do Diagnostics->DNS Lookup on pfSense, and put a rubbish name, do you get a NXDOMAIN answer?
From a client, "nslookup www.sdvhibvzdfvdfv.com" - do you get NXDOMAIN? Or the IP address of your web site?You could also use a sub-domain of your real domain for your pfSense and thus for internal clients - office1.mydomain.com - all my pfSense have names like that.
-
I've attached screen shots of a DNS lookup on pfsense, as well as a client. I've blocked the view of our domain name (sorry, trying to stay anonymous) and I've blocked half of our IP, so you can at least see where it shows our domain versus IP address.
I'm betting that even if I set our domain on pfsense to a subdomain that I'd still run into this problem. Reason being, if I try to go to office1.ourdomain.com I'm going to get sent to ourdomain.com since "office1" doesn't exist. If I go to networkappliance.office1.ourdomain.com the same thing will happen, provided there's not a real device there attached to that address.
I'll have to wait until this weekend to test it our though, which will be good since I'm doing some other updates to our DHCP structure.
-
OK - I think I understand the sequence of events on the client:
- Client has a name like client1.thisdomain.com
- thisdomain.com has a wildcard *.thisdomain.com going to www.thisdomain.com
- Client does nslookup for www.rubbishrandomname.com and nslookup first looks for "www.rubbishrandomname.com." and gets NXDOMAIN.
- Client nslookup now decides to try appending its own domain name, so looks for "www.rubbishrandomname.com.thisdomain.com." - because of the wildcard domain entry it returns the address of www.thisdomain.com
and how do you get around that? You probably want the behavior at step (4) so people can use short names like "client2" and it will lookup "client2.thisdomain.com".
Suggestions from others welcome! -
If at step 4, the user HAD to use the correct name, it wouldn't be the end of the world. I'll just have to make that clear in our documentation.
It's less trouble to tell people to use the correct address then it is to explain to people why they're getting redirected to our own website when they spell a website wrong… First world IT problems much?
Thank you for your time thus far. Rest assured it is indeed appreciated.
-
Also to be clear, I don't even know how to just stop the DNS lookup at the end of step 3. That alone would be a step in the right direction for me.
-
So I would think the better solution would be to have whatever your dns for your local domains/suffix search order not return wildcards.
Now not sure what the browser might do, but from just a simple nslookup in debug mode you can see that it adds suffixs in the first search even.
so I then edit the ipv4 properties advanced, dns to only append the listed suffix and just put a ., it won't let you leave it blank
I then did another nslookup in debug mode and did not see it query for any suffix, only what I did the query for. This could break your normal name resolution process for things like AD? Not sure - but this is one way to get the client from stop adding suffix to their dns queries - you would have to validate that browser adheres to these settings as well. Or there might be a way to just get the browser not to append your machines suffix, etc. For example I did a quick sniff with my firefox browser and I did not see it append my local domain to any dns queries.
-
I've been told by our web admin that it's possibly due to the fact that we have a wildcard subdomain, which obviously we're not going to fuss with in order to fix internal routing issues.
Well, that is
- obvious cause of the problem
- very wrong practice
- and the only thing that needs to be fixed
So… you are messing with completely wrong part of your DNS infrastructure. There really are no "internal routing issues."
-
Pardon my ignorance, but what's wrong about using a wildcard on our domain? We want people on the net to get redirected to our main site, should the type an incorrect URL with our domain name.
Now, if you're saying that we shouldn't be using our main web domain name for our local network, well that's a conversation we can have. Ideas? Should we switch to a variant of our company name and keep things totally separated?
I'm open to suggestions.
-
So configure your internal DNS without the wildcard. This whole thing is completely unrelated to pfSense.
-
^ Agreed if you want to help the 2 users on the planet that type ww.yorudomain.com and can not figure out what they did wrong when they don't get an answer, etc. Then sure ok use a wildcard on the public side - what does that have to do with your internet view of your domain. Which why it would match up and want to resolve public IPs another question. Do the machines these fqdns resolve to only have public IPs - they are not on a rfc1918 IP at all? If they are on rfc1918 space why would you not have your internal clients resolve those IPs for the sites they want to access?
-
What's particularly bizarre - you yourself do not like what you are doing to others.
I just don't like that when a user puts in an address that doesn't exist that they get forwarded to our website… I'd much rather they go to an error page.
vs.
We want people on the net to get redirected to our main site, should the type an incorrect URL with our domain name.
::)
P.S. Recall the Verisign TLD wildcard fiasco?
-
The problem is that dnsmasq forwards the appended name out to your external DNS which will wildcard to your website. Go into your pfsense dns forwarder settings and add a domain override at the very bottom. Use "!" so it doesn't forward anywhere.
You really should take a look at the resolver log. You will see exactly what happens. Add log-queries to the advanced dnsmasq options to get more verbose output in the resolver log.
Forwarding no override
Feb 22 17:25:00 dnsmasq[93889]: reply www.efrgthyhyjuyjk.com is NXDOMAIN-IPv6 Feb 22 17:25:00 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com to 8.8.4.4 Feb 22 17:25:00 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com to 8.8.8.8 Feb 22 17:25:00 dnsmasq[93889]: query[AAAA] www.efrgthyhyjuyjk.com from 192.168.55.101 Feb 22 17:25:00 dnsmasq[93889]: reply www.efrgthyhyjuyjk.com is NXDOMAIN-IPv4 Feb 22 17:25:00 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com to 8.8.4.4 Feb 22 17:25:00 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com to 8.8.8.8 Feb 22 17:25:00 dnsmasq[93889]: query[A] www.efrgthyhyjuyjk.com from 192.168.55.101 Feb 22 17:25:00 dnsmasq[93889]: reply www.efrgthyhyjuyjk.com.localdomain is NXDOMAIN-IPv6 Feb 22 17:24:59 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com.localdomain to 8.8.4.4 Feb 22 17:24:59 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com.localdomain to 8.8.8.8 Feb 22 17:24:59 dnsmasq[93889]: query[AAAA] www.efrgthyhyjuyjk.com.localdomain from 192.168.55.101 Feb 22 17:24:59 dnsmasq[93889]: reply www.efrgthyhyjuyjk.com.localdomain is NXDOMAIN-IPv4 Feb 22 17:24:59 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com.localdomain to 8.8.4.4 Feb 22 17:24:59 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com.localdomain to 8.8.8.8 Feb 22 17:24:59 dnsmasq[93889]: query[A] www.efrgthyhyjuyjk.com.localdomain from 192.168.55.101
Not fowarding with override enabled
Feb 22 17:19:05 dnsmasq[6833]: reply www.efrgthyhyjuyjk.com is NXDOMAIN-IPv6 Feb 22 17:19:05 dnsmasq[6833]: forwarded www.efrgthyhyjuyjk.com to 8.8.4.4 Feb 22 17:19:05 dnsmasq[6833]: forwarded www.efrgthyhyjuyjk.com to 8.8.8.8 Feb 22 17:19:05 dnsmasq[6833]: query[AAAA] www.efrgthyhyjuyjk.com from 192.168.55.101 Feb 22 17:19:05 dnsmasq[6833]: reply www.efrgthyhyjuyjk.com is NXDOMAIN-IPv4 Feb 22 17:19:05 dnsmasq[6833]: forwarded www.efrgthyhyjuyjk.com to 8.8.4.4 Feb 22 17:19:05 dnsmasq[6833]: forwarded www.efrgthyhyjuyjk.com to 8.8.8.8 Feb 22 17:19:05 dnsmasq[6833]: query[A] www.efrgthyhyjuyjk.com from 192.168.55.101
Dnsmasq is quite simple it basically looks at manual entries and dhcp information. Everything else is forwarded externally for a lookup. If you want a real DNS server you could try the BIND package or spinning up a separate VM and running bind.
![2014-02-22 17_34_56-pfsense.localdomain - Services_ DNS forwarder_ Edit Domain Override.png](/public/imported_attachments/1/2014-02-22 17_34_56-pfsense.localdomain - Services_ DNS forwarder_ Edit Domain Override.png)
![2014-02-22 17_34_56-pfsense.localdomain - Services_ DNS forwarder_ Edit Domain Override.png_thumb](/public/imported_attachments/1/2014-02-22 17_34_56-pfsense.localdomain - Services_ DNS forwarder_ Edit Domain Override.png_thumb)
![2014-02-22 17_36_57-pfsense.localdomain - Services_ DNS forwarder.png](/public/imported_attachments/1/2014-02-22 17_36_57-pfsense.localdomain - Services_ DNS forwarder.png)
![2014-02-22 17_36_57-pfsense.localdomain - Services_ DNS forwarder.png_thumb](/public/imported_attachments/1/2014-02-22 17_36_57-pfsense.localdomain - Services_ DNS forwarder.png_thumb) -
Thank you for the info bryan. You certainly got me pointed in the right direction.
I've gotten my config operating the way I wanted, and without having to change anything on our domain, which would also effect our public side, which I have no personal responsibilities for at my work.
Adding a domain override did NOT work unfortunately, as it seems pfsense still sends out your local domain as a search domain to clients. I found that if I entered a domain without a wildcard configuration under the optional "search domains" under the DHCP server page then invalid domain entries returned a not found reply.
It's quite obvious that pfsense is still polling locally because I can not only access my manual host entries, but even ones that I haven't directly forwarded. For example:
appliance1.ourdomain.com is registered to 192.x.x.x and you can access it perfectly via hostname instead of IP
appliance2.ourdomain.com is only configured on the device, not in pfsense, and is able to be accessed perfectly via hostname instead of IPUnfortunately this means the internal clients HAVE to enter .ourdomain.com for hostname access to work, but that's better than where I was before, since very few of us will be accessing devices via hostname anyways, while many more in the company will be typing invalid URL's.
-
Thank you for the info bryan. You certainly got me pointed in the right direction.
I've gotten my config operating the way I wanted, and without having to change anything on our domain, which would also effect our public side, which I have no personal responsibilities for at my work.
Adding a domain override did NOT work unfortunately, as it seems pfsense still sends out your local domain as a search domain to clients. I found that if I entered a domain without a wildcard configuration under the optional "search domains" under the DHCP server page then invalid domain entries returned a not found reply.
It's quite obvious that pfsense is still polling locally because I can not only access my manual host entries, but even ones that I haven't directly forwarded. For example:
appliance1.ourdomain.com is registered to 192.x.x.x and you can access it perfectly via hostname instead of IP
appliance2.ourdomain.com is only configured on the device, not in pfsense, and is able to be accessed perfectly via hostname instead of IPUnfortunately this means the internal clients HAVE to enter .ourdomain.com for hostname access to work, but that's better than where I was before, since very few of us will be accessing devices via hostname anyways, while many more in the company will be typing invalid URL's.
I think there is a lack of a clarity surrounding exactly what you want to be happening.
Who do you want to get wildcarded: People inside your network or people on the internet?
-
Q: What do I want to get wildcarded?
A: Just people on the internet, accessing our website.I didn't setup the wildcard, I only setup and manage internal hardware and software. We have a web department that manages our domain (company website).
It would seem silly to NOT use our domain (company website) as the domain for our internal network though. Hence the conflict of interest regarding the wildcard.
-
Do you have a wildcard subdomain setup on pfsense?
Nope. The only place anything related to our company's website is entered is as the domain name under System->General Setup. The wildcard "issue" only comes into play when pfsense starts searching our domain name for name resolution, and our website hands back a response to forward the client to the company website.
If I changed the domain in pfsense to ourcompany minus ".com" or to something else entirely, then the "issue" i'm having would be resolved. But as I stated, the issue is resolved for the most part just by specifying a search domain for the DHCP server.
-
Do you have a wildcard subdomain setup on pfsense?
Nope. The only place anything related to our company's website is entered is as the domain name under System->General Setup. The wildcard "issue" only comes into play when pfsense starts searching our domain name for name resolution, and our website hands back a response to forward the client to the company website.
If I changed the domain in pfsense to ourcompany minus ".com" or to something else entirely, then the "issue" i'm having would be resolved. But as I stated, the issue is resolved for the most part just by specifying a search domain for the DHCP server.
Deleted my previous post.
-
Remove your domain from the search list in the DHCP. It is already set as the domain for the dhcp. You can verify by doing ps aux | grep dhcp and expanding the window you will see "-d yourdomainhere"
-
Please go check your resolver log and do a nslookup for some garbage hostname. Please grab this information and replace your real domain and IP with something else. Please get the queries and the replies. Post it here like the example below in codeblock.
-
How did you setup your domain override? Are you sure you set it up right. As you can see in my other post the domain override clearly stops lookup for that domain on the external dns servers I have set in General Settings. Which is exactly what you need to stop everything not resolvable internally getting appending and resolving to your website
-
If you setup the domain override again with the correct "!" so traffic for that domain is not forwarded anywhere. Please look at the resolver log again and post output as well. You should not see anything.yourdomain in any queries going to googles dns servers. I have attached the picture from my previous post. Please note that you may need to add a host override for your website internally as you will be blocking that from resolving from the public DNS.
Feb 22 17:25:00 dnsmasq[93889]: reply www.efrgthyhyjuyjk.com is NXDOMAIN-IPv6 Feb 22 17:25:00 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com to 8.8.4.4 Feb 22 17:25:00 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com to 8.8.8.8 Feb 22 17:25:00 dnsmasq[93889]: query[AAAA] www.efrgthyhyjuyjk.com from 192.168.55.101 Feb 22 17:25:00 dnsmasq[93889]: reply www.efrgthyhyjuyjk.com is NXDOMAIN-IPv4 Feb 22 17:25:00 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com to 8.8.4.4 Feb 22 17:25:00 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com to 8.8.8.8 Feb 22 17:25:00 dnsmasq[93889]: query[A] www.efrgthyhyjuyjk.com from 192.168.55.101 Feb 22 17:25:00 dnsmasq[93889]: reply www.efrgthyhyjuyjk.com.localdomain is NXDOMAIN-IPv6 Feb 22 17:24:59 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com.localdomain to 8.8.4.4 Feb 22 17:24:59 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com.localdomain to 8.8.8.8 Feb 22 17:24:59 dnsmasq[93889]: query[AAAA] www.efrgthyhyjuyjk.com.localdomain from 192.168.55.101 Feb 22 17:24:59 dnsmasq[93889]: reply www.efrgthyhyjuyjk.com.localdomain is NXDOMAIN-IPv4 Feb 22 17:24:59 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com.localdomain to 8.8.4.4 Feb 22 17:24:59 dnsmasq[93889]: forwarded www.efrgthyhyjuyjk.com.localdomain to 8.8.8.8 Feb 22 17:24:59 dnsmasq[93889]: query[A] www.efrgthyhyjuyjk.com.localdomain from 192.168.55.101
![2014-02-22 17_34_56-pfsense.localdomain - Services_ DNS forwarder_ Edit Domain Override.png](/public/imported_attachments/1/2014-02-22 17_34_56-pfsense.localdomain - Services_ DNS forwarder_ Edit Domain Override.png)
![2014-02-22 17_34_56-pfsense.localdomain - Services_ DNS forwarder_ Edit Domain Override.png_thumb](/public/imported_attachments/1/2014-02-22 17_34_56-pfsense.localdomain - Services_ DNS forwarder_ Edit Domain Override.png_thumb) -