DNS Resolver does stops resolving some domains.
-
Hi guys. Very interesting topic. I am having the same problem with my pfsense resolver. Sometimes I am not able to resolve certain domains on my windows 10 laptop. When I grab my iPhone or iPad the problem is there too. So no client in my network, at that moment, can resolve that specific domain. It often happens with imdb.com. When I login to pfsense and go to Diagnostic -> DNS Lookup and enter imdb.com resolving works. The server 127.0.0.1 correctly resolves imdb.com to an ipadress. From that moment on all my clients in my network can also resolve that domain! Very weird.
I have also setup DNS Resolver on pfsense to use my OpenVPN client interface. I have noticed that this resolving "glitch" does not happen when I enable Forwarding mode in DNS Resolver. Any help is greatly appreciated.
-
And it doesn't happen if you don'y use the VPN?
Are you using DNSsec?
I would suggest you turn up the Unbound logging and then check that next time it fails to see if it's showing clients asking for that URL.
Then run a packet capture to see if the request if being sent either in WAN if it is in the logs or on LAN if it is not.
Steve
-
Hi. Thanks for helping! Yes it does not happen when I disable the VPN and set DNS Resolver to use my WAN. I have tested this for a couple of days and everything (including the imdb.com site) were working fine.
How can I turn up the Unbound logging?
-
The log level is a drop-down on the Advanced Settings tab in Unbound. Set it to level 3 to see queries. You may want to increase the log sizes before doing that though as it can get very noisy.
Steve
-
Thanks I will do that and see what's happening. Btw, do I need to set the Access List for the resolver when I have specific interfaces set in the General Settings tab of the DNS Resolver?
-
You should not. It will allow queries from all the subnets it has interfaces listening on.
Steve
-
I I have set it and this is what I am getting when imdb.com is not able to being resolved (see screenshot). I can see some kind of poisoning going on? Frankly I am lost.
-
I can not duplicate this problem...
imdb.com resolves just fine..
The SOA is listed as dns-external-master.amazon.com, which is not given as an actual NS which come back as
; QUESTION SECTION: ;imdb.com. IN NS ;; ANSWER SECTION: imdb.com. 900 IN NS ns3.p31.dynect.net. imdb.com. 900 IN NS ns2.p31.dynect.net. imdb.com. 900 IN NS ns4.p31.dynect.net. imdb.com. 900 IN NS PDNS2.ultradns.net. imdb.com. 900 IN NS PDNS1.ultradns.net. imdb.com. 900 IN NS pdns6.ultradns.co.uk. imdb.com. 900 IN NS pdns5.ultradns.info. imdb.com. 900 IN NS pdns4.ultradns.org. imdb.com. 900 IN NS PDNS3.ultradns.org. imdb.com. 900 IN NS ns1.p31.dynect.net.This could be problematic but shouldn't be causing the problem.. If your saying it works when you don't use the vpn, then do a dig +trace through the vpn and see where your hitting a problem.
A +trace will walk through just how the resolver resolves and you can see all the steps involved. And where your having a problem.
$ dig imdb.com +trace ; <<>> DiG 9.12.3-P1 <<>> imdb.com +trace ;; global options: +cmd . 81580 IN NS h.root-servers.net. . 81580 IN NS d.root-servers.net. . 81580 IN NS f.root-servers.net. . 81580 IN NS l.root-servers.net. . 81580 IN NS b.root-servers.net. . 81580 IN NS m.root-servers.net. . 81580 IN NS j.root-servers.net. . 81580 IN NS i.root-servers.net. . 81580 IN NS a.root-servers.net. . 81580 IN NS e.root-servers.net. . 81580 IN NS g.root-servers.net. . 81580 IN NS k.root-servers.net. . 81580 IN NS c.root-servers.net. . 81580 IN RRSIG NS 8 0 518400 20190422050000 20190409040000 25266 . bDDO6VLbDeTi3pjCJGBs915yaD64xagxRaqUN1UQg3wFP6v0SXfGDdrx DXI4zBM61NHgXcZDZN1YlQDgW5RZnqf/GdHNDUI53Ab6tBgA7kLr4HUL +8wAT0dgygvLBSDei81B484Zbv3l6tc+RTFUO0f2bvmXUG3byD9JqJwt lbS/Tectg87JvpJ5XrbI9J2R+v7o7j+flbSTdMZGZxv1xr8pRYUFYH1J 8lUAEffjz704YNWCkaa9D5o4x+NhRG/eNrK3uHAYHVhAx+vnZTqH7f4c A1kaUClhHpQDYKDqxt9oz2KcOdItJ3M6lDgCOJZdaQ/8p/7Vx5TWm1VU Hp+Zcw== ;; Received 525 bytes from 192.168.3.10#53(192.168.3.10) in 12 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20190422050000 20190409040000 25266 . mz/BluPZGmNvpuXQH4ruMsK3C7JlGm022rsy9ccJeAgH7uHFBnb/oupF +GECVfjQYMLCAVOLKlEtGbsMNa6nOHErd6sFoTJKGHeJnRhLVIKOyrIJ 8n1P5yx3peUdORy46V2hFuFCdc6dnMPF4FjgDgjd+MT0HWxGWjDSHJ9U efN8Ob74II/Ma+I0hDY5NdLQmq5uNd7771JuR4Bd7//DA3/v9s3jeUZL O/TsGPEuF53tucIV+oM81N37IlkH29y8vMUyO448+B2c0f3AHiMoOjAV T3928H8l2IHhtgcRDrp0smttj4BJVDEhbR3ZkZvIcZHGIP4u17C2gqnT pfUe1Q== ;; Received 1168 bytes from 199.7.91.13#53(d.root-servers.net) in 16 ms imdb.com. 172800 IN NS pdns3.ultradns.org. imdb.com. 172800 IN NS pdns4.ultradns.org. imdb.com. 172800 IN NS pdns1.ultradns.net. imdb.com. 172800 IN NS pdns2.ultradns.net. imdb.com. 172800 IN NS pdns5.ultradns.info. imdb.com. 172800 IN NS pdns6.ultradns.co.uk. imdb.com. 172800 IN NS ns1.p31.dynect.net. imdb.com. 172800 IN NS ns3.p31.dynect.net. imdb.com. 172800 IN NS ns2.p31.dynect.net. imdb.com. 172800 IN NS ns4.p31.dynect.net. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20190413044428 20190406033428 16883 com. KDKyKhfEhyxmB3esZoOugsRqNEbqOD4m7st+H+2lroRIpaKyGflx2DPN yorfB62+ox6whk+X9/+fITemoMGaXd4O58PuvunOfVdKyVpkp/Lw2fqd X//PtaGqQ51ZSy6iGY7V945u+FDcDG8NFjBvhCABaSNIUKIct7lnYd+2 7v8= O4U270A63UUCIE3EG4MLF4DAV3PPQ9CS.com. 86400 IN NSEC3 1 1 0 - O4U44R6RHDJT871PC03RJDB0A109P5J7 NS DS RRSIG O4U270A63UUCIE3EG4MLF4DAV3PPQ9CS.com. 86400 IN RRSIG NSEC3 8 2 86400 20190416054036 20190409043036 16883 com. VQ0Y+GBMPkgexF3Zh6Ygt4B4ctf1T4ZbfIWo0O1oVwHvjdLGT+7xRGrI FS4M46mntpZCLnjP9iVZf4Cc2laC0P4pEeftiE7xzD/wnrs/nM9/zIJ6 7ggbapjJ9HCSP0JknYjr55Ahae9vudiFpIc7s6ZZqmU3YN7H0ax7zha3 dkg= ;; Received 776 bytes from 192.33.14.30#53(b.gtld-servers.net) in 44 ms imdb.com. 900 IN A 52.94.228.167 imdb.com. 900 IN A 52.94.225.248 imdb.com. 900 IN A 52.94.237.74 imdb.com. 900 IN NS PDNS3.ultradns.org. imdb.com. 900 IN NS PDNS1.ultradns.net. imdb.com. 900 IN NS pdns5.ultradns.info. imdb.com. 900 IN NS pdns4.ultradns.org. imdb.com. 900 IN NS PDNS2.ultradns.net. imdb.com. 900 IN NS ns4.p31.dynect.net. imdb.com. 900 IN NS pdns6.ultradns.co.uk. imdb.com. 900 IN NS ns3.p31.dynect.net. imdb.com. 900 IN NS ns1.p31.dynect.net. imdb.com. 900 IN NS ns2.p31.dynect.net. ;; Received 339 bytes from 204.13.250.31#53(ns2.p31.dynect.net) in 15 msNS sending out additional info like the NS isn't always a bad thing.. Please post up the config of your resolver - did you mess with anything other than default... Like did you set Query Name Minimization?
-
I don't know who is this "ultradns", but the Resolver complains about it.
Your logs show that the Resolver send out the to this " 199.7.69.1" DNS (you are forwarding to it ?) but the answer is ... no answer.
"
"A solution might be : use the Resolver as Resolver and you'll be fine ^^
-
@Gertjan said in DNS Resolver does stops resolving some domains.:
199.7.69.1
That is pdns4.ultradns.org. they are listed as one of the NS for imdb.com
They are a large player in the dns space.. They are Neustar..
Depending on your configuration its possible you could see such log entries when NS info is given out when not asked for with unbound. Normally you do not always hand out that info, to save on bandwidth, etc. etc.. But all depends on how the NS are configured with additional info. As I suggested I would do a +trace with dig to see where he might be having issues resolving via is vpn... Its possible he is having issues talking to the NS that are authoritative for imdb, or somewhere between roots and there
You can see them listed when you ask unbound what it uses for lookup of that domain.
[2.4.4-RELEASE][admin@sg4860.local.lan]/root: unbound-control -c /var/unbound/unbound.conf lookup imdb.com The following name servers are used for lookup of imdb.com. ;rrset 3597 10 0 7 3 imdb.com. 3597 IN NS PDNS1.ultradns.net. imdb.com. 3597 IN NS pdns4.ultradns.org. imdb.com. 3597 IN NS pdns6.ultradns.co.uk. imdb.com. 3597 IN NS ns4.p31.dynect.net. imdb.com. 3597 IN NS pdns5.ultradns.info. imdb.com. 3597 IN NS ns1.p31.dynect.net. imdb.com. 3597 IN NS PDNS3.ultradns.org. imdb.com. 3597 IN NS PDNS2.ultradns.net. imdb.com. 3597 IN NS ns3.p31.dynect.net. imdb.com. 3597 IN NS ns2.p31.dynect.net. ;rrset 71670 1 0 8 3 ns2.p31.dynect.net. 71670 IN A 204.13.250.31 ;rrset 71670 1 0 8 3 ns3.p31.dynect.net. 71670 IN A 208.78.71.31 ;rrset 302 1 0 8 0 ns3.p31.dynect.net. 302 IN AAAA 2001:500:94:1::31 ;rrset 3334 1 0 8 0 pdns2.ultradns.net. 3334 IN A 204.74.109.1 ;rrset 3334 1 0 8 0 pdns2.ultradns.net. 3334 IN AAAA 2610:a1:1014::1 ;rrset 3335 1 0 8 0 pdns3.ultradns.org. 3335 IN A 199.7.68.1 ;rrset 3335 1 0 8 0 pdns3.ultradns.org. 3335 IN AAAA 2610:a1:1015::1 ;rrset 71670 1 0 8 3 ns1.p31.dynect.net. 71670 IN A 208.78.70.31 ;rrset 302 1 0 8 0 ns1.p31.dynect.net. 302 IN AAAA 2001:500:90:1::31 ;rrset 3597 1 0 8 0 pdns5.ultradns.info. 3597 IN A 204.74.114.1 ;rrset 3597 1 0 8 0 pdns5.ultradns.info. 3597 IN AAAA 2610:a1:1016::1 ;rrset 71670 1 0 8 3 ns4.p31.dynect.net. 71670 IN A 204.13.251.31 ;rrset 361 1 0 8 0 pdns6.ultradns.co.uk. 361 IN A 204.74.115.1 ;rrset 361 1 0 8 0 pdns6.ultradns.co.uk. 361 IN AAAA 2610:a1:1017::1 ;rrset 3597 1 0 8 0 pdns4.ultradns.org. 3597 IN A 199.7.69.1 ;rrset 3597 1 0 8 0 pdns4.ultradns.org. 3597 IN AAAA 2001:502:4612::1 ;rrset 302 1 0 8 0 pdns1.ultradns.net. 302 IN A 204.74.108.1 ;rrset 302 1 0 8 0 pdns1.ultradns.net. 302 IN AAAA 2001:502:f3ff::1 Delegation with 10 names, of which 2 can be examined to query further addresses. <snipped the rest> -
Amazing work guys! Thanks for all the help. I have done some more testing on my side and then contacted my OpenVPN provider. I suspected that they were redirecting all DNS requests in the tunnel and they acknowledged that. Their guide for pfsense clearly states to use DNS resolver in forwarding mode and not resolving mode. So bummer on that. At least everything is working fine in forwarding mode so I will leave it at that for now.
Again thanks everyone for being so helpful!
-
@vjizzle said in DNS Resolver does stops resolving some domains.:
redirecting all DNS requests in the tunnel and they acknowledged that.
WTF?? They say they are doing that for your privacy? That is just pure utter nonsense!!!
