Unresolvable DNS Entries
-
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.101Not 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.101Dnsmasq 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.
 -
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
 -
-
The good news is that it seems like the domain override worked this time. I did it exactly as I did last time, but now I'm wondering if I didn't give it enough time after restarting the forwarder service and renewing my DHCP lease or something. All I know is that I changed the settings, verified I didn't break the network, and then had to head into a meeting. Came out of the meeting, and now it's working properly.
And to reiterated/clarify:
Under general settings I have "ourwebsite.com" and under DHCP there's no search domain specified, but under DNS Forwarder there's a Domain override with "localdomain" for the domain field, and "!" for the IP field.
And of course, I can still access my appliances via hostname. Lovely.
Here's my log, and man this can be tough to hunt down when you've got so much traffic going on. Thanks for the help though. I'm not 100% positive I found all the relative lines to this one request, as it was spread accross about 50 lines, but I think that's all of it.
Feb 24 15:03:50 dnsmasq[87210]: reply www.qwwersdfretdfg.com is NXDOMAIN-IPv4 Feb 24 15:03:50 dnsmasq[87210]: forwarded www.qwwersdfretdfg.com to 8.8.8.8 Feb 24 15:03:50 dnsmasq[87210]: query[A] www.qwwersdfretdfg.com from 192.168.16.19 Feb 24 15:03:50 dnsmasq[87210]: reply qwwersdfretdfg.com is NXDOMAIN-IPv4 Feb 24 15:03:50 dnsmasq[87210]: forwarded qwwersdfretdfg.com to 8.8.8.8 Feb 24 15:03:50 dnsmasq[87210]: query[A] qwwersdfretdfg.com from 192.168.16.19 -
The good news is that it seems like the domain override worked this time. I did it exactly as I did last time, but now I'm wondering if I didn't give it enough time after restarting the forwarder service and renewing my DHCP lease or something. All I know is that I changed the settings, verified I didn't break the network, and then had to head into a meeting. Came out of the meeting, and now it's working properly.
And to reiterated/clarify:
Under general settings I have "ourwebsite.com" and under DHCP there's no search domain specified, but under DNS Forwarder there's a Domain override with "localdomain" for the domain field, and "!" for the IP field.
And of course, I can still access my appliances via hostname. Lovely.
Here's my log, and man this can be tough to hunt down when you've got so much traffic going on. Thanks for the help though. I'm not 100% positive I found all the relative lines to this one request, as it was spread accross about 50 lines, but I think that's all of it.
Feb 24 15:03:50 dnsmasq[87210]: reply www.qwwersdfretdfg.com is NXDOMAIN-IPv4 Feb 24 15:03:50 dnsmasq[87210]: forwarded www.qwwersdfretdfg.com to 8.8.8.8 Feb 24 15:03:50 dnsmasq[87210]: query[A] www.qwwersdfretdfg.com from 192.168.16.19 Feb 24 15:03:50 dnsmasq[87210]: reply qwwersdfretdfg.com is NXDOMAIN-IPv4 Feb 24 15:03:50 dnsmasq[87210]: forwarded qwwersdfretdfg.com to 8.8.8.8 Feb 24 15:03:50 dnsmasq[87210]: query[A] qwwersdfretdfg.com from 192.168.16.19Yeah that looks about right. Glad you got it working. It could have been cached dns on your client. On windows you can ipconfig -flushdns. You can access your website still properly?
-
Yea, I'm on OSX and hadn't done a true flush, just a DHCP renew. Probably was the problem the first go around, since I don't specifically remember changing the URL.
And yes, we can still access our site internally, even the legitimate wildcards. An invalid wildcard turns up our website too, exactly as it would for people on the outside of our network.
Thanks so much for the help! Time to backup the config again…
-
Adding a domain over-ride with IP of "!" solved this problem for me… I wonder how common it is for new users. Seems like a good tip for FAQ if it doesn't already exist.
