DNS resolution to random ip

jinu

I am using PFSense version 2.5.2. I have enabled DNS resolver and using that for my DNS resolution.

I have local domain setup as lets say abc.com. Now for some reason the DNS resolution for some of local servers happens to the ip 74.124.24.14. I have no idea why this happens.

I have narrowed down my problem to a combination of 2 issues

Windows 10 behavior
PFSense–DNS Resolver.

Windows 10 Issue
Windows for some reason adds the local domain name to the lookup value (even if the lookup value already has the domain name in it). So if my local domain name is abc.com and if i try to do nslookup of server1.abc.com, windows converts it to server1.abc.com.abc.com.

DNS Resolver issue
DNS Resolver on PFSense seems to have this behavior that for any address which ends in the local domain name , if it cant find a dns resolution it blindly resolves it to 74.124.24.14. This i checked using PFSense → Diagnostics -->DNS Lookup. if i give it server1.abc.com it resolves correctly to the local ip address of server1. If i give it server1.abc.com.abc.com it resolves it to 74.124.24.14, Infact if i give any junk value.abc.com it resolves it to 74.124.24.14

I guess if i can get DNS Resolver to modify its behavior so that it return a “host could not be resolved” it would solve the problem. But the question is what setting in DNS Resolver is causing this behavior

Any ideas on this ?

johnpoz

@jinu said in DNS resolution to random ip:

So if my local domain name is abc.com and if i try to do nslookup of server1.abc.com, windows converts it to server1.abc.com.abc.com.

Yeah tell nslookup to just ask what you ask for by putting "." on the end

server1.abc.com.
vs
server1.abc.com

This isn't unbound/pfsense issue - its resolving what your asking for.. nslookup is a horrible troubleshooting tool ;) Use dig..

edit:
Why never use an actual public domain locally is a good thing ;)

use the new home.arpa special domain locally - and you won't ever run into such a problem.

jinu

@johnpoz

Thanks. This works, but it does not solve my basic problem and that is when i try to reach my server using my browser it tries to go to the ip 74.124.24.14. It was as part of this investigation that i ended up with this issue.

Question i cant answer is why the Pfsense-DNS Resolver resolves the server1.abc.com.abc.com to ip 74.124.24.14. Such a domain does not exist and the ip belongs to some IIS server in the USA. PFSense DNS resolver should return a host not found only then will windows send the next and correct url for resolution.

johnpoz

you sure your browser isn't using DOH? The browser makers are way smarter then you or me - they clearly know we shouldn't be using local dns and are too stupid to tell our systems what dns to use... So they have been gracious enough to point your browser at the company that pays them the most money.. Or wait the company they feel provides the best dns ;)

PM me the actual domain, vs this abc.com domain and can take a look to why its resolving to this 74 ip

jinu

@johnpoz

Thanks saw your edit later and figured out that the domain that i was using as a local domain is genuinely present. My mistake

That would also explain why i was getting the ip. Thanks a lot for your help.

johnpoz

using a public domain locally just makes things harder, especially if you don't actually own the domain and control the dns.. Especially when you have clients trying to help you out by using suffix searching..

If you do happen to want to use a public domain locally, or just don't want unbound trying to resolve stuff that you don't have locally as a record. You can set your zone to static vs transparent.

The default zone type will try to resolve something if there is not a local record. So for example if you have say hostA.abc.com, but you don't have hostB.abc.com - and you happen to ask unbound for hostB.abc.com - it would try to actually resolve that vs sending you a hey stupid that record that doesn't exist

example

$ dig @192.168.9.253 nas.local.lan

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

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

;; ANSWER SECTION:
nas.local.lan.          3600    IN      A       192.168.9.10

$ dig @192.168.9.253 nonexist.local.lan

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

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

;; Query time: 1 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Wed Jul 14 08:26:45 Central Daylight Time 2021
;; MSG SIZE  rcvd: 47

Now local.lan never going to resolver anything public, .lan is not a valid tld.. But I just no point in even trying when I know for sure there is never going to be anything public on that domain that I would want/need to resolve. At somepoint I will prob move to the home.arpa domain - but that is a project for another time.. I have everything setup how I like it and many certs created with local.lan, etc. If they ever make .lan a public tld - then yeah for sure I would switch.

jinu

@johnpoz
Thanks i tried changing the zone to Static and it worked. The resolution failed as expected. But the only drawback was that it also failed some public domain lookups that did exist but was rarely used.

I think i will take your advice and move to the home.arpa domain to prevent this confusion.

Query for using this domain : can i use like jinu.home.arpa domain with the same effect. So my servers will be server1.jinu.home.arpa ?

johnpoz

@jinu said in DNS resolution to random ip:

But the only drawback was that it also failed some public domain lookups that did exist but was rarely used.

This is why they default to transparent I do believe - for this specific scenario, its common for users to use some domain they actually own locally, etc. I think its a bad choice, it causes really nothing but issues.. Common practice that solves really both issues of local name and public is using different tld.. say you own domain.com, if you also own control domain.net - you could use .com public, and .net locally..

And sure you can use anything.whatever.heartsdesire.home.arpa if you wanted ;)

https://datatracker.ietf.org/doc/html/rfc8375
Special-Use Domain 'home.arpa.'

Gertjan

@johnpoz said in DNS resolution to random ip:

especially if you don't actually own the domain and control the dns.

Are you saying that there are really people out there use these kind of settings :

johnpoz

@gertjan Yup - not sure about microsoft.com ;) that would be funny..

But yeah users pull domains out of thin air all the time - that are quite often used publicly owned and controlled by someone/company etc..

SteveITS

@gertjan said in DNS resolution to random ip:

really people out there use these kind of settings

Can happen after renames/mergers if they let the old domain expire. Windows asks for "domain name" when setting up a domain controller so people enter their Internet domain name. If Exchange is installed on premises the domain can't be renamed.

We still have one web hosting client that way (that we don't provide IT for) that uses their own Internet domain internally and keeps forgetting to duplicate DNS changes to their LAN.