Reverse DNS Lookups
-
Well what is your replication schedule, what is integrated zone reload time. You can can force replication if you wanted too.
Simple repadmin /syncall /APed should make sure its everything really quickly!
-
I'm aware, but i'm fine waiting till morning. :)
Any ideas on the non-FQDN resolution fault?
-
Any ideas on the non-FQDN resolution fault?
You're assigning the wrong default domain to clients via DHCP (assuming they're DHCP clients, if static, must statically define default domain).
-
A packet capture should show what suffix is being added to the non-fqdn requests.
-
Not sure I understand where you want to get a non-fqdn query answered.. Seems you don't have they hosts defined in pfsense. But in some AD dns.. So how would a query to pfsense dns that gets forwarded to your AD dns without being fqdn resolve to anything?
Your clients in doing the query should add whatever search suffixes you want to use, and then the client would query walking through all the suffixes and up the tree until they get a response or don't get a response.
lets say you have domain.tld, and some sub domains sitea.domain.tld and siteb.domain.tld
You would have your clients search suffix go through sitea.domain.tld, siteb.domain.tld and then domain.tld etc..
What pfsense does by responding to hosts. isn't really part of dns - but just that it has that host with . or root in the host file so when you query for just host. you get an answer. I could fire up my windows dns and do some testing but if you have a A record for host.sitea.domain.tld and you just ask for host. I don't think its going to respond.
You need to get your clients to ask for host.sitea.domain.tld if you want to look up host.sitea.domain.tld
edit: yup just fired up dns server on 2k8r2 and if you just ask it for host. you get a servfail back - which makes complete sense because you don't have an A record for host. you have a A record for host.domain.tld
-
@cmb:
You're assigning the wrong default domain to clients via DHCP (assuming they're DHCP clients, if static, must statically define default domain).
Nope. The DHCP clients get the correct domain.
Not sure I understand where you want to get a non-fqdn query answered….
I know how DNS resolution works. As said from the beginning, other hosts, firewalls, clients, devices, servers, ect; do not have this issue at all. Based on this, logic dictates the issue with PF as its only PF with the issue. The none PF services, with all types of lookups, work correctly both forward and reverse, and non-FQDN.
To prove out further: If i fire up a test CentOS machine and do a lookup on just a hostname, it resolves to a FQDN. If i do a reverse lookup, it gets me the name too.Now, some changes to some routing has corrected the reverse lookup, however the diagnostic page on Pf still doesn't resolve a non-FQDN host name - as said, nothing else, whatever the OS, has this issue.
Looking at what lightsquid is spitting out, its now giving me the hostnames for clients, so the issue is now moot now that the client names come through correctly. -
Logic dictates no such thing..
If your saying your clients resolve single label queries or just hostname, then you have wins enabled in your MS dns? Or you have enabled globalnames? DNS will not return and resource that is not a FQDN query unless your using WINS or have enabled globalnames zone. But if your so sure suffix is being used, and there are records in that zone why don't you just sniff and see??
I really don't get why you think pfsense has any thing to do with your clients doing queries to your MS dns???? Or what is returned if pfsense itself does a dns query.. is the query fqdn or not - pfsense is not going to add a search suffix that I am aware of.
"Pf still doesn't resolve a non-FQDN host name"
Again how and the F do you think that is going to happen?? MS DNS does not resolve host. it needs host.something you don't have any records in . If you what you could do is set your dns to query WINS or have a globalnames zone. There it can lookup just host names with the domain.
-
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. -
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
-
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.
-
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.
-
Here we are trying to get Booman to troubleshoot the issue and CMB is giving away the answers to the test so to speak. ;)
-
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. :)
-
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>
-
@cmb:
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. :)
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. :) -
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.
-
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..
