Reverse DNS Lookups
-
Morning all,
Im having a few issues with Pf in regards to reverse DNS lookups.
We have a variety of PF's setup around our network for different purposes, all running at least 2.2.0 and most on 2.2.4.
All are set to ignore their own DNS server and prefer our internal ones (MS DNS servers).However despite the fact that every other device on our networks, be them Windows machines, switches, ect; will do lookups either fully qualified or not, or reverse lookup, NONE of the Pfs will do so.
I've tried every possible combination of DNS resolver, forwarder, local dns setting, ect; i can think of to resolve this issue but it simply will not work. Am i missing something obvious?To be clear:
works:
Fully qualified computer name (computer1.domain.com)doesnt work:
computer name (computer1)
IP address (1.2.3.4)Thanks in advance.
-
This doesn't sound like a 'reverse DNS' issue so much as a wrongly set domain name setting. Under System/General Setup, have you set the correct local domain name for your internal network?
-
Morning,
Yes, the local domain name is set as it should be.Perhaps this is two issues then, both a reverse DNS issue (as reversing the IP address doesn't work, so thus packages that need DNS lookups for logging only displays IP addresses) & a non-FQDN lookup issue.
Thanks.
-
Failing to resolve a non-fqdn implies a misconfiguration on either the DNS server or the host making the query. What does the /etc/hosts file show on your pfSense boxes? Is there a fqdn entry for the firewall in each case?
-
Its not the DNS Servers themselves. As said the rest of the domain + a multitude of non-windows devices work 100% fine.
Regarding the host file, on one of the systems it reads as:
127.0.0.1 localhost localhost.domain.com
::1 localhost localhost.domain.com
1.2.3.4 firewallname.domain.com firewallnameBut as said, this affects 7-8 PF boxes, none of which have custom host files, and 1 of which is a new install as of this week.
-
huh? pfsense provides ptr just fine using dnsmasq or unbound.. And has no issues resolving external ptr records either.
C:>dig -x 192.168.9.100
; <<>> DiG 9.10.3rc1 <<>> -x 192.168.9.100
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51546
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;100.9.168.192.in-addr.arpa. IN PTR;; ANSWER SECTION:
100.9.168.192.in-addr.arpa. 3600 IN PTR i5-w7.local.lan.;; Query time: 1 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Thu Oct 01 08:07:18 Central Daylight Time 2015
;; MSG SIZE rcvd: 84C:>dig -x 216.58.216.110
; <<>> DiG 9.10.3rc1 <<>> -x 216.58.216.110
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48659
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;110.216.58.216.in-addr.arpa. IN PTR;; ANSWER SECTION:
110.216.58.216.in-addr.arpa. 86014 IN PTR ord30s22-in-f14.1e100.net.
110.216.58.216.in-addr.arpa. 86014 IN PTR ord30s22-in-f110.1e100.net.
110.216.58.216.in-addr.arpa. 86014 IN PTR ord30s22-in-f14.1e100.net.
110.216.58.216.in-addr.arpa. 86014 IN PTR ord30s22-in-f110.1e100.net.;; Query time: 1 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Thu Oct 01 08:07:43 Central Daylight Time 2015
;; MSG SIZE rcvd: 154Not sure what your issue is since you have not really given any details.
looking up just a host name is not a reverse?? And that works too
C:>dig i5-w7
; <<>> DiG 9.10.3rc1 <<>> i5-w7
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7717
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;i5-w7. IN A;; ANSWER SECTION:
i5-w7. 3600 IN A 192.168.9.100;; Query time: 1 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Thu Oct 01 08:09:09 Central Daylight Time 2015
;; MSG SIZE rcvd: 50C:>
-
However despite the fact that every other device on our networks, be them Windows machines, switches, ect; will do lookups either fully qualified or not, or reverse lookup, NONE of the Pfs will do so.
So, going back to basics, what are you trying to do exactly? How do you know the firewalls can't lookup internal hosts? Are you running an nslookup or dig from the command line? And what is your ultimate aim in getting the pfSenses to perform non-fqdn lookups?
-
ok, im just testing at the moment, but i "think" ive solved the reverse lookups, although the fqdn vs non-fqdn fault still exists.
Will report back in the morning once the changes have propagated globally… -
"Will report back in the morning once the changes have propagated globally"
dns changes do not "propagate" the ttls expire.. Why don't you just query your authoritative ns, ie the SOA directly - does it work. Then what was the ttl on record you changed, and that would be the longest it should take anywhere on the planet to see that change.
-
Actually they do, when its a AD integrated zone in use. ;-)
With the issue on every Pf globally on our network, and there being several subnets with zones stored in AD, the AD needs to replicate to every DC in the forest and/or domain for the settings to get everywhere.
The records can have a TTL yes, but the zone information and cross-site knowledge of said zones is dependant on the AD replication times.Initial results look good however at this point as 2 of the affected sites appear to be fixed.
The non FQDN names still don't resolve, which would be nice to solve too, but later tomorrow on one of our user firewalls i should be able to see if LightSquid generates a report with DNS names, if so, then the non-FQDN resolutions are moot.
-
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.
