DNS Lookup wrong
-
@johnpoz DNS Lookup appending .local in background?
-
@johnpoz said in DNS Lookup wrong:
So your creating a host override just filling in the domain and leaving host empty??
That is just freaking BORKED!
Then what should it be if just directing to a local host machine?
-
You should be using a fqdn.. host.domain or host.domain.tld even better.
Your local query is going to resolve like that because in hosts it gets put in like that
IP host.domain.tld host
Look in your /etc/hosts file
If your resolving something old - look to there for why..
But a query to unbound from a client will not resolve that.
-
I just discovered that "nslookup" adds a local domain (called "srchlist ") :
[2.4.4-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: nslookup > set all Default server: 127.0.0.1 Address: 127.0.0.1#53 Set options: novc nodebug nod2 search recurse timeout = 0 retry = 3 port = 53 ndots = 1 querytype = A class = IN srchlist = brit-hotel-fumel.netCorrect, " brit-hotel-fumel**.**net " is my pfSense domain.
Btw : I never use nslookup, I don't "like" it.
"dig" is far more powerful.IMHO : never ever us a GUI for this kind of testing. The console or SSH access is king here.
edit @generaluser88457 : what in your /etc/hosts file ?
-
yeah its quite possible for the os or some dns tools to add the search list set on the machine.. dig will not do that for sure unless you tell it too.
problem is the os domain could be set different then the domain your using in your dns, etc.
A host will not resolve via unbound, past version 2.3.3 I believe is when they fix the bad behavior.. You can tell if your os is adding the suffix if you get say this.
$ ping nas Pinging nas.local.lan [192.168.9.10] with 32 bytes of data: Reply from 192.168.9.10: bytes=32 time<1ms TTL=64See how I only asked for nas, but it came back fq.. if you watch the dns query go out for that... you will see what happens.
You can see only asked for nas in my ping command, but the dns query was actually fq.
-
@Gertjan said in DNS Lookup wrong:
I just discovered that "nslookup" adds a local domain (called "srchlist ") :
[2.4.4-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: nslookup > set all Default server: 127.0.0.1 Address: 127.0.0.1#53 Set options: novc nodebug nod2 search recurse timeout = 0 retry = 3 port = 53 ndots = 1 querytype = A class = IN srchlist = brit-hotel-fumel.netCorrect, " brit-hotel-fumel**.**net " is my pfSense domain.
Btw : I never use nslookup, I don't "like" it.
"dig" is far more powerful.IMHO : never ever us a GUI for this kind of testing. The console or SSH access is king here.
edit @generaluser88457 : what in your /etc/hosts file ?
I don't remember what the /etc/host looked like on pfSense. I've never had this issue before even if the setup as @johnpoz said is "just freaking BORKED!". It'd be good to know why (beyond speculation) the engineers behind pfsense decided to make " Domain"=required and "Host"= optional in the Host Overrides in the DNS Resolver. Most times I don't do this because i'm using it to resolve applications on the server like company.app1.com or office.maps.com that only work on the local network.
In the few instances I have taken advantage of this "just freaking BORKED!" setup, it resolved a connectivity issue with some old bad software needing to talk to a machine by name and would accept http://somename:port but not http://x.x.x.x:port or x.x.x.x:port and for some reason hostname resolution was not working for that machine. I have no idea why without it=problem, with it=no problem. For all I know it could have been temporary (like the issue i opened this thread for disappeared after the weekend).
Most times in a production environment, making something broken work can happen quickly with minimal knowledge about the tools available. Being an expert (at the same level as people who primarily spend their day only doing 1 part of the large IT stack) isn't practical since in most cases the wider the knowledge, the lower the understanding.
Finding the root problem or the "technically correct" solution often keeps everybody offline for much longer than is acceptable because knowing the "technically correct" solution or root problem often requires knowledge from previous experience or the ability to test and confirm theories. I often try for technically correct but if 50 people are out of work until i find a solution, 20min have gone by trying to make sure I take the action that can't be disputed in a forum, I implement something that works so everybody else can get back to work.
After everybody is back to work, I try as best I can to get a better understanding later but often without the customers network at my disposal for testing my theories. Even this issue i still do not understand.
The expert @johnpoz said
server-main1 is not even a fqdn... So that would never resolve in the first place... did you mean server-main1.something??
And yet I just put Domain = ppxtest and IP Address = 192.168.0.13 (picked a random ip to a machine that was online and hostname is not ppxtest) in pfSense 2.4.4-RELEASE-p2 running on official Netgate Netgate SG-3100 in DNS Resolver > Host Override and then went to another machine on the network and ran this:
$ dig ppxtest ; <<>> DiG 9.10.3-P4-Ubuntu <<>> ppxtest ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17614 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ppxtest. IN A ;; ANSWER SECTION: ppxtest. 3600 IN A 192.168.0.13 ;; Query time: 0 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Fri Apr 26 10:12:44 EDT 2019 ;; MSG SIZE rcvd: 52 $ ping ppxtest PING ppxtest (192.168.0.13) 56(84) bytes of data. 64 bytes from ppxtest (192.168.0.13): icmp_seq=1 ttl=128 time=0.604 ms 64 bytes from ppxtest (192.168.0.13): icmp_seq=2 ttl=128 time=0.440 ms 64 bytes from ppxtest (192.168.0.13): icmp_seq=3 ttl=128 time=0.491 ms 64 bytes from ppxtest (192.168.0.13): icmp_seq=4 ttl=128 time=0.566 ms 64 bytes from ppxtest (192.168.0.13): icmp_seq=5 ttl=128 time=0.637 ms # using @<dns server ip> $ dig @192.168.0.1 ppxtest ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @192.168.0.1 ppxtest ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23469 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ppxtest. IN A ;; ANSWER SECTION: ppxtest. 3600 IN A 192.168.0.13 ;; Query time: 0 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Fri Apr 26 10:41:45 EDT 2019 ;; MSG SIZE rcvd: 52I didn't edit any files on any of the other machines, all i did was do the "just freaking BORKED!" setup in pfSense as a test and it's resolving.
-
Back to :
@generaluser88457 said in DNS Lookup wrong:server name like "server-main1" it resolves to 192.168.5.125
@generaluser88457 said in DNS Lookup wrong:
I don't remember what the /etc/host looked like on pfSense
Me neither.
So typecat /etc/hostsIt could explain things...
-
@generaluser88457 said in DNS Lookup wrong:
official Netgate Netgate SG-3100 in DNS Resolver > Host Override
if you put pxxtest in your host override "domain" section then yes that would resolve!! We already freaking went over this did we not?
Dude I don't know what to tell you - trying to run dns with just "hostnames" Is BORKED!!! and yeah your going to run into all kinds of shit with shit like that.
If you want to allow for your hosts to just use hostnames, then correctly set up your search suffix to use the domain(s) you want to use and correctly setup dns to use fqdn for your entries!
-
/etc/hosts doesn't have any entries for that host or ip. But the issue from Friday is resolved so it's likely the file looked different then...which is why i said i don't remember what it looked like....the file no longer reflects what it did last Friday and the issue no longer exist.
-
@johnpoz said in DNS Lookup wrong:
Dude I don't know what to tell you - trying to run DNS with just "hostnames" Is BORKED!!! and yeah your going to run into all kinds of shit with shit like that.
The problem likely had to do with the /etc/hosts file. It probably had the old entry or two entries. It's anybody's guess since the file no longer reflects what it did when there was a problem.
When i make an entry in the DNS resolver with only domain, the file gets updated to
192.168.0.13 ppxtest. The problem i had only happened when i created a new machine on the network that got it's ip via DHCP and then i changed that machine to a static IP and made the change in DNS resolver. DNS was still resolving to the old which would have beenx.x.x.x server-main1.companydomain server-main1in the etc/host file from DHCP.If it's "just freaking BORKED!" why is it allowed via the GUI when in the same menu other inputs are appropriately validated? Why does it edit the /etc/hosts file in the same BORKED manner? And if i'm going to run into all kinds of shit as a result, why did it only happen this one time and not when I created multiple host overrides without a host for testing today?
-
It shouldn't be if you ask me... I will bring it up... Prob never thought to put in a check for such nonsense, since thought who would be so stupid to do such a thing ;)
-
@johnpoz said in DNS Lookup wrong:
It shouldn't be if you ask me... I will bring it up... Prob never thought to put in a check for such nonsense, since thought who would be so stupid to do such a thing ;)
They probably never thought someone would be stupid enough to assume they didn't put that check in purely as a lack of thought but validated the very next field and made sure the firewall knew what to do with those request.
