Unbound Not Resolving One Website

johnpoz

@cnliberal So you can not talk directly to their name servers. Problem with connectivity then.. Could be peering issue with your ISP, could be routing issue - could be block upstream, etc..

Simple workaround for now - you can check later to see if connectivity is returned.. Is just setup a domain override for that specific domain.. for example

Then use dns lookup in diag to validate pfsense can resolve..

This tells unbound - hey if you need to lookup something in that domain - ask googledns, you could use your isp dns, or whatever other dns you want, say cloudflare, etc.

Problem you might have is connectivity problem to that whole network, since they seem to be on the same network as their name servers 199.184.120, so if you having problem talking to that network. Then possible even if you can look it up you can not get there.

edit: oh my bad your domain override should be for mycarle.com - but again.. They seem to be on the same network as the ns, so if you can not talk to the ns.. you prob can not get to the website either, even if you can look it up..

CNLiberal

@johnpoz

What's interesting is if I traceroute the 199.184.120.100 IP, the first IP hit is 10.1.110.1. I'm not sure what that is, as my network is a 10.0.0.0/20:

[2.4.5-RELEASE][root@pfsense.theoltmanfamily.net]/root: traceroute 199.184.120.100
traceroute to 199.184.120.100 (199.184.120.100), 64 hops max, 40 byte packets
 1  10.1.110.1 (10.1.110.1)  171.401 ms  174.149 ms  175.139 ms
 2  unn-143-244-55-254.datapacket.com (143.244.55.254)  172.262 ms  172.304 ms  171.684 ms
 3  be6206.ccr31.buh01.atlas.cogentco.com (149.6.50.81)  171.968 ms  172.827 ms  172.142 ms
 4  be3262.ccr31.bud01.atlas.cogentco.com (154.54.38.245)  183.770 ms  183.556 ms  184.761 ms
 5  be3261.ccr21.bts01.atlas.cogentco.com (130.117.3.137)  189.259 ms
    be3263.ccr22.bts01.atlas.cogentco.com (154.54.59.177)  190.207 ms
    be3261.ccr21.bts01.atlas.cogentco.com (130.117.3.137)  186.550 ms
 6  be2988.ccr51.vie01.atlas.cogentco.com (154.54.59.86)  190.060 ms
    be3463.ccr52.vie01.atlas.cogentco.com (154.54.59.185)  188.315 ms  189.341 ms
 7  be2974.ccr21.muc03.atlas.cogentco.com (154.54.58.5)  193.388 ms
    be3462.ccr22.muc03.atlas.cogentco.com (154.54.59.182)  194.559 ms
    be2974.ccr21.muc03.atlas.cogentco.com (154.54.58.5)  193.825 ms
 8  be2960.ccr42.fra03.atlas.cogentco.com (154.54.36.253)  200.969 ms  199.455 ms  199.248 ms
 9  be2813.ccr41.ams03.atlas.cogentco.com (130.117.0.121)  205.865 ms  205.938 ms  210.122 ms
10  be12488.ccr42.lon13.atlas.cogentco.com (130.117.51.41)  302.444 ms
    be12194.ccr41.lon13.atlas.cogentco.com (154.54.56.93)  315.861 ms
    be12488.ccr42.lon13.atlas.cogentco.com (130.117.51.41)  302.643 ms
11  be3627.ccr41.jfk02.atlas.cogentco.com (66.28.4.197)  305.662 ms
    be2490.ccr42.jfk02.atlas.cogentco.com (154.54.42.85)  302.000 ms  306.395 ms
12  be2889.ccr21.cle04.atlas.cogentco.com (154.54.47.49)  304.928 ms
    be2890.ccr22.cle04.atlas.cogentco.com (154.54.82.245)  301.623 ms
    be2889.ccr21.cle04.atlas.cogentco.com (154.54.47.49)  303.392 ms
13  be3043.ccr22.ymq01.atlas.cogentco.com (154.54.44.166)  311.022 ms
    be2718.ccr42.ord01.atlas.cogentco.com (154.54.7.129)  301.886 ms
    be2879.ccr22.cle04.atlas.cogentco.com (154.54.29.173)  305.511 ms
14  be2521.agr21.ord01.atlas.cogentco.com (154.54.80.254)  302.207 ms
    be2522.agr21.ord01.atlas.cogentco.com (154.54.81.62)  301.770 ms
    be3260.ccr32.yyz02.atlas.cogentco.com (154.54.42.89)  313.150 ms
15  te0-0-2-1.nr12.b010917-1.ord01.atlas.cogentco.com (154.24.64.26)  302.277 ms  301.634 ms
    be2522.agr21.ord01.atlas.cogentco.com (154.54.81.62)  304.195 ms
16  38.142.189.218 (38.142.189.218)  306.163 ms
    te0-0-2-1.nr12.b010917-1.ord01.atlas.cogentco.com (154.24.64.26)  302.129 ms
    38.142.189.218 (38.142.189.218)  302.507 ms
17  38.106.130.90 (38.106.130.90)  305.424 ms
    be2523.agr22.ord01.atlas.cogentco.com (154.54.81.102)  301.628 ms
    38.106.130.90 (38.106.130.90)  305.254 ms
18  38.106.130.90 (38.106.130.90)  310.162 ms
    te0-0-2-2.nr12.b010917-1.ord01.atlas.cogentco.com (154.24.64.30)  303.546 ms
    te0-0-2-1.nr12.b010917-1.ord01.atlas.cogentco.com (154.24.64.26)  308.624 ms
19  * * *
20  * * *
21  * * *
22  * * *

johnpoz

@cnliberal said in Unbound Not Resolving One Website:

the first IP hit is 10.1.110.1. I'm not sure what that is, as my network is a 10.0.0.0/20:

Well either your mistaken with what your network is.. Or your going out a vpn? your doing that from pfsense.. So that first hop would be your isp device IP.. Which could be anything.. What is the IP of pfsense wan?

is the /20 your lan network? When you traceroute from pfsense, the first hop would be its gateway..

Edit: keep in mind that device along the trace doesn't always have to answer with IP you would expect.. See here

That first 50.x.x.x hop is not my gateway, and see that 2nd hop freaking 10 address.. That clearly is not "correct" ;) But its inside the isp network - so could be..

My gateway is in the 64.x address

CNLiberal

@johnpoz BOOM. That was the answer. VPN! I have a VPN running and the IP I'm receiving is a 10.1.110.0 IP. I'm assuming that Unbound was using that VPN connection for some reason?? That sounds like something I'd do. I'll go down that path and let you know.

johnpoz

@cnliberal if your using a vpn - its quite possible said site blocks known vpn IPs.. Ransomware loves to target medical sites, etc. So yeah could see them blocking all known vpn, or bad rep ips, etc. etc. .

CNLiberal

@johnpoz That's exactly what I think. However, I'm not sure why DNS is going over that particular VPN. I'm not seeing explicit rules that reference that VPN Tunnel.

johnpoz

@cnliberal said in Unbound Not Resolving One Website:

I'm not seeing explicit rules that reference that VPN Tunnel.

You pull routes from vpn, it becomes default.. If you pull routes from multiple last one that connected would set as default..

Not just dns - from your traceroute you could see which default route you took.

CNLiberal

@johnpoz OK, I've checked the "Don't Pull Routes" from that VPN connection and things seem to be working correctly. I don't think this will affect any other connections I have. We shall see! Thank you VERY much for the assist!

johnpoz

@cnliberal if your actually policy routing the stuff you want to use the vpn, like a specific vlan, or specific devices IPs you should be fine.

But be aware - depending on how tight your tinfoil hat is, your dns is going to be leaking now ;) <rolleyes>

CNLiberal

@johnpoz This is true about DNS leakage. I'm not sure of a better way to accomplish certain internal IPs using the VPN for all traffic including DNS resolution. I do have policy routing in that I have certain IPs running over the VPN tunnel.

johnpoz

@cnliberal if your worried about specific clients - best to point them to specific dns that policy routes through your vpn.

If my tinfoil hat was that tight - I would run a different dns on my network where I point such clients, with a domain override to ask pfsense for local resources. That way queries from this dns could be policy routed out a vpn. Or even run multiple name servers on your network depending.. That either forward or resolve - either way makes it very easy to policy route their traffic when they actually on the network vs actually being pfsense.

If you run multiple ones you are also sure there is no cache sharing for different clients or different forwarders. With vm and dockers it really simple to spin up as many different copies of something that you might want to run, etc.

Spinning up say a pihole via docker is pretty simple - run 20 of those if you so desired on some box/nas/pi on your network with their own IPs and able to policy route whatever you want from anything, etc.

Just because pfsense runs unbound or bind. Doesn't mean it always makes sense to use that for everything - depending on your needs/wants.

Gertjan

@cnliberal

Check the domain name with https://www.zonemaster.net/domain_check.

The next time you 'rent' a domain name, check the quality of the registrar's services.
Issues like "ns1.carle.com" and "ns2.carle.com" are using the same AS, and are even in the same network. That's not ok.
You can correct this, by adding a third one (or remove the second and replace it for another, elsewhere). Slave DNS name services can be found for free on the Internet.

Issues like :

is also something that had to be dealt with, many years ago.

Who is this registrar, the local hobby club ? ;)

You're aware now that there are 13 'main root servers'. These know where to find all the top name severs, the ones know all about 'com', 'org', 'net', etc.
These top level name servers have many 'clones'.
The bottleneck are the (minimum) two domain name servers, your "ns1.carle.com" and "ns2.carle.com". These two have, of course, firewall rules that to filter out 'abuse'.
And guess what, what is the third reason why people use VPN's ? Right : to abuse a max.
( the third reason : just to loose some money, and the second : hiding their public WAN IP )
Which means : when you connect to your VPN, and you get an IP that was 'used' for some abusive activity, the IP will get blacklisted for a while.
At that moment, you, withthat VPN WAN IP, will have issues when resolving domain name that are registered (known to) "ns1.carle.com" and "ns2.carle.com".