Reverse DNS Lookups

boomam

Logic dictates no such thing..

I disagree completely on that point.
If everything else works and PF does not, then how does logic point at anything other than PF being at fault? ???

I really don't get why you think pfsense has any thing to do with your clients doing queries to your MS dns

At no point have i said this.
This is about PF's inability to resolve a non-FQDN name, something which other systems on our network does without issue, whatever the OS or device may be.

Again how and the F do you think that is going to happen??

This thread has run its course i think based on your apparent frustration at entertaining any idea of PF perhaps being at fault or having a bug.
Lightsquid is resolving correctly it seems so reports run fine, the non-FQDN thing i can live with as its moot.
Thanks for the hints, the direction was food for thought and probably helped the self-diagnosis at some level.

johnpoz

If you believe pfsense can not resolve a fqdn that is clearly there.. Then why not show this happening, it would take all of about 30 seconds to show a sniff of pfsense sending its query that is fq and mangled or wrong in such a way to not get an answer.. while a query from a client works..

What seems clear is your not providing any sort of actual details to your issue.. Other than saying your clients resolve single label and or host without .domain.tld (fqdn).. For all we know they are broadcasting for this resolution and no pfsense is not going to do that. Do you have wins in your environment?? Or just using globalnames setup in your MS dns?? Pfsense sure not going to query wins.

How exactly are you trying to resolve PTR in pfsense? For example from a 30 second test there seems to be an issue in the dns lookup webgui tool.. I set one of the dns servers for pfsense to be my 2k8r2 box running dns. And while it can resolve my host.test.tld, when I put in an IP it is sending an A record query vs a correctly formatted PTR query.. So yeah that would not work.. Is this the issue your having? This took all of 30 seconds to validate and now document exactly what the problem is.

Now if your clicking the little i in your firewall log to resolve an IP.. This works correctly.. So I picked an IP in my log, I then setup 2k8r2 dns box to own that reverse zone 177.195.123, I create a testptr.test.tld A record in my test.tld zone, I had it update the PTR zone.. And as you can see when I disable pfsense from asking public internet for that actual true owner of that network.. And ask my MS dns it resolves to what I put in there for that.

So what exactly is your so called issue? Post up exactly what pfsense is or is not doing that you feel is wrong.. For example I will bring up a thread or submit a bug report that the dns lookup web gui is not looking up IPs correctly with a PTR but just a A record.. While pfsense dnsmasq or unbound might resolve that.. That is not a actual valid query for a PTR. So that should actually be corrected.

Now if I want pfsense to resolve a single label query.. Do you have GlobalNames setup on your MS dns with the cnames pointing to the fqdn you want to resolve using singlelabel. Post this information, so a sniff of client sending just a single label query and it resolving and then pfsense sending same query and it not resolving.

But you clearly need to post what your issue is other than just blaming it on pfsense.. Especially when actual documentation of the problem normally only takes a couple of minutes.. So everyone is not making GUESSES to what you think the problem is.

Without a GlobalNames zone setup, MS dns is NOT going to resolve a single label query.. Its just NOT - plain and simple..

edit: Ok so I took some time to play around with globalnames in ms dns.. And atleast in 2k8r2 is pretty much freaking useless for this sort of thing and doesn't seem to live up to the description.

The GlobalNames Zone (GNZ) is used to hold single-label names. The GlobalNames zone is intended to provide single-label name resolution for a limited set of host names, typically corporate servers and web sites that are centrally managed. The GlobalNames zone is most commonly used to hold CNAME resource records to map a single-label name to a Fully Qualified Domain Name (FQDN). GlobalNames Zone functionality is not intended to fully replace WINS. GNZ provides single-label name resolution whereas WINS provides NetBIOS resolution.

But what I have found with playing with it you still have to send a FQDN in the query.. now the record does not have to be in that zone.. But sending singlelabel does not function..

So created new zone on my 2k8r2 dns local.lan, in this zone I put A record for host.local.lan that has ip of 5.6.7.8

There is no host.test.tld record.. So in the new attached you can see that there is a record in local.lan for host, and there is cname in globalnames for host that points to host.local.lan

Now look at the actual dns queries from nslookups, when I send query for just true single label host. it Fails!!! But if I query a zone that is on the server that there is not record for host for.. It returns the entry that is in globalnames zone..

So your NEVER going to get this to work from my quick testing.. So I would suggest actually sniff on your hosts that are working - they must be sending a fqdn query that actually resolves, and not some single label query

issuednslookup.png_thumb

correctptr.png_thumb

msdnsglobalnameshowworks.png_thumb

nslookups.png_thumb

NOYB

@boomam:

This thread has run its course i think based on your apparent frustration at entertaining any idea of PF perhaps being at fault or having a bug.

Or perhaps due to your apparent unwillingness to follow the suggested troubleshooting steps for diagnosis. i.e. packet capture / network sniff.

cmb

So the clients are resolving fine, it's just queries from the firewall itself that don't work unless they're FQDNs? In that case, either the domain under System>General Setup is wrong, or it's not getting replies from its configured DNS server(s).

When you do a DNS lookup from the firewall, it'll append the default domain and do a lookup on that name. If that fails, it'll do a lookup for the hostname minus the domain. Where my domain under System>General Setup is buechler.lan, and I run "ping blah":

21:53:19.946424 IP 10.0.4.2.8205 > 10.0.4.50.53: 4148+ A? blah.buechler.lan. (35)
21:53:19.946803 IP 10.0.4.50.53 > 10.0.4.2.8205: 4148 NXDomain* 0/1/0 (110)
21:53:19.947549 IP 10.0.4.2.60216 > 10.0.4.50.53: 17090+ A? blah. (22)
21:53:19.947826 IP 10.0.4.50.53 > 10.0.4.2.60216: 17090 NXDomain* 0/1/0 (97)

where 10.0.4.50 is the configured DNS server.

NOYB

Here we are trying to get Booman to troubleshoot the issue and CMB is giving away the answers to the test so to speak. ;)

cmb

@NOYB:

Here we are trying to get Booman to troubleshoot the issue and CMB is giving away the answers to the test so to speak. ;)

Well, he's still gonna have to troubleshoot the issue, just showing how things work. :)

johnpoz

This poster is unwilling to think his problem through and just wants to blame pfsense.. Or take the 30 seconds it would take to actually see what is happening via a sniff.. I hate these sorts of users to be honest.. But you can not make the horse drink even when you shove the bucket a water over its mouth..

Yes I use the term user, admins atleast good/decent ones do not think like this nor are they unwilling to provide info either proving their train of thought results or showing how they got to this train of though to what they think the problem is. Users expect someone to fix their problem without providing any sort of details to help..

User: My car won't start
Tech: Does it have gas?
User: It wont start!
Tech: Does it turn over, does it make a noise - does it have gas?
User: It wont start! Its blue and the tires have air.
Tech: <rolleyes> Get a new car ;)

BTW I have not seen the web gui dns lookup act this way.. if your doing it from cmd line on pfsense sure. But the webgui dns lookup does not seem to add your pfsense domain to the query. Which we don't even know what the user is even doing from pfsense to try and resolve??</rolleyes>

boomam

@cmb:

@NOYB:

Here we are trying to get Booman to troubleshoot the issue and CMB is giving away the answers to the test so to speak. ;)

Well, he's still gonna have to troubleshoot the issue, just showing how things work. :)

Nothing to troubleshoot, as said, i've solved the issue already. :)

@johnpoz:

This poster is unwilling to think his problem through and just wants to blame pfsense.. Or take the 30 seconds it would take to actually see what is happening via a sniff.. I hate these sorts of users to be honest.. But you can not make the horse drink even when you shove the bucket a water over its mouth..

Yes I use the term user, admins atleast good/decent ones do not think like this nor are they unwilling to provide info either proving their train of thought results or showing how they got to this train of though to what they think the problem is. Users expect someone to fix their problem without providing any sort of details to help..

You really do have an attitude problem.
The issue from a community point of view is the stout defence of Pf that blinds you from the same thing your accusing me of.
Do not make assumptions on people just because you disagree. My theory proved correct and it was solved.
As said, i thank you for the points of view given as whilst they did not ultimately point me in the correct direction for resolution they at least gave me food for thought. Its often useful to bounce ideas to get the create juices flowing. :)

timboau

This had been irking me for some time as well….

After doing some packet capture I noticed that the request wasn't being passed to the MS DNS Server.

it seems that the DNS resolver was happy to answer the request (unsuccessfully) - as illustrated by the DNS lookup tool 127.0.0.1

I simply turned off the DNS Resolver built into pfsesne and all sprun to life.

johnpoz

What has been irking you?? Not having a clue to how dns works… Yeah that would irk the shit out of me too to the point I would actually learn how it works..