Zoom Blocked, Completely Stumped.
-
Yeah if your blocking outbound traffic to the networks or IPs the gtld servers are in your going to have problems!!!
Keep in mind the root and gtlds (ns for tlds) just below the root servers in the hierarchy are globally based.. So they could really be anywhere across the globe.
Blocking the planet is really BAD idea and practice. You should block only specifics.. Or only allow specifics to your inbound traffic.
pbflocker and IPS are both very powerful tools - and quite often users shoot themselves in the foot with them. Like handing a loaded gun to a teenager that has been in your liquor cabinet if you ask me... Yeah they might hit a few targets, but let them play with it long enough and they will end up in the hospital or the morgue..
I only block couple of things outbound.. rfc1918 being a good netizen, and known doh servers IPs. And dot (853).. I do not use doh, I do not use dot - and I want none of my devices using it behind my back... These rules are logged, and any hits I will look into why!! Rest of the internet is open outbound... I never know what I might need to talk to..
-
@stephenw10 @johnpoz I don't have Snort or Suratica installed the system. As far as I can tell, pfblocker is completely shut down. I just filtered both the firewall logs and the pfblocker logs against every one of the 6 IPs and I got no blocks whatsoever. On the firewall I log everything except the default block rule on WAN and as far as I know pfblocker logs every block. I only have 1 geo_ip block alias (some selected Top 40 spammers) but I have it disabled in the firewall on the Lan interface where I've done some of my testing today. I also see in the pfsense logs that the top 40 Spammers feed was last updated March 10. We've definitely been on zoom since then.....this all started today....so I doubt it's an update to that feed. I don't block the planet.
I really grateful and appreciate of your guy's help today. I've learned so much from you guys over the years and continue to learn more and more each day. It's very comforting to know that you guys are out there for when I'm really lost with no direction home!
Right now I'm going to get some dinner and a stiff drink and dig into this again in the morning with a big cup of coffee. I'll let you guys know what, if anything, I find out. Thanks again!
-
@dma_pf so you have no rules in floating?
What is odd unbound wouldn't try tcp unless udp failed normally.. So its odd your permission denied there are all tcp.. Are you not getting an answer via UDP so its trying TCP and that is being denied?
root servers we identified as authoritative for zoom.us
Those are not the authoritative NS for zoom.us, those are the authoritative name servers for the .us tld..
Can you lookup say www.state.il.us, or your state all states should really resolve.. Now that site might might redirect you to a .gov site for that state, etc. but really all states should resolve via the format www.state.XX.us
There are many gov sites that have such a format that should resolve.. I just can think of any other popular.us sites off the top of my head.. But if your having a problem with the us tld servers then you should be having problems looking up anything.us
example
$ dig www.state.il.us +short 216.124.54.83 $ dig www.state.oh.us +short 66.144.73.125 $ dig www.state.ca.us +short www.ca.gov. www.ca.gov.edgekey.net. e65017.dscb.akamaiedge.net. e65017.dscb.akamaiedge.net.0.1.cn.akamaiedge.net. 23.56.237.108 23.56.237.124 $ dig www.state.wv.us +short 129.71.224.134 $ dig www.state.nd.us +short state.nd.us. 165.234.159.23 $ dig www.state.wy.us +short 192.146.215.91What about say apple.us or google.us those should resolve
$ dig google.us +short 142.250.190.100 $ dig apple.us +short 17.253.142.4You can also look to unbound on where it would go look for any domain. So for example ask unbound - hey what were would you go ask for zoom.us I get.
[22.01-RELEASE][admin@sg4860.local.lan]/root: unbound-control -c /var/unbound/unbound.conf lookup zoom.us The following name servers are used for lookup of zoom.us. ;rrset 61601 4 0 8 3 zoom.us. 61601 IN NS ns-1137.awsdns-14.org. zoom.us. 61601 IN NS ns-1772.awsdns-29.co.uk. zoom.us. 61601 IN NS ns-387.awsdns-48.com. zoom.us. 61601 IN NS ns-888.awsdns-47.net. ;rrset 56026 1 0 8 3 ns-888.awsdns-47.net. 56026 IN A 205.251.195.120 ;rrset 56026 1 0 8 3 ns-888.awsdns-47.net. 56026 IN AAAA 2600:9000:5303:7800::1 ;rrset 11466 1 0 8 3 ns-387.awsdns-48.com. 11466 IN A 205.251.193.131 ;rrset 11466 1 0 8 3 ns-387.awsdns-48.com. 11466 IN AAAA 2600:9000:5301:8300::1 ;rrset 52745 1 0 8 3 ns-1772.awsdns-29.co.uk. 52745 IN A 205.251.198.236 ;rrset 52745 1 0 8 3 ns-1772.awsdns-29.co.uk. 52745 IN AAAA 2600:9000:5306:ec00::1 ;rrset 61601 1 0 8 3 ns-1137.awsdns-14.org. 61601 IN A 205.251.196.113 ;rrset 61602 1 0 8 3 ns-1137.awsdns-14.org. 61602 IN AAAA 2600:9000:5304:7100::1 Delegation with 4 names, of which 0 can be examined to query further addresses. It provides 8 IP addresses. 2600:9000:5304:7100::1 not in infra cache. 205.251.196.113 not in infra cache. 2600:9000:5306:ec00::1 not in infra cache. 205.251.198.236 not in infra cache. 2600:9000:5301:8300::1 expired, rto 3426080 msec, tA 0 tAAAA 0 tother 0. 205.251.193.131 expired, rto 3426080 msec, tA 0 tAAAA 0 tother 0. 2600:9000:5303:7800::1 not in infra cache. 205.251.195.120 expired, rto 3426080 msec, tA 0 tAAAA 0 tother 0. [22.01-RELEASE][admin@sg4860.local.lan]/root:If I ask it where it would find the NS for any us. domain
[22.01-RELEASE][admin@sg4860.local.lan]/root: unbound-control -c /var/unbound/unbound.conf lookup us. The following name servers are used for lookup of us. ;rrset 41190 6 0 2 0 us. 41190 IN NS k.cctld.us. us. 41190 IN NS x.cctld.us. us. 41190 IN NS b.cctld.us. us. 41190 IN NS y.cctld.us. us. 41190 IN NS w.cctld.us. us. 41190 IN NS f.cctld.us. ;rrset 41190 2 1 11 5 us. 41190 IN DS 21364 8 1 260D0461242BCF8F05473A08B05ED01E6FA59B9C us. 41190 IN DS 21364 8 2 B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E6EBDAB26 us. 41190 IN RRSIG DS 8 1 86400 20220328050000 20220315040000 9799 . gP5Vt4cLr/5t/NsWZaB7v+T5jYVWTbkzitGUFCzI+0EdLQvaZ2Tk06sBaxXeV+B69R7rjv8UD8grD0v4Db3c0udjzPf/zaND/aHK0t+UvNZIc+s57DLriJkh7mhdM8WwKB2XyJxiFfMIpRurLQNCiI8sA0L/0nkRHdQ9u5ZMMOXyMHODoQ7l2JZy5WHPjmvqkFj2zjkB7a7f1AdblYp4Eh/ngYRNxRShFwHBMJCoYaaw067e/JHZSCFEh9Dlgy1JWW9oIvEsc7yIo8KtR1vsc3ZEj1TKQ9QcJiS8FdLEBGwAGDmTZrFxRbDFIKR8p8pthLzcqAiIBOyVdcK8pSh/zw== ;{id = 9799} ;rrset 61668 1 1 11 5 f.cctld.us. 61668 IN A 209.173.58.70 f.cctld.us. 61668 IN RRSIG A 8 3 86400 20220408144101 20220309140106 53985 us. JBNdg17AOx4FnRMwCfCpQLc56OQu8uqyFfTb4HZCHW3DC0Lz6vQ5YDCC5AY9j64QD7SAsf4Ys21Yfjuw9oFoo/oUc/t77BgNfWu5yp1FfErQ4dlFb8ad0meqdc3HxiB0MToqk2TiJqf77dmJrglBMe2qsBZXBLdbJTf2lg52yev1JhZ6jqjgtu7ck0xjS5pITOyLqfnzbaJ/rhlwmQ0a5Q== ;{id = 53985} ;rrset 61668 1 1 11 5 f.cctld.us. 61668 IN AAAA 2001:500:3682::11 f.cctld.us. 61668 IN RRSIG AAAA 8 3 86400 20220408144101 20220309140106 53985 us. kGm+EQqTNs95rihLFCtjW93EgORZFsARKs6uosoY5+16Xfx+iTuTF8bCrK5t/APDlSqeP9BmQrLsQ4IT9loyZClL4euquPizSyPs+EuDetsW/stmbiOyOYB9tk8vLNlLpGWqjTm+fLLdVM3dnXlMy+J/kqKav6Y7QZ+oXLLPMzfCx8jCpn2+CPuOUK2N/LXkVayl5HLLI20+JnnVX0gzaw== ;{id = 53985} ;rrset 61668 1 1 11 5 w.cctld.us. 61668 IN A 37.209.192.15 w.cctld.us. 61668 IN RRSIG A 8 3 86400 20220408151325 20220309144008 53985 us. l3jIDgU9PTHCoNmsSvcAf9dzPe/m+XwrZQoWesnejXWMUt9hIhzw/OWDA/wwx5BlHwUY7xguqFngKLRt+rSQ+Owv5J7cwLBtdfj93Ba1aopdu6SIuHDqUq5J2IArHnZSVSl1/M8eNF/nM4eHoW5FqLudRRWajW+ZG0//DQlz+rAL60nlhedY9HqqoGWzC4boCx2+imaxW8fox91y+mwqsw== ;{id = 53985} ;rrset 61668 1 1 11 5 w.cctld.us. 61668 IN AAAA 2001:dcd:1::15 w.cctld.us. 61668 IN RRSIG AAAA 8 3 86400 20220408151325 20220309144008 53985 us. xdgesCQdB3c5DtkAx3uKTtjduC9o9XzUnH4jRdTQvxckKhd3VhSqIzJz3o9VfhQXSGTCIN0OkwSeXR1sI+61N6p5R3wXROmfWPZTQcaNW01+AokE/kWZelw0n7nn5NS/+ko4+WtoF/snlbfPpJOeQhlNZMKR0LFMukKxd0paQNr8Gd+ygP3VOYkP9X9V1RV4G9hUOKuWZKHBnR++Pfkviw== ;{id = 53985} ;rrset 61668 1 1 11 5 y.cctld.us. 61668 IN A 37.209.196.15 y.cctld.us. 61668 IN RRSIG A 8 3 86400 20220408144101 20220309140106 53985 us. opF4x8u+PRnzbC76K39HF/Yvv4DtUoR9MgQvMqCFnXUnaw2VunGvfbgkSOnJsaspO/+uW2dfyJIChgbIPPCuMWBC1h1LCdaMgVE3BX0Mn/MTilZLBUpHh4SHZMCIYRVOSwW4kD5czo/eOsp+kxBKVQ4Fj7whtiHJzfFNBGdHRNBizfCQzKNPVc5Ap+7uJEmG7/ctAmVNid/dfIq+LmQlwQ== ;{id = 53985} ;rrset 61668 1 1 11 5 y.cctld.us. 61668 IN AAAA 2001:dcd:3::15 y.cctld.us. 61668 IN RRSIG AAAA 8 3 86400 20220408144101 20220309140106 53985 us. KKJb13+9LzpZCOQCJarKyYpTkHqDz5Gt0e2k2Ufsw68uQPVOI9/mPcti8s9QplK57xL9xBpqOI0XXgaYoyJcg0O3swLLQEdxWJrvSoxWFosuvWHk+2lD1mhlbHxWctkGY3FRf/aamxFOI3F72MeFmVjkSeGNNQlXJ43iexYZ7cNnab8WrgHJV4mG9aCVlFqIqxF2YR7shfp9TXxZLP/0qg== ;{id = 53985} ;rrset 61668 1 1 11 5 b.cctld.us. 61668 IN A 156.154.125.70 b.cctld.us. 61668 IN RRSIG A 8 3 86400 20220408144101 20220309140106 53985 us. UHm1VQTRrWMObX5BKnfnxeUt12Lt3Tjhe98a88kamAhHqOiRNYnMPiy5cv1XStX3Ahsy6WkqPZWDCIbh9VB+vovbq+zDf3knGMVwWM8jUYdn0sDAqtTvc5ta/zUSpD4IAN/m06/6FDX7qMPjNYlIBklJO0Rs4OO61LwWKxsKaVg4ytqfbv8zETMNLzANI2ReyNlekmkaOwmh1q788fjI3w== ;{id = 53985} ;rrset 61668 1 1 11 5 b.cctld.us. 61668 IN AAAA 2001:502:ad09::29 b.cctld.us. 61668 IN RRSIG AAAA 8 3 86400 20220408144101 20220309140106 53985 us. YYF79W6LuKWMGCaWU4tmTeBCdVgmXIsm5f3zAQXcm2HEGL9ee8qB3CdLusmsXX1TMFlWBRtzd1EtrA6n1HeqWH6XxctrwHfqb5pa7dyUyjqNzEfzdu5tzMbBlsZhQ2u+Gw1lYsQrZmVCaoVMR1xWCZ5+cMhsly5FaK5K6CRgLayjj8caCyoGEwehBfbO61pUnjssuxqBB5uqbIbKzvSpXg== ;{id = 53985} ;rrset 61668 1 1 11 5 x.cctld.us. 61668 IN A 37.209.194.15 x.cctld.us. 61668 IN RRSIG A 8 3 86400 20220408144101 20220309140106 53985 us. behf21LmbISS+5Rio3bs8AZ+MLtKphX8NmA54/Lp66Xphmv2uVtgGeAyMth0ZtOXJxjsdUvutB5HDdvEfHDs8SB2aVvV7bZWVmst+Z/yCMg1T6rBS9iud75mBKo1eZYGCQmkg4plC1nVXWBohvHXBIGTJo/Glf+p45tDLnHUnjV3oqeqdipi4ttsejkOTz4H6lbuLkN09lUOTThnY5/oYQ== ;{id = 53985} ;rrset 61668 1 1 11 5 x.cctld.us. 61668 IN AAAA 2001:dcd:2::15 x.cctld.us. 61668 IN RRSIG AAAA 8 3 86400 20220408144101 20220309140106 53985 us. fvEmdE8Ml2QxBzDSgyx00/VjmT0hTj2DfVYTZnU+SzuYcfKyouxEQiq0ki6VWBdQrG+njct7o3dcqfTDRAuIO56xFMbRaqAY6KBTz9A2QoyAAUQYuKn/3Nh3uPql1zfrZXykxKxkxEE/p1nyibBEmCGGgeiZdjZcRtciMEx3X4jJfZ+ln0i2AdUhZo0iGfm2fpMvTxCpu5ePl26FQSb3gQ== ;{id = 53985} ;rrset 61668 1 1 11 5 k.cctld.us. 61668 IN A 156.154.128.70 k.cctld.us. 61668 IN RRSIG A 8 3 86400 20220408144101 20220309140106 53985 us. kBqXLarawEcIsC7kkCXWRPH1gOvNqPWu7R4NdTtqmBw/YUrsW08ay8qDEEiwxxUwSf0aNYfs9s8axMdRbwBQus5QqrFHYbpMpM0I9nzERGyVuAR/oQvVB26pSbxZmnV90ArxwCQw9bo2jiNsUo7MfZFKvNBeT9BfGUQ+ZbqHe6smhBf7cGAKdE9kf7EvgaS6d6yBFFh8PzZfTpnD0NAiqg== ;{id = 53985} ;rrset 61668 1 1 11 5 k.cctld.us. 61668 IN AAAA 2001:503:e239::3:1 k.cctld.us. 61668 IN RRSIG AAAA 8 3 86400 20220408144101 20220309140106 53985 us. s+WQGNcSZUpTGGfo8ZGMy3NQmaxKXG8ic0iNWjXPPHiC51sF0UIjJEZYao4Dq482KxKz+RPvWQX8V5Bcj4BSCkTq1Jw53N5DaTURK73oVOTPUbDwHTLzygr9oXMEbRWXHfc/Io7GP3PJU+Yod7Jqqmi5+atLlG3CnG0C3Lw0yCUjA5XFKK8pozVbASRX8x4xvYEH2Yg2PZ+PT29JPr2NLw== ;{id = 53985} Delegation with 6 names, of which 0 can be examined to query further addresses. It provides 12 IP addresses. 2001:503:e239::3:1 rto 376 msec, ttl 454, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 156.154.128.70 rto 164 msec, ttl 661, ping 4 var 40 rtt 164, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2001:dcd:2::15 rto 376 msec, ttl 666, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 37.209.194.15 rto 89 msec, ttl 377, ping 9 var 20 rtt 89, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2001:502:ad09::29 rto 376 msec, ttl 454, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 156.154.125.70 rto 138 msec, ttl 454, ping 6 var 33 rtt 138, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2001:dcd:3::15 rto 376 msec, ttl 666, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 37.209.196.15 rto 195 msec, ttl 666, ping 3 var 48 rtt 195, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2001:dcd:1::15 rto 376 msec, ttl 377, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 37.209.192.15 rto 191 msec, ttl 653, ping 15 var 44 rtt 191, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 2001:500:3682::11 rto 376 msec, ttl 666, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 209.173.58.70 rto 115 msec, ttl 377, ping 7 var 27 rtt 115, tA 0, tAAAA 0, tother 0, EDNS 0 probed. [22.01-RELEASE][admin@sg4860.local.lan]/root:That bottom info there when you ask unbound is information on it talking to those different NS, rto, response time, etc.. This is how it figures out the best NS to talk to for any domain.. The ones that answer the fastest, is who is going to ask first next time it gets a query for that domain that isn't cached, etc.
while those other domains like apple.us and google.us will end up pointing to their own NS, to find those name servers you have to go ask cctld servers..
If your having issues talking to cctld servers you would have looking up really any CC domain that use them - like cloudflare.us for example - does that resolve?
$ dig cloudflare.us +short 104.21.80.121 172.67.181.11 -
@johnpoz @stephenw10 Sorry about my delay getting back to you today. In my preoccupation with everything going on yesterday I forgot that I had a root canal scheduled this morning so I wasn't able to get an early jump on this issue today.....nothing related to roots is working for me right now!
I got back a little while ago and read through John's post. Regarding floating rules this is the only one I have:
It shouldn't be an issue for what I have going on.I can confirm that in running the tests from John's last post I was not able to resolve any .us domain. However, (drum roll) I think I have figured out the issue.
I've been using a VPN provider, IVPN, for about the last 5-6 years. I have unbound set up to route all the DNS request out through 3 simultaneous wireguard connections to 3 of their servers located in different states and housed in differently owned datacenters. It has worked perfectly over all these years (originally via OpenVPN and then via wireguard when the wireguard package came out (v2.5.2 ?)
I remember reading on these forums about another VPN provider that does DNS hijacking. So I thought that I would route my DNS requests out of unbound through my ISP just in case they implemented some new DNS policy that was blocking me.
As soon as I switched the routing out through my ISP, Verizon, everything works perfectly. I can surf to, and resolve, any .us domain.
I've reached out to IVPN and asked them if they were aware of any DNS issues with .us roots or if they had implemented any type of DNS hijacking. The said they are not aware of any .us roots issues and do not implement any blocking of any king unless you use their DNS with adblocking (which I don't.)
The suggested that it was probably something in my pfsense config. I told them that I didn't believe was the case based on our in-depth troubleshooting. I referred them to this post so they could see what we have done and suggested that they look at the servers that I've been using to see if they can find any issues.
The funny thing is, I have a remote site that is also using unbound through IVPN on a pfsense box. However, unlike my setup I've never upgraded the connections to IVPN to wireguard, they are still OpenVPN. That site is not experiencing any .us issues at all.
In looking back at the DNS error log screenshots they all indicated that the DNS queries that failed were TCP packets. That's got me wondering why that would be if I was using wireguard, which is all UDP, to route all those DNS queries? It seems like unbound didn't get a response back in time to the UDP query so unbound then tried to send a TCP query out. But that query would have been routed out the IVPN wireguard tunnels and wireguard was the thing that denied the request because it was TCP. So what happened to the original UDP query?
Not sure if that means there may be an issue/bug between unbound and wireguard, or something else. That's way above me. But I'm happy to help in any way that I can if you need me to.
Thanks again to both of you. I never would have figured this out on my own unless I would have stumbled on it by dumb luck.
-
@dma_pf said in Zoom Blocked, Completely Stumped.:
wireguard was the thing that denied the request because it was TCP
huh? Wireguard would be completely useless if didn't allow tcp.. While the tunnel itself is UDP, and it doesn't support TCP tunnel. Same goes with openvpn default tunnel is UDP.. But you can run a TCP tunnel connection if you want. That has nothing to do with the traffic and protocol of the traffic inside the tunnel.
So did you validate that you actually did get a response to your UDP queries - they were just too late? It could be that the VPN isn't blocking anything but its possible the cctld servers are blocking the VPN IP?
Glad you got it sorted in the long run.. Sure wish you were running vpn early in the thread, would of for sure had you check without that really early.. Would of saved time - reminder to self!! First question to ask on any thread - are you using vpn ;) If so turn it off for testing..
-
Mmm, are you routing only UDP DNS queries via VPN maybe?
Anyway, yeah, glad you were able to 'resolve' it!
-
@johnpoz @stephenw10 I've done some more troubleshooting and have an update on this issue.
When using unbound in pfsense with its default settings (not in forwarding mode) the inability to resolve the .us sites is directly related to the use of DNSSEC. If I toggle DNSSEC on (default setting) I can't resolve any .us domain when unbound is set to route those DNS queries through the IVPN wireguard vpn tunnel. With DNSSEC off they all resolve correctly.
As I mentioned previously, this is only an issue when unbound is routed out through IVPN's servers. It works perfectly when routed out through my ISP. I've also noticed that the same issue is happening with .biz sites. Why it was working before last Tuesday is beyond me.
If I have DNSSEC enabled and configure a custom option in unbound for a specific site like this:
domain-insecure: "zoom.us"
then that particular site will resolve correctly while all other .us and .biz sites will fail.
In reviewing these (b.cctld.us & a.gtld.biz are one of the roots for .us & .biz):
https://dnsviz.net/d/b.cctld.us/dnssec/
https://dnsviz.net/d/a.gtld.biz/dnssec/There are some warnings about the DNSSEC using a SHA-1 digest algorithm which is prohibited. But there is also a SHA-2 digest algorithm available which should work.
I'm continuing to work through this issue with IVPN's tech support but thought I'd update you guys in case you had any ideas. I'll keep you posted.
-
@dma_pf they really should clean up the sha1 stuff, but your right they really mean nothing with the other algo available and setup.
-
@johnpoz @stephenw10 I've been doing some more troublshooting on this issue. The main failure I see is based on running dig on a .us site. When I have DNSSEC disabled in unbound'ss settings is works perfectly. When I enable DNSSEC it always fails like this:
<<>> DiG 9.16.23 <<>> cloudflare.us +trace ;; global options: +cmd . 36069 IN NS f.root-servers.net. . 36069 IN NS j.root-servers.net. . 36069 IN NS l.root-servers.net. . 36069 IN NS b.root-servers.net. . 36069 IN NS e.root-servers.net. . 36069 IN NS k.root-servers.net. . 36069 IN NS a.root-servers.net. . 36069 IN NS h.root-servers.net. . 36069 IN NS c.root-servers.net. . 36069 IN NS i.root-servers.net. . 36069 IN NS g.root-servers.net. . 36069 IN NS m.root-servers.net. . 36069 IN NS d.root-servers.net. . 36069 IN RRSIG NS 8 0 518400 20220406170000 20220324160000 9799 . gyfGHVhZgBScIWZRPOubqW56HLKyOdryQbrySv+Kc9qMN/cCEWkas7mg un6kOp0qxoyz16s7qU7yZ8JagcMYGOA+9VnOi9sf2RdKWAf16mkLQESf tOenLagm1HSsR0DPgq0KEm+Hk7hPc+kCSVAn7+jg4tgS5O9tHuOrZJvy E2CCCeZgNyGuTbbtJ7ZH3zp5M4mRcklHIEWb+NBWb54Q7x5tO5VTqccI +yJa1nptKaZpB+XyrAd99lNR0kpgMc5R5R+JHA5hp7KjLus8cbkFrdVX 7tshJ6+gxxo/L0ob0udqsmtqfzrwb7eWYy9etdHtezoDc18O8n62thfr Xqunsg== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms us. 172800 IN NS b.cctld.us. us. 172800 IN NS f.cctld.us. us. 172800 IN NS k.cctld.us. us. 172800 IN NS w.cctld.us. us. 172800 IN NS x.cctld.us. us. 172800 IN NS y.cctld.us. us. 86400 IN DS 21364 8 1 260D0461242BCF8F05473A08B05ED01E6FA59B9C us. 86400 IN DS 21364 8 2 B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26 us. 86400 IN RRSIG DS 8 1 86400 20220407050000 20220325040000 9799 . KQHw5nUUnQFiykOB42BfON4ZoGRTooGMk0KbQzVuYDEn+tt2CLrN0kQ+ UtvM4gblgQLTa0JSBN1VkN3o52TJlSGvLkt9ZxI8y3iB67gsHm9RQQil h9ndmW2laUhoYEUqDPV3FCi2+cziATxzZwD4RbLJV9gc3oWjXmUR+Mj+ j09NYiG4//89Z46TlguQ6yveNgCvWUR3nJgM58JPVpyqOWdKTQTC76jR ZMidFe6+qjgL3AP3ZOnxLnV4Wn2dGcVnq/dByuGB/ltKGhkTaAotC6lT MqNt86YRfop6qvqRr9KhPOBTm4GRWKcxf8P4sRv7Pf0XZ9fdBL3GlWKp 11n8lw== couldn't get address for 'b.cctld.us': not found couldn't get address for 'f.cctld.us': not found couldn't get address for 'k.cctld.us': not found couldn't get address for 'w.cctld.us': not found couldn't get address for 'x.cctld.us': not found couldn't get address for 'y.cctld.us': not found dig: couldn't get address for 'b.cctld.us': no moreSo I decided to do a pcap of a dig to cloudflare.us with DNSSEC disabled and enabled. Here's what I got with DNSSEC disabled (172.24.94.115 is my VPN wireguard tunnel):
And when I do the pcap with DNSSEC enabled here's what I get:
I'm not sure what is going on but it certainly looks to me that the root servers for .us were resolved and they definitely provided the address of the authoritative name servers (nsx.cloudflare.com) for cloudflare.us. So why does dig say it can't get the address for the .us root servers?
When I dig cloudflare.us via one of the nsx.cloudflare.com servers it works perfectly:
; <<>> DiG 9.16.23 <<>> @162.159.4.8 cloudflare.us ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44351 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;cloudflare.us. IN A ;; ANSWER SECTION: cloudflare.us. 300 IN A 104.21.80.121 cloudflare.us. 300 IN A 172.67.181.11 ;; Query time: 12 msec ;; SERVER: 162.159.4.8#53(162.159.4.8) ;; WHEN: Fri Mar 25 08:27:57 EDT 2022 ;; MSG SIZE rcvd: 74 -
@dma_pf if your forwarding, dnssec should not be enabled.
where your forwarding to is either doing dnssec already, or its not - telling unbound to do dnssec isn't going to magically make were you forwarded to do dnssec.
I have gone over this multiple times, there is zero reason to have dnssec set when your forwarding.. It is only viable setting when your resolving.
You have no idea what some forwarder your sending to might send in response for the dnssec. Only when you talk to the actual authoritative NS is checking dnssec valid.
edit: example. cloudflare does dnssec out of the box. here is know fqdn that fails dnssec.
$ dig @1.1.1.1 www.dnssec-failed.org ; <<>> DiG 9.16.27 <<>> @1.1.1.1 www.dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39572 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.) ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 52 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Fri Mar 25 07:44:02 Central Daylight Time 2022 ;; MSG SIZE rcvd: 107See no answer - if I query a NS that is not doing dnssec.
$ dig @4.0.0.53 www.dnssec-failed.org ; <<>> DiG 9.16.27 <<>> @4.0.0.53 www.dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24722 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 8192 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; ANSWER SECTION: www.dnssec-failed.org. 7200 IN A 68.87.109.242 www.dnssec-failed.org. 7200 IN A 69.252.193.191 ;; Query time: 152 msec ;; SERVER: 4.0.0.53#53(4.0.0.53) ;; WHEN: Fri Mar 25 07:50:38 Central Daylight Time 2022 ;; MSG SIZE rcvd: 82 -
@johnpoz said in Zoom Blocked, Completely Stumped.:
@dma_pf if your forwarding, dnssec should not be enabled.
Hey, I'm not forwarding. I"m just routing the dns queries out through a vpn instead of my ISP. Here's my settings:
-
@dma_pf you have dnssec enabled and you don't get valid dnssec then no you wouldn't be able to use that answer..
If for whatever reason dnssec is failing when resolving through your vpn, and you have dnssec enabled, then no you wouldn't get an answer.
A simple trace shouldn't/wouldn't be enforcing dnssec.
If when you do a +trace through your vpn it fails - then the issue is on your vpn, or they they are being blocked, etc. Or maybe they are intercepting your dns - you know for your own good and safety ;)
edit: doing a +trace to a known bad dnssec fqdn, works just fine via trace.
$ dig www.dnssec-failed.org +trace ; <<>> DiG 9.16.27 <<>> www.dnssec-failed.org +trace ;; global options: +cmd . 16946 IN NS a.root-servers.net. . 16946 IN NS b.root-servers.net. . 16946 IN NS c.root-servers.net. . 16946 IN NS d.root-servers.net. . 16946 IN NS e.root-servers.net. . 16946 IN NS f.root-servers.net. . 16946 IN NS g.root-servers.net. . 16946 IN NS h.root-servers.net. . 16946 IN NS i.root-servers.net. . 16946 IN NS j.root-servers.net. . 16946 IN NS k.root-servers.net. . 16946 IN NS l.root-servers.net. . 16946 IN NS m.root-servers.net. . 16946 IN RRSIG NS 8 0 518400 20220406170000 20220324160000 9799 . gyfGHVhZgBScIWZRPOubqW56HLKyOdryQbrySv+Kc9qMN/cCEWkas7mg un6kOp0qxoyz16s7qU7yZ8JagcMYGOA+9VnOi9sf2RdKWAf16mkLQESf tOenLagm1HSsR0DPgq0KEm+Hk7hPc+kCSVAn7+jg4tgS5O9tHuOrZJvy E2CCCeZgNyGuTbbtJ7ZH3zp5M4mRcklHIEWb+NBWb54Q7x5tO5VTqccI +yJa1nptKaZpB+XyrAd99lNR0kpgMc5R5R+JHA5hp7KjLus8cbkFrdVX 7tshJ6+gxxo/L0ob0udqsmtqfzrwb7eWYy9etdHtezoDc18O8n62thfr Xqunsg== ;; Received 525 bytes from 192.168.9.253#53(192.168.9.253) in 0 ms org. 172800 IN NS a0.org.afilias-nst.info. org. 172800 IN NS a2.org.afilias-nst.info. org. 172800 IN NS b0.org.afilias-nst.org. org. 172800 IN NS b2.org.afilias-nst.org. org. 172800 IN NS c0.org.afilias-nst.info. org. 172800 IN NS d0.org.afilias-nst.org. org. 86400 IN DS 26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32 org. 86400 IN RRSIG DS 8 1 86400 20220407050000 20220325040000 9799 . bHjx5Zh1LhyXZu7KZHF0wXhi+yPC4s7lo8F97VuIz1pA6xWcYlsajuMG ijIbfvxShH0ZJajbvRqOSn4IUEfiNbROioMXR99RgtITWyZGravqpQTf pzVXPEj9wnhc+PIUAXGZgvxhCNK8IqMXC0wYoAbL7Fblyztt4bL4a2Sn YO0FjU4giBfN1n3nYv7WANiZuflvSxaNGRfwn4Y8ZH2Fdxd2RpO9BJ13 TWLE9GLCysvRdIc6lXMaeQUHoYLFRrslQqhvwgS2zWICjp8IZJWigCEW PPxPp3sPTkj9b7e8h9aqyo3dLxSn1QfNQzXeh2abVXkYuoawz0YSfEiz HUh+pQ== ;; Received 857 bytes from 199.9.14.201#53(b.root-servers.net) in 34 ms dnssec-failed.org. 86400 IN NS dns101.comcast.net. dnssec-failed.org. 86400 IN NS dns102.comcast.net. dnssec-failed.org. 86400 IN NS dns105.comcast.net. dnssec-failed.org. 86400 IN NS dns103.comcast.net. dnssec-failed.org. 86400 IN NS dns104.comcast.net. dnssec-failed.org. 86400 IN DS 106 5 2 AE3424C9B171AF3B202203767E5703426130D76EF6847175F2EED355 F86EF1CE dnssec-failed.org. 86400 IN DS 106 5 1 4F219DCE274F820EA81EA1150638DABE21EB27FC dnssec-failed.org. 86400 IN RRSIG DS 8 2 86400 20220407152430 20220317142430 30573 org. BRGLDVHxuTSAGicYgDopMTVGH8FGCPEHp8dhxq63rmZTBQHPxRU+FaWh 3OIPOS6LrEEv9ferIcvUkgCEig4yxQTChAr8Jqcwe/Gvzd6FGDHIXwGK qqCsd4VY/p70Spk6xL6xValE7YQhl1XFxvM3D1kBM40qSKKF1gVCCpVV C4M= ;; Received 413 bytes from 199.19.53.1#53(c0.org.afilias-nst.info) in 36 ms www.dnssec-failed.org. 7200 IN A 69.252.193.191 www.dnssec-failed.org. 7200 IN A 68.87.109.242 www.dnssec-failed.org. 7200 IN RRSIG A 5 3 7200 20220404145103 20220318144603 44973 dnssec-failed.org. uHA7l/1qYhntcwtNUSxVi4OlD+2w0nUrridzTrPgPCO6K6rrqO9RBa0M bgJQgJ4mpYEKKEgE3+GlbLZ0uSCIR/XDtnRaHYLnXBlb9pW0Qw3Vk5Zx l595g+ATQfY6ZK4qlxMx8bKNIM+KuPxTJvqTbFvNYyqP/TZl92sYnHRk tCs= ;; Received 259 bytes from 68.87.68.244#53(dns104.comcast.net) in 38 msanother known bad broken dnssec for testing
$ dig @1.1.1.1 www.brokendnssec.net ; <<>> DiG 9.16.27 <<>> @1.1.1.1 www.brokendnssec.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9205 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for brokendnssec.net.) ;; QUESTION SECTION: ;www.brokendnssec.net. IN A ;; Query time: 22 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Fri Mar 25 08:09:49 Central Daylight Time 2022 ;; MSG SIZE rcvd: 105If I just do a simple trace to that it works.
$ dig www.brokendnssec.net +trace ; <<>> DiG 9.16.27 <<>> www.brokendnssec.net +trace ;; global options: +cmd . 16685 IN NS a.root-servers.net. . 16685 IN NS b.root-servers.net. . 16685 IN NS c.root-servers.net. . 16685 IN NS d.root-servers.net. . 16685 IN NS e.root-servers.net. . 16685 IN NS f.root-servers.net. . 16685 IN NS g.root-servers.net. . 16685 IN NS h.root-servers.net. . 16685 IN NS i.root-servers.net. . 16685 IN NS j.root-servers.net. . 16685 IN NS k.root-servers.net. . 16685 IN NS l.root-servers.net. . 16685 IN NS m.root-servers.net. . 16685 IN RRSIG NS 8 0 518400 20220406170000 20220324160000 9799 . gyfGHVhZgBScIWZRPOubqW56HLKyOdryQbrySv+Kc9qMN/cCEWkas7mg un6kOp0qxoyz16s7qU7yZ8JagcMYGOA+9VnOi9sf2RdKWAf16mkLQESf tOenLagm1HSsR0DPgq0KEm+Hk7hPc+kCSVAn7+jg4tgS5O9tHuOrZJvy E2CCCeZgNyGuTbbtJ7ZH3zp5M4mRcklHIEWb+NBWb54Q7x5tO5VTqccI +yJa1nptKaZpB+XyrAd99lNR0kpgMc5R5R+JHA5hp7KjLus8cbkFrdVX 7tshJ6+gxxo/L0ob0udqsmtqfzrwb7eWYy9etdHtezoDc18O8n62thfr Xqunsg== ;; Received 525 bytes from 192.168.9.253#53(192.168.9.253) in 0 ms net. 172800 IN NS d.gtld-servers.net. net. 172800 IN NS b.gtld-servers.net. net. 172800 IN NS m.gtld-servers.net. net. 172800 IN NS f.gtld-servers.net. net. 172800 IN NS j.gtld-servers.net. net. 172800 IN NS h.gtld-servers.net. net. 172800 IN NS e.gtld-servers.net. net. 172800 IN NS c.gtld-servers.net. net. 172800 IN NS k.gtld-servers.net. net. 172800 IN NS a.gtld-servers.net. net. 172800 IN NS l.gtld-servers.net. net. 172800 IN NS i.gtld-servers.net. net. 172800 IN NS g.gtld-servers.net. net. 86400 IN DS 35886 8 2 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE net. 86400 IN RRSIG DS 8 1 86400 20220407050000 20220325040000 9799 . UrzwQwWNcq9u0myT+qF2mh+UqTlruBiVrky5qqFQQhVzhqVntGnLSIcx LsvKmEoEnfLlk//+4Z/KiYs9aPa0eNE+EJF5mwbICaioWaISIgsLUTGm r9aYGa9Pz6PVNF7YDRWUGwWUZoLcCMis1edFcJ2R77xEyke6Fl6xOu+n Sd2frWsljUBDnkwM2PJmEa6sJ7Zz7MJwfOvkx8lmY8Rxt4rEreJwC9AL i/uT7xqfcKSnILnSCCU1zK5CfALgp18W5napODTL/BGbqDpg2otiT27F ATBvJDypuITUyW/10JGmrG2O9PMisKSu8UQpL4x0kKYW1ogvZR8Qzll6 dqs/Lw== ;; Received 1205 bytes from 192.33.4.12#53(c.root-servers.net) in 13 ms brokendnssec.net. 172800 IN NS carl.ns.cloudflare.com. brokendnssec.net. 172800 IN NS cruz.ns.cloudflare.com. brokendnssec.net. 86400 IN DS 2371 8 2 173EA96867879929EEEB7C6D245D2472C266043EB596370AEBC7D2CC A43EE84F brokendnssec.net. 86400 IN RRSIG DS 8 2 86400 20220330054835 20220323043835 4604 net. ICXWkr5UveQu5ee9fDesJi4zOcc6T+jsbEBZGF8r+DblC+H/VSJHnDCl z3VF1NMV7l6Pp4aQQArFhHYJAqUBybGpiooFMc/U8Fe2rIU/4AXyFoM5 gP6uln422vxLEY2OxVzSsfkBgNj0p2rAcvLs4Bng5oQ1FjtnUNIDodhQ 61R03nKsYsme9ocA0MF3J9W7PAbPeZNRmfTIBVdsxu1hzg== ;; Received 347 bytes from 192.54.112.30#53(h.gtld-servers.net) in 24 ms www.brokendnssec.net. 300 IN A 104.22.35.212 www.brokendnssec.net. 300 IN A 104.22.34.212 www.brokendnssec.net. 300 IN A 172.67.36.129 ;; Received 97 bytes from 172.64.32.88#53(cruz.ns.cloudflare.com) in 20 ms -
@dma_pf here are some tests you might want to do to see if your isp is intercepting your dns..
so query a specific authoritative NS for a record - say www.google.com to one of the actual google ns.. You should see aa in the response field showing that it was an authoritative response..
Notice when I just ask some other NS for www.google.com I do not see the aa in the flags.. This means was not an authoritative response.. This points to dns being intercepted if you don't see the aa when doing a directed query to specific authoritative name server.
Another simple test to see if all dns is being intercepted is just do a query to some IP you know for sure isn't actually running dns.
So for example 1.2.3.4 sure and the hell is not providing dns.. But if its being redirected - sure looks like it is. So a quick test to see if all dns is being redirected is to just do a directed query to some IP you know for sure is not providing dns services - if you get a response, then your dns is being intercepted.
another sign of interception is when you query an authoritative ns for a record it is authoritative for.. You would get back the full TTL.. Notice I got a 300 back when I asked ns1.google.com for www.google.com, but when I asked another ns I got back some odd ttl.. That was something lower than the actual ttl - since it was from cache and not from the actual authoritative NS..
Another possible hint of dns shenanigans is odd response times. Lets say 1.2.3.4 was actually some dns I could talk too.. But look at the response time I got back, 0 (since my redirection is local).. But if through some vpn while a query to maybe 1.2.3.4 might take 40ms, if your seeing much lower response time than what would be normal - that points to dns interception as well.
There are many clues to look for to see if your isp or vpn is messing with your dns..
