DNS Resolution issues


Go to solution Solved by groot-stuff,

Recommended Posts

I am running into the same issue multiple people are having here, I have read over a dozen threads both old and new. Nothing is working, please don't give me the "it's your network response".

 

When attempting to load the CA tab I get this error:

Quote

Something really wrong went on during get_categories
Post the ENTIRE contents of this message in the Community Applications Support Thread

No data was returned. It is probable that another browser session has rebooted your server. Reloading this browser tab will probably fix this error

 

That is only one symptom, I have the other symptoms other's have described:

- Intermittent access to CA list (occasionally it loads, most often it times out after 60 seconds)

 

- Docker containers show version "not available"

- Forcing the update of a Docker container causes the icon to disappear and show the ? one

- When a Docker is missing an icon, loading the Docker tab takes 15 seconds (research shows this is the standard timeout, down from 60 in the past)

    - I learned how to manually resolve this (where to save the image files and naming convention) 

 

- Commands with IPs such as "ping 172.217.12.14" (google.com's ip address) come back instantly

- Commands with domains such as "curl ifconfig.io" and "ping google.com" take 10-14 seconds to return anything (ip address or start pinging the ip)

- These same commands run instantly, as expected, when run in ANY docker's shell

    - So we know the network card and subnet/firewall is capable

- Commands and speed tests run on a fresh W10 VM are instantaneous and pull my full gig bandwidth

    - So we know the network card and subnet/firewall is capable

 

Facts and attempted resolutions:

- I have rebooted numerous times, re-logged-in through a new browser with cache cleared, re-logged-in through SSH

- IPv6 is disabled on unraid and my firewall

- I setup letsencrypt docker with reverse proxy a few weeks ago, everything worked fine, still does

    - This required setting up a custom Docker network (proxynet, as instructed in SpaceInvaderOne's video)

        - That network has a metric of 1 in my ip routes, whereas my eth0/br0 subnet always has a 200+ metric

        - I don't know how to change the new Docker network (br-b579...) to a higher metric... could this be the cause?

image.thumb.png.fb756cafb2f22cda2ee523103bee0624.png

        - When Docker is enabled the 172.17.0.0/16 docker0 network shows up with a metric of 1, same symptoms (no dockers use it, all are on proxynet)

image.thumb.png.694a4c60a561861ee263d1cc48925a61.png

        - Screenshot above also has the "optional metric" for my eth0/br0 IPv4 gateway set to 1, yields the same symptoms

 

    - Only recent change is converting the letsencrypt container to swag (name, appdata folder and mapping, repo and icon url were all updated)

    - swag works fine, websites and dockers are all accessible as they were before (I only mention this because it is the only recent change)

 

- No changes to IP scheme, masks or dns servers (the firewall provides ip/mac bound address and open dns servers)

- DHCP and Static configurations yield the same symptoms

    - Yes I am using the correct mask, gateway and multiple DNS providers (open dns, google, and cloudfare)

- I have tried with bonding/bridging: on/on, off/on, off/off  (respectively)

- I have tried with Docker/VM manager on and off

- I have regenerated the /boot/config/network.cfg file and resolvr.conf (forget what path that one was at) - both update in response to changes in Settings > Network (evidenced by cat /boot/config/network.cfg and cat resolvr.conf)

 

- I can ping: 127.0.0.1, 10.3.55.2 (server's IP), 10.3.55.1 (gateway), both ISP's modems LAN address and my WAN IP without issue... it's when I try to ping, traceroute or curl a domain name that it hangs 10+ seconds

 

- Tracing the route to my default gateway though... doesn't work from unraid but it comes back as expected on any other VM or machine on the network

image.png.15a8d7937935a1f1ff36020062f0baa4.png (from VM on same subnet, 10.3.55.7)

image.png.c60305dff961d5242c597f2d7fad574b.png(from unraid console via ssh as root)

 

So I really need some help here folks. I've attached what I thought would be helpful... let me know if other info is needed to help.

After 8 hours of reading threads and troubleshooting I am at a loss.

 

 

Edited by SidereusAquila
removed diagnostic files, due to privacy concerns
Link to comment
57 minutes ago, SidereusAquila said:

"it's your network response".

TBH, hard not to as it certainly appears to be that

 

57 minutes ago, SidereusAquila said:

- Commands with IPs such as "ping 172.217.12.14" (google.com's ip address) come back instantly

- Commands with domains such as "curl ifconfig.io" and "ping google.com" take 10-14 seconds to return anything (ip address or start pinging the ip)

- When a Docker is missing an icon, loading the Docker tab takes 15 seconds (research shows this is the standard timeout, down from 60 in the past)

    - I learned how to manually resolve this (where to save the image files and naming convention) 

That's where it's very interesting.

 

Every download request in CA has a connection timeout of 15 seconds, and a total download time (including connection) of 45 seconds.  The docker icon system also uses identical timeouts.  Reasoning on this is that if the system can't connect in 10 seconds, then why bother waiting the entire 45 seconds as it'll probably fail anyways

 

But, I just issued a release of CA that has the connection timeout removed to see if it helps alleviate some of these issues, specifically if this improves

57 minutes ago, SidereusAquila said:

- Intermittent access to CA list (occasionally it loads, most often it times out after 60 seconds)

 

 

 

Link to comment
39 minutes ago, Squid said:

And although you do imply you did this, have you explicitly set DNS addresses within Settings - Network Settings?  Same result?

Same results even when using open dns (what I usually use, firewall assigns them to devices rather than itself). Same with google and cloudflare dns servers - all statically set in Settings > Network.

 

Regarding "it's not my network" -

I let my OP be open-ended, but I feel it is ip routing or dns resolution.

Just not the network numbers I'm typing in or configuration of my firewall. Literally nothing has changed on that side, and connection requests from dockers and vms are unaffected.

 

Edit: also no pfsense or other proxys between the unraid box and WAN.

 

Thoughts on my ip routes and traces? I have nothing to compare them to, nor have I ever recorded the same in the past. They are only what unraid generates, aside from the metric = 1 for the IPv4 gateway I set in the gui when troubleshooting.

 

The 14-16 second curl ifconfig.io response is very consistent, same time span for a domain name ping to start hitting the resolved ip.

Could it be attempting to route through the 172.18 docker network then falling back to eth0/br0?

Edited by SidereusAquila
Link to comment
1 hour ago, Squid said:

TBH, hard not to as it certainly appears to be that

 

That's where it's very interesting.

 

Every download request in CA has a connection timeout of 15 seconds, and a total download time (including connection) of 45 seconds.  The docker icon system also uses identical timeouts.  Reasoning on this is that if the system can't connect in 10 seconds, then why bother waiting the entire 45 seconds as it'll probably fail anyways

 

But, I just issued a release of CA that has the connection timeout removed to see if it helps alleviate some of these issues, specifically if this improves

 

 

I updated CA and it loads now, under 30 seconds on the few tries I did. 

Still have the same slow response on curl, ping and traceroute requests on the host, dockers are still ok.

Link to comment
  • Solution

@Squid I understand you aren't a networking guru, but thank you very much, I really appreciated your instant CA update to help me troubleshoot.

After a nice hike yesterday and good night's sleep, I banged my head on the keyboard some more this morning.

 

I would hate coming to a thread with a similar or same issue... read through and it ends without a resolution. I would equally hate a final post from the OP saying "Never mind, I fixed it." because it doesn't help the next person that a Google search lands here.

 

Request:

I am a not a networking expert and would LOVE someone who is - to take a stab at why this resolved the issue... despite no changes being made to the router or unRaid network config that would have caused it.

 

So further down the troubleshooting rabbit hole:

- I stopped the array, same symptoms

    - I tested this because of reading posts about unRaid gui latency being caused by failing disks

 

Next I dug through my mental cobwebs and found my 20 year old, uncertifed CCNA knowledge... along with many web articles, some linked below.

Quote

To install more networking CLI tools:

    - Install the Nerd Tools/Nerd Pack plugin

    - Go to Settings > Nerd Pack

    - Install bind and lmdb (that is Lmdb)

You will now have the dig command, similar to nslookup in Windows

I'm not sure if tcpdump is available natively in unRaid - but those are the only two packs I installed for this troubleshooting

- dig [anyDomainName.TLD] came back instantaneously... SO STRANGE, as here I am thinking unRaid is having DNS request time outs

    - This command allowed me to learn that my docker containers are using 127.0.0.11 as their DNS server... hence why docker containers had no symptoms 

    - Resource: https://www.google.com/amp/s/www.hostinger.com/tutorials/how-to-use-the-dig-command-in-linux/amp/

 

So I ran tcpdumps on these various commands (curl, ping, traceroute and even clicking on the CA apps tab) to observe what is sent/received

Quote

An easy way to explore tcpdumps (.pcap files) is using WireShark - https://www.wireshark.org/#download

    - Not an advertisement... I just want to ensure any reader can replicate my research, if they so desire

    - Other Resources: https://opensource.com/article/18/10/introduction-tcpdump and https://danielmiessler.com/study/tcpdump/

 

Quote

tcpdump command and options/filters I used to clean up the capture

- command: tcpdump -i any -nn -t -e dst not [IPofMachineYouAreOn] and src not [IPofMachineYouAreOn] -w [filename.pcap]
    - options: -i any (all interfaces), -nn (tcpdump tool will not do dns lookups), -t (user readable timestamps), -e (also get ethernet header)

    - filters: dst not [IPofMachineYourAreOn] and src not [IPofMachineYouAreOn] (filter out packets to/from the machine you are connected to unraid from)

    - output: -w [filename.pcap] (write to filename.pcap, .pcap is the standard extension for packet captures)

Tip: stopping dockers, vms and other processes that create network traffic is crucial to this effort as well

 

Digging into tcpdump of "curl ifconfig.io"

    - unRaid settings: external DNS servers statically assigned in Settings > Network (open DNS = 208.67.220.220 and 208.67.222.222)

    - The traffic (packets) going from point A to B were just fine, quick as it should be... but something was slowing the overall request down
    - 106 packets over 15 seconds
    - 33 of those were ARP requests to my local router asking "who has [myPublicIP]?

        - This got me curious... why is unRaid continually trying to figure out that my router is the next layer 2 (mac address) hop to my public IP?

 

Digging into ARP requests

- Resource: https://osqa-ask.wireshark.org/questions/5412/what-does-arp-42-who-has-19216811-tell-192168133-mean

- ARP (Address Resolution Protocol) requests are similar to DNS requests but they are IP to MAC resolutions rather than Domain to IP resolutions

- running arp -a was very slow (this shows IP addresses and their corresponding MAC addresses)
- running arp -an (no DNS lookups) was instantaneous
    - Surprisingly this is the same after resolution, but it makes sense because DNS requests of each local subnet IP and 172.18.X.X docker subnet IP fail

 

Quote

TLDR Resolution

Since unRaid kept asking my router where my public IP was and being a novice...

I figured what the heck, lets set the first DNS server in unRaid > Settings > Network to my router

- BAM! curl requests are now instantaneous, checking for plugin updates takes ~5 seconds, loading CA tab takes 2-3 seconds

- This was exactly the opposite of SO many threads I have read... they all suggested removing the local router as a DNS server

 

Honestly, this isn't a favorable solution... as I have always preferred assigning each machine external DNS servers and avoiding the local router

 

Digging into tcpdump of "curl ifconfig.io" with local router as the first DNS server

    - unRaid settings: local router and external DNS servers statically assigned in Settings > Network

        - local router as #1, then open DNS = 208.67.220.220 and 208.67.222.222 as #2 and #3)

    - 42 packets (64 less) over less than 1 second (14 less)
    - None of those (33 less) were ARP requests to my local router asking "who has [myPublicIP]?

 

Symptom Resolution:

    - CLI requests to WAN resources are instantaneous (as expected)

    - Plugins tab loads in ~5 seconds (background update checks are enabled)

    - CA tab loads in 2-3 seconds

    - Dockers update and retain icon image

    - Fix Common Problems plugin scans within 15 seconds now (took multiple minutes before)

 

Unresolved symptoms:

    - Docker's still show version "not available"

        - Forcing an update resolves this, but I am going to wait overnight to see if the scheduled update check resolves it (will post again tomorrow)

        - UPDATE (same day): I triggered a manual check for docker updates and about 15-20 seconds later all 17 of my dockers had no more "not available"

    - traceroutes to my default gateway still fail

 

Quote

So if you are a networking expert... please take a stab at why this resolved the issue! 

Could this be something that a VM, Docker, Plugin or I inadvertently changed in the OS?

Could this be something that a firmware upgrade on my router caused?

Could this be something a power outage caused?

    - I had one last week, albeit momentarily but it was enough to kill my unRaid server and power stayed off until I booted it back up

 

Network devices

ISP: Comcast Gigabit (1g/40mbps) Coax Service

Modem: Arris SB8200

Firewall/Router: ZyXEL ZyWALL VPN100 

    - All traffic from DMZ to WAN is allowed, no firewall filters/rules

    - Only https requests destined for my public WAN IP, hitting the WAN interface are looped back to unRaid machine for internal-only reverse proxy

        - Same configuration as before the issue (working fine for literally years)

        - Same symptoms occur if I disable this rule

Server: unRaid 6.8.3

    - Sits in DMZ subnet

    - Router DHCP provides a MAC/IP bound IP and open DNS server IPs 

        - At the moment DNS servers are statically set in unRaid settings, making zywall first DNS server

 

@Squid So, it was my network... I think? lol

Edited by SidereusAquila
  • Thanks 3
Link to comment
  • 2 months later...

I've had almost identical issues with my setup. I've tried to set my first DNS record as the router (as suggested) but CA still takes 60sec and then timeout. 

 

I've tested ping google.com whilst array is stopped and left it running to check changes when i start the array and it seems to not be able to connect once the array starts.

 

ARP testing below. 

First is with Array Stopped

arp -a took too long to load. 

arp -an was instant. 

curl was slow by successfull

 

Second Image is Array Started

arp -a slow but successfull

arp -an instant

curl failed as you can see. 

 

image.png.ceae2a4cc3325b436d4748eccc0b55e2.png

image.png.30baf7e68624a450b358bf72f545e8c3.png

 

PING

ping requests failed to DNS and IP when array started. Successfull when stopped. 

image.png.ad95595eb5e2afcfc5d4bea8f988f1cb.png

Link to comment

The recommended setup in many other places is to only use public DNS servers and remove all entries for your router. Honestly this is what I prefer, but my new firewall of the same brand is acting subtlety different.

 

So the first thing I would try is using only public DNS servers, i.e. just

208.67.220.220

208.67.222.222

 

Actually... looking closer at your screenshot, your 2nd entry (1st external IP) has a typo (222.220 should be 220.220). Hopefully its that simple, but if not...

 

What do you have starting with the array? I'd suggest testing these independently...

  • Dockers set to auto-start
    • Settings > Docker > Enable: Yes/No
      • If disabling the Docker service works, continue testing by enabling one Docker at a time, testing after each one
  • VMs set to auto-start
    • Settings > VM Manager > Enable VMs: Yes/No
  • UserScripts plugin with a script set to run on array start
    • Change schedule(s) to "Schedule Disabled"

Also think about any other custom scripts or configurations you may have. For example... custom docker networks or ip routing rules.

 

I would also suggest getting into the shell of a docker container and trying the DNS lookups from within it.

     This is where I isolated my issue because the docker network uses a different DNS resolver/address (127.0.0.11 with my config).

 

Guide to setup docker-shell'ing: 

 

Link to comment
  • 2 weeks later...
On 12/1/2020 at 1:09 PM, groot-stuff said:

So the first thing I would try is using only public DNS servers, i.e. just

208.67.220.220

208.67.222.222

 

Actually... looking closer at your screenshot, your 2nd entry (1st external IP) has a typo (222.220 should be 220.220). Hopefully its that simple, but if not...

 

What do you have starting with the array? I'd suggest testing these independently...

  • Dockers set to auto-start
    • Settings > Docker > Enable: Yes/No
      • If disabling the Docker service works, continue testing by enabling one Docker at a time, testing after each one
  • VMs set to auto-start
    • Settings > VM Manager > Enable VMs: Yes/No
  • UserScripts plugin with a script set to run on array start
    • Change schedule(s) to "Schedule Disabled"

Sorry for not responding sooner, i've had a very long 2 weeks and i've done all i can think of to get this working again but having no luck. 

 

I've tested with DCHP from router, tested changing DNS to OpenDNS IP, Google IP and a whole bunch others. Each time i restart the server and check that it's saved correctly. I've tested with the array off and on, it will all seem fine for about 5-10 minutes after changing settings, but then it'll all fail again. 

 

I can't install any application, no dockers show any updates, i've also disabled all the user scripts and ran it with the docker services disabled but it's all the same. Not sure what else to try...?

Link to comment
  • 1 month later...
On 12/13/2020 at 4:41 AM, xxbigfootxx said:

Sorry for not responding sooner, i've had a very long 2 weeks and i've done all i can think of to get this working again but having no luck. 

 

I've tested with DCHP from router, tested changing DNS to OpenDNS IP, Google IP and a whole bunch others. Each time i restart the server and check that it's saved correctly. I've tested with the array off and on, it will all seem fine for about 5-10 minutes after changing settings, but then it'll all fail again. 

 

I can't install any application, no dockers show any updates, i've also disabled all the user scripts and ran it with the docker services disabled but it's all the same. Not sure what else to try...?

Were you able to ever resolve this? I have been having some odd behaviour with network tasts on my server (cannot install or update plugins, stalls at 45% when installing something. I bypassed by ISP router and used a (VERY) old 802.1n router and everything seemed to work fine. Back to the ISP router and back to the same problems. 

Link to comment
35 minutes ago, benyaki said:

Were you able to ever resolve this? I have been having some odd behaviour with network tasts on my server (cannot install or update plugins, stalls at 45% when installing something. I bypassed by ISP router and used a (VERY) old 802.1n router and everything seemed to work fine. Back to the ISP router and back to the same problems. 

Please provide the DNS entries you see when using both of the configurations... the finest details can be the culprit with these types of issues (see my post above for all I went through)

These can be acquired from Settings > Network Settings or the results from cat /etc/resolv.conf at the command line

Edited by groot-stuff
Link to comment
On 12/13/2020 at 3:41 AM, xxbigfootxx said:

Sorry for not responding sooner, i've had a very long 2 weeks and i've done all i can think of to get this working again but having no luck. 

 

I've tested with DCHP from router, tested changing DNS to OpenDNS IP, Google IP and a whole bunch others. Each time i restart the server and check that it's saved correctly. I've tested with the array off and on, it will all seem fine for about 5-10 minutes after changing settings, but then it'll all fail again. 

 

I can't install any application, no dockers show any updates, i've also disabled all the user scripts and ran it with the docker services disabled but it's all the same. Not sure what else to try...?

Did you fix the typo?

See the blue text in my post above

Link to comment
1 hour ago, groot-stuff said:

Did you fix the typo?

 

I resolved the issue by upgrading my router to a newer model and firmware. I'm now having no issues at all. 

 

2 hours ago, benyaki said:

Were you able to ever resolve this? I have been having some odd behaviour with network tasts on my server (cannot install or update plugins, stalls at 45% when installing something. I bypassed by ISP router and used a (VERY) old 802.1n router and everything seemed to work fine. Back to the ISP router and back to the same problems. 

 

As @groot-stuff mentioned, provide the DNS entries. Have you tried with 8.8.8.8 and 1.1.1.1?

Link to comment
21 hours ago, groot-stuff said:

Please provide the DNS entries you see when using both of the configurations... the finest details can be the culprit with these types of issues (see my post above for all I went through)

These can be acquired from Settings > Network Settings or the results from cat /etc/resolv.conf at the command line

I tried my ISP provided ones, 8.8.8.8, 4.4.4.4, 1.1.1.1, various others (open DNS) without any change. Something appears to be messed up on the ISP provided gateway.

Link to comment
1 hour ago, benyaki said:

I tried my ISP provided ones, 8.8.8.8, 4.4.4.4, 1.1.1.1, various others (open DNS) without any change. Something appears to be messed up on the ISP provided gateway.

What worked for me was (strangely) setting the first DNS entry to my router's default gateway... typically something like 192.168.1.1 unless you have a custom subnet setup.

Worth a try - but IMO setting up a custom network is more fun than using ISP provided equipment. ☺️

Link to comment
Just now, groot-stuff said:

What worked for me was (strangely) setting the first DNS entry to my router's default gateway... typically something like 192.168.1.1 unless you have a custom subnet setup.

Worth a try - but IMO setting up a custom network is more fun than using ISP provided equipment. ☺️

Yeah, I even tried that. Honestly the ISP equipment is crap and I needed an excuse for something better with actual port forwarding and some network control.

Link to comment
  • 3 months later...
On 2/5/2021 at 5:31 AM, groot-stuff said:

What worked for me was (strangely) setting the first DNS entry to my router's default gateway... typically something like 192.168.1.1 unless you have a custom subnet setup.

Worth a try - but IMO setting up a custom network is more fun than using ISP provided equipment. ☺️

I've started to have weird DNS issues since today and ended up here. Guess what changed since last week and this week ? I've got a new fiber line and started using a new (probably crappy) ISP provided fiber box. Seems everything points to the ISP boxes. But do you guys have all one thing in common maybe in regards to the ISP or line technology used?

 

On my side, I'm stuck, because all the ISPs here block their routers from being used in bridge mode. And since it's a very last gen 10gig XGS-PON connection, you can't really use homelab equipment yet, as this technology has very specific requirements, because some authentication mechanism is put on the software side of the client's router. In other words, you can't just hook up any media converter like for regular 1gig connections. 

 

So I'm stuck with this ISP crap that I can't change and that apparently will give me a ton of DNS issues, as mentioned above by everyone else. Great .... 😅

Link to comment
1 hour ago, Marco L. said:

I've started to have weird DNS issues since today and ended up here. Guess what changed since last week and this week ? I've got a new fiber line and started using a new (probably crappy) ISP provided fiber box. Seems everything points to the ISP boxes. But do you guys have all one thing in common maybe in regards to the ISP or line technology used?

 

On my side, I'm stuck, because all the ISPs here block their routers from being used in bridge mode. And since it's a very last gen 10gig XGS-PON connection, you can't really use homelab equipment yet, as this technology has very specific requirements, because some authentication mechanism is put on the software side of the client's router. In other words, you can't just hook up any media converter like for regular 1gig connections. 

 

So I'm stuck with this ISP crap that I can't change and that apparently will give me a ton of DNS issues, as mentioned above by everyone else. Great .... 😅

Wow... 10gig - impressive for in-the-home speed availability! 💪 

I'm not sure if I mention this anywhere, but the one thing that did change in my setup was the firewall (but not the config). Went from an old Zyxel USG50 to a Zyxel VPN100... maybe some differences in the firmware that cause it to handle DNS requests differently.

I have updated the VPN100's firmware a couple times since this issue but haven't bothered to take my array offline to test going back to using OpenDNS rather than my router's IP for the DNS entry in unRaid.

 

As far as ISP, I've always been on a dual-WAN setup through a basic Arris coax modem (SB6141 before, SB8200 now) and Zyxel firewall (USG50 before, VPN100 now), with 1gig (now 1.2gig) Xfinity/Comcast as the primary and CenturyLink/Level3 as failover-only (no round robin or least-load-first because clink is SO slow (20/1Mbps)).

 

If you don't have much configurability with the ISP provided fiber box... have you tried altering the DNS entries within unRaid (Settings > Network) to test using public DNS options as well as your default gateway/fiber box IP?

Link to comment

I have a lead. If I switch to "automatic DHCP" from static, everything is super snappy (unraid menus) and nslookup works, If I switch back to static and add DNS like 1.1.1.1 and 8.8.8.8, nslookup stops working. If I revert back to auto DHCP, it works again. If I revert back to static IP without touching DNS, it still works.

 

??????????????????????????????????????????????????

 

Is it possible that XGS-PON requires you to use your ISP provided DNSes ?

 

image.png.94f7b1b7209c757bb06555c10dd0a994.png

 

image.png.c4035054f37f223d3071fb71902f3e1d.png

 

image.png.17ace956971bb9b9fdd84806e7a90cd3.png

 

image.png.a50e4cdcb57d6f3fe998994d28ad591f.png

Link to comment
35 minutes ago, Marco L. said:

Is it possible that XGS-PON requires you to use your ISP provided DNSes ?

 

It is entirely possible that your ISP is blocking outbound requests on port 53 (DNS)

Quoting that answer so you don't have to click the link...

"Yes, they can block custom DNS - and its fairly trivial. All they need to do is block port 53 exiting their network (except from their nameservers - but in practice its more likely to be from their broadband IP ranges)

The logical reasons for doing this include (which I vehemently disagree with, but thats besides the point) tracking usage, forcing traffic to local caches, blocking access to certain sites, injecting adverts instead of errors for non-existent domain names.

There could theoretically also be benefits to you (prevent some kinds of malware, faster DNS resolution times for people with wrong DNS settings)"

 

To test if they are, just run this at the terminal:

telnet 8.8.8.8 53

If it times out/fails to connect then your ISP is blocking outbound requests on port 53.

 

This is what my successful result looks like (not blocked):

Screenshot_20210514-161454_JuiceSSH.thumb.jpg.864444f3c994fb1f52662e8c0a153bc6.jpg

  • Like 1
Link to comment

I think I have another lead.

Today I realized my OpenVPN server was not working anymore. Upon checking the logs, I saw this:

 

Reading package lists...
E: Failed to fetch http://as-repository.openvpn.net/as/debian/dists/bionic/InRelease Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)

E: The repository 'http://as-repository.openvpn.net/as/debian bionic InRelease' is not signed.
Stopping openvpn-as now; will start again later after configuring

 

After trying to manually check this IP in my browser, I got a nice message from my ISP telling me this website is not safe, is known to contain malware and was blocked.....

It is literally an URL for a PPA repo from openvpn... Anyway, besides the fact this prevents apparently my OpenVPN server docker to install correctly, it made me realize I have now in my ISP packages a "surf protect" feature, which I didn't ask for "for free" (normally 5 bucks per month).

 

I think that if you have this service enabled, they NEED to see your traffic to "protect" you, so that may explain my issues with the 1.1.1.1 DNS and Cie....

 

EDIT : I have obviously asked that this stupid thing be deactivated

Edited by Marco L.
Link to comment

I have been having issues with Sonarr Indexer not working, could this be related to the DNS issues so many people are having? I usually can reboot the server and it works again, but it's getting old and there are no solutions that I have found. I have changed the DNS server addresses from DHCP, to static and back and I keep running into this problem.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.