OPNsense Forum

English Forums => 25.7 Series => Topic started by: GrumpyOLTechie on August 03, 2025, 01:41:47 AM

Title: Unbound appending home.arpa to valid external url and then failing with NXDomain
Post by: GrumpyOLTechie on August 03, 2025, 01:41:47 AM
Hi,

I have only found 1 URL that does this.

my ISP's help webpage.

with unbound running, all block lists cleared and disabled, no register anything in DNS forwarders or not, no static arp entries or anything like that
(I use quad9 unsecured DoT - IE - no blocking whatsoever)

I opened Firefox and Librewolf

Firefox is VPN only
Librewolf is bypass VPN

with the VPN connected Firefox loads help.teksavvy.com with zero issues
Librewolf is saying "We can't connect to the server at help.teksavvy.com"
I disconnect for the VPN and Firefox starts to give "We can't connect to the server at help.teksavvy.com"
I connect to my cell phones hot spot and both browsers load it up right away.

This is very odd to me so I captured some tcpdump on port 53 and 853

53 snippet is below:

19:20:02.426726 IP 192.168.175.10.40211 > 192.168.175.1.53: 53429+ A? help.teksavvy.com. (35)
19:20:02.501549 IP 192.168.175.1.53 > 192.168.175.10.40211: 53429 NXDomain 1/0/0 CNAME domains.bettermode.io. (70)
19:20:02.501844 IP 192.168.175.10.46343 > 192.168.175.1.53: 10632+ A? help.teksavvy.com.home.arpa. (45)
19:20:02.502503 IP 192.168.175.1.53 > 192.168.175.10.46343: 10632 NXDomain 0/1/0 (104)
19:20:03.051475 IP 192.168.175.18.58756 > 192.168.175.1.53: 32394+ A? rr1---sn-ux3n588t-mjh6.googlevideo.com. (56)
19:20:03.051770 IP 192.168.175.18.57840 > 192.168.175.1.53: 33149+ HTTPS? rr1---sn-ux3n588t-mjh6.googlevideo.com. (56)
19:20:03.098312 IP 192.168.175.1.53 > 192.168.175.18.58756: 32394 2/0/0 CNAME rr1.sn-ux3n588t-mjh6.googlevideo.com., A 206.248.169.108 (107)
19:20:03.439760 IP 192.168.175.1.53 > 192.168.175.18.57840: 33149 2/0/0 CNAME rr1.sn-ux3n588t-mjh6.googlevideo.com., HTTPS (113)
19:20:03.451242 IP 192.168.175.10.56601 > 192.168.175.1.53: 31914+ A? help.teksavvy.com. (35)
19:20:03.451643 IP 192.168.175.1.53 > 192.168.175.10.56601: 31914 NXDomain 1/0/0 CNAME domains.bettermode.io. (70)
19:20:03.451813 IP 192.168.175.10.33670 > 192.168.175.1.53: 12969+ A? help.teksavvy.com.home.arpa. (45)
19:20:03.452142 IP 192.168.175.1.53 > 192.168.175.10.33670: 12969 NXDomain 0/1/0 (104)
19:20:04.643408 IP 192.168.175.10.54041 > 192.168.175.1.53: 55773+ A? help.teksavvy.com. (35)
19:20:04.643842 IP 192.168.175.1.53 > 192.168.175.10.54041: 55773 NXDomain 1/0/0 CNAME domains.bettermode.io. (70)
19:20:04.644020 IP 192.168.175.10.37668 > 192.168.175.1.53: 32194+ A? help.teksavvy.com.home.arpa. (45)
19:20:04.644303 IP 192.168.175.1.53 > 192.168.175.10.37668: 32194 NXDomain 0/1/0 (104)
19:20:05.093359 IP 192.168.175.10.37965 > 192.168.175.1.53: 10969+ A? help.teksavvy.com. (35)
19:20:05.093940 IP 192.168.175.1.53 > 192.168.175.10.37965: 10969 NXDomain 1/0/0 CNAME domains.bettermode.io. (70)
19:20:05.094244 IP 192.168.175.10.50103 > 192.168.175.1.53: 13512+ A? help.teksavvy.com.home.arpa. (45)
19:20:05.094812 IP 192.168.175.1.53 > 192.168.175.10.50103: 13512 NXDomain 0/1/0 (104)
19:20:07.467367 IP 192.168.175.10.47428 > 192.168.175.1.53: 27245+ A? discourse.pi-hole.net. (39)
19:20:07.467871 IP 192.168.175.1.53 > 192.168.175.10.47428: 27245 1/0/0 A 157.180.42.82 (55)

of course using DoT I only see this when dumping port 853

19:20:52.447387 IP 149.112.112.112.853 > 24.212.185.81.63245: Flags [P.], seq 1919021145:1919021169, ack 4171963101, win 22, options [nop,nop,TS val 316595860 ecr 3829189812], length 24
19:20:52.447458 IP 24.212.185.81.63245 > 149.112.112.112.853: Flags [.], ack 24, win 514, options [nop,nop,TS val 3829199954 ecr 316595860], length 0
19:20:52.447522 IP 149.112.112.112.853 > 24.212.185.81.63245: Flags [F.], seq 24, ack 1, win 22, options [nop,nop,TS val 316595860 ecr 3829189812], length 0
19:20:52.447544 IP 24.212.185.81.63245 > 149.112.112.112.853: Flags [.], ack 25, win 514, options [nop,nop,TS val 3829199954 ecr 316595860], length 0
19:20:52.447629 IP 24.212.185.81.63245 > 149.112.112.112.853: Flags [P.], seq 1:25, ack 25, win 514, options [nop,nop,TS val 3829199954 ecr 316595860], length 24
19:20:52.447786 IP 24.212.185.81.63245 > 149.112.112.112.853: Flags [F.], seq 25, ack 25, win 514, options [nop,nop,TS val 3829199954 ecr 316595860], length 0
19:20:52.473880 IP 149.112.112.112.853 > 24.212.185.81.63245: Flags [R], seq 1919021170, win 0, length 0
19:20:52.473971 IP 149.112.112.112.853 > 24.212.185.81.63245: Flags [R], seq 1919021170, win 0, length 0
19:20:57.457835 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [S], seq 1149037668, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 2054282869 ecr 0], length 0
19:20:57.475195 IP 149.112.112.112.853 > 24.212.185.81.59161: Flags [S.], seq 3331761963, ack 1149037669, win 43440, options [mss 1460,sackOK,TS val 4044053599 ecr 2054282869,nop,wscale 11], length 0
19:20:57.475256 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [.], ack 1, win 514, options [nop,nop,TS val 2054282886 ecr 4044053599], length 0
19:20:57.475730 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [P.], seq 1:322, ack 1, win 514, options [nop,nop,TS val 2054282887 ecr 4044053599], length 321
19:20:57.501382 IP 149.112.112.112.853 > 24.212.185.81.59161: Flags [.], ack 322, win 22, options [nop,nop,TS val 4044053625 ecr 2054282887], length 0
19:20:57.501773 IP 149.112.112.112.853 > 24.212.185.81.59161: Flags [.], seq 1:1449, ack 322, win 22, options [nop,nop,TS val 4044053626 ecr 2054282887], length 1448
19:20:57.501809 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [.], ack 1449, win 503, options [nop,nop,TS val 2054282913 ecr 4044053626], length 0
19:20:57.501816 IP 149.112.112.112.853 > 24.212.185.81.59161: Flags [P.], seq 1449:2897, ack 322, win 22, options [nop,nop,TS val 4044053626 ecr 2054282887], length 1448
19:20:57.501836 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [.], ack 2897, win 492, options [nop,nop,TS val 2054282913 ecr 4044053626], length 0
19:20:57.501863 IP 149.112.112.112.853 > 24.212.185.81.59161: Flags [P.], seq 2897:3302, ack 322, win 22, options [nop,nop,TS val 4044053626 ecr 2054282887], length 405
19:20:57.501883 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [.], ack 3302, win 489, options [nop,nop,TS val 2054282913 ecr 4044053626], length 0
19:20:57.507477 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [P.], seq 322:402, ack 3302, win 514, options [nop,nop,TS val 2054282918 ecr 4044053626], length 80
19:20:57.507520 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [P.], seq 402:554, ack 3302, win 514, options [nop,nop,TS val 2054282918 ecr 4044053626], length 152
19:20:57.527016 IP 149.112.112.112.853 > 24.212.185.81.59161: Flags [P.], seq 3302:3573, ack 554, win 22, options [nop,nop,TS val 4044053651 ecr 2054282918], length 271
19:20:57.527055 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [.], ack 3573, win 512, options [nop,nop,TS val 2054282939 ecr 4044053651], length 0
19:20:57.527058 IP 149.112.112.112.853 > 24.212.185.81.59161: Flags [P.], seq 3573:3844, ack 554, win 22, options [nop,nop,TS val 4044053651 ecr 2054282918], length 271
19:20:57.527070 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [.], ack 3844, win 510, options [nop,nop,TS val 2054282939 ecr 4044053651], length 0
19:20:57.527076 IP 149.112.112.112.853 > 24.212.185.81.59161: Flags [P.], seq 3844:3918, ack 554, win 22, options [nop,nop,TS val 4044053651 ecr 2054282918], length 74
19:20:57.527091 IP 24.212.185.81.59161 > 149.112.112.112.853: Flags [.], ack 3918, win 511, options [nop,nop,TS val 2054282939 ecr 4044053651], length 0

I am unsure why this is happening and it is probably my own fault but I do not know for sure.

Anyone can help that would be very nice tyvm.

Title: Re: Unbound appending home.arpa to valid external url and then failing with NXDomain
Post by: Patrick M. Hausen on August 03, 2025, 02:07:59 AM
Recursive name servers never manipulate the DNS name queried - the client's resolver library does that.
Title: Re: Unbound appending home.arpa to valid external url and then failing with NXDomain
Post by: GrumpyOLTechie on August 03, 2025, 02:23:17 AM
Hi,

TYVM for responding.
I was so excited that someone responded I forgot my manners.

so when you say "the client's resolver library"
would you be referring to my desktops client resolver?

On Linux what would that be?
I am running EndeavourOS.
or would you be referring to the DoT servers I forward to?
In my case, quad9 unsecured - dot10.quad9.net

"Edit#2: OK it IS the quad9 DoT servers doing this.
Probably because I have something misconfigured on my end.

I am unsure howto approach troubleshooting this.
Any ideas, hints, tips URL's anyone could provide?"

Edit#3: so, when I looked at my "automatically generated" resolv.conf file
 (the one that'll get overwritten if I edit it) it shows home.arpa as the search domain
I commented out the entry:

# Generated by NetworkManager
#search home.arpa

and left only the nameserver x.x.x.x entry, saved it and then -re-enabeld the DoT servers, then the help.teksavyy.com webpage opens just fine with the DoT servers at quad9 enabled




Tyvm once more for your response.
Title: Re: Unbound appending home.arpa to valid external url and then failing with NXDomain
Post by: GrumpyOLTechie on August 03, 2025, 02:50:05 AM
My next question is probably going to be in the EndeavourOS forum but does anyone know howto stop the network manager from automatically inserting a search domain into resolv.conf.

This is not normal behavior is it?

I have my desktop using dhcp so the domain name is coming from OPNSense is it not?

I checked my HOST.conf, hostname and resolv.conf and the only place I see the home.arpa domain is in the automatically generated entry in resolv.conf and my PC got that from the dhcp server on OPNSense.

Once again, I am sure this is something I did but I cannot figure out what and am trying to understand how to stop this behavior.

I'll go ask in the Endeavour OS forum to.

Thanks a bunch to everyone!
Title: Re: Unbound appending home.arpa to valid external url and then failing with NXDomain
Post by: GrumpyOLTechie on August 03, 2025, 06:38:10 PM
It was Quad9 in the end.

I was editing the resolv.conf to comment out my internal domain name and that would get the website working once more while also not seeming to negatively affect anything else
.
I disabled quad9 dot srv's and added cloud-flares and the issue is gone on cloud-flare.

This is probably still my fault as I had a setting to register dhcp clients in dns and that probably got sent to quad9's dns servers and yadda,yadda, yadda-like I said. Probably my own fault.