DNS Lookup wrong

Problem with system today. DNS lookup is wrong. If i type in a server name like "server-main1" it resolves to 192.168.5.125 which is the ip it was assigned when i created it. I gave the server a static IP and rebooted it. from another machine i can ping the server and ssh into it using the new ip. Why does pfsense still resolve to the old IP?

I also went to services, dns resolver and updated the hostname and ip and it still is not working. All other settings i have are working in dns resolver

??

johnpoz

server-main1 is not even a fqdn... So that would never resolve in the first place... did you mean server-main1.something??

So if your had pfsense register dhcp, and then changed the server to a static IP... Did it release the dhcp entry or its still there?

Post what you updated exactly show your query.. using your fav dns tool, dig, host, nslookup, etc.

server-main1 is not even a fqdn... So that would never resolve in the first place.

Results from pfsense DNS Lookup:
Hostname: ctrl-server1
Result Record type
192.168.0.15 A

I'm not sure what you mean by your first quote. If that is true, my pfsense is broken because it resolved. What did i miss?

johnpoz

And what version of pfsense are you running?

dns can not just resolve a host.. it has to be fully qualified... host.domain..

@johnpoz said in DNS Lookup wrong:

So if your had pfsense register dhcp, and then changed the server to a static IP... Did it release the dhcp entry or its still there?
Post what you updated exactly show your query.. using your fav dns tool, dig, host, nslookup, etc.

It did not release the DHCP until today. Friday i did a reboot and DNS Lookup in pfsense still showed the old IP. This is even after restaring unbound and dhcpd service. However today, it's resolving to the IP set in pfsense.

What i'm confused about is why restarting pfsense or unbound and dhcpd service seem to have no effect Friday. Was i suppose to do something else to pfsense after changing a machine from DHCP to a static IP?

I'm also confused about the first reply that it would never resolve in the first place. I'm sure there is something i'm missing there.

johnpoz

$ dig @192.168.9.253 sg4860

; <<>> DiG 9.12.3-P1 <<>> @192.168.9.253 sg4860
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40526
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sg4860.                                IN      A

;; AUTHORITY SECTION:
.                       3600    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2019042200 1800 900 604800 86400

;; Query time: 35 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Mon Apr 22 12:27:13 Central Daylight Time 2019
;; MSG SIZE  rcvd: 110

$ dig @192.168.9.253 sg4860.local.lan

; <<>> DiG 9.12.3-P1 <<>> @192.168.9.253 sg4860.local.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42218
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sg4860.local.lan.              IN      A

;; ANSWER SECTION:
sg4860.local.lan.       3600    IN      A       192.168.9.253

;; Query time: 1 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Mon Apr 22 12:28:04 Central Daylight Time 2019
;; MSG SIZE  rcvd: 61

DNS can not resolve just a HOST without the domain!

@johnpoz said in DNS Lookup wrong:

And what version of pfsense are you running?

dns can not just resolve a host.. it has to be fully qualified... host.domain..

I'm running 2.4.4-RELEASE-p2 (arm) on pfsense hardware. I had that hostname setup in "Host Overrides", domain part of the DNS Resolver.

I just tried again with something like "ppxc" and then went to DNS Lookup in pfsense and it resolves to the IP i set in "Host Overrides", domain (=ppxc) part of the DNS Resolver. I'm not sure why this does not throw errors.

johnpoz

So your creating a host override just filling in the domain and leaving host empty??

That is just freaking BORKED!

@johnpoz DNS Lookup appending .local in background?

pfsense_example_Screenshot from 2019-04-22 13-32-18.png

@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?

johnpoz

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.

Gertjan

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.net

Correct, " 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 ?

johnpoz

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=64

See 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.net
Correct, " 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: 52

I 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.

Gertjan

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 type

cat /etc/hosts

It could explain things...

johnpoz

@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!

@Gertjan

/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 been x.x.x.x server-main1.companydomain server-main1 in 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?

johnpoz

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.