Users from a local ISP, Globacom (https://www.gloworld.com/ng/) are unable to access sites I have hosted on Netlify. How can I resolve this problem?
If it’s the ISP blocking the server, there’s nothing anyone can do except the ISP. The only solution would be to use proxy or VPN.
@dozieogbo Are these sites on a Netlify subdomain, with your custom domain, or both?
So, funny thing.
It seems like the Netlify subdomain works but the custom domain does not work.
What could be wrong?
What’s the error you’re getting? I’m getting a 502 error after waiting for it to load for a long time and that doesn’t look like a ISP error.
EDIT: The webpage is not being served by Netlify:
@dozieogbo Please help us help you by writing a good post!
All issues: Provide your Netlify site name (e.g. gifted-antelope-58b104.netlify.app).
DNS or SSL issues: Tell us your custom domain(s) (e.g. mycustomdomain.com), and how long it has been since you made changes to your DNS (DNS changes can take up to 48 hours). We can’t help if we don’t know your domain.
Let us know what you have already tried and what the results were.
The better the post = the faster we can help!
Sorry about that.
I made the DNS changes over 1 month ago.
Netlify site name: obiex.netlify.app
Custom Domain: www.obiex.africa
This mostly happens for only users browsing through the ISP (Globacom Nigeria).
@dozieogbo It appears as though your DNS is not properly configured:
|======================= dig CNAME(s) for ======================= | ---------------------- www.obiex.africa ---------------------- | ---------------- will be blank for Netlify DNS ---------------- obiex.africa. |================================================================
Your CNAME should point to your Netlify subdomain, not to your apex domain.
You also have an inactive DNS zone:
|================== check for inactive DNS zone ================= | --------------- last line should show nsone.net --------------- ;; Received 606 bytes from 126.96.36.199#53(ns2us.dns.business) in 45 ms obiex.africa. 1800000 IN NS dns1.namecheaphosting.com. obiex.africa. 1800000 IN NS dns2.namecheaphosting.com. ;; Received 99 bytes from 188.8.131.52#53(dns2.namecheaphosting.com) in 17 ms |================================================================
Thanks a lot.
Checking these out.
Could you help me also check out obiex.africa to see if the DNS is properly configured?
It should be pointing to the load balancer IP address. I think the issue is also reflected there.
@dozieogbo Yes, the A record still is pointed at the load balancer correctly, but the CNAME is still wrong and you still have an inactive Netlify DNS zone.
Hi, @dozieogbo. I checked the domain
obiex.africa and it is configured exactly as recommended now:
obiex.africa. 0 IN A 184.108.40.206 www.obiex.africa. 0 IN CNAME obiex.netlify.app.
By the way, it looks like the TTL (time to live) value for both records above is 1 second (being shown as 0). This TTL is much smaller than I would recommend. Unless you plan to test frequent changes I would recommend a TTL of at least 1800 (30 minutes) if not 3600 or higher.
We use NS1 for our own DNS infrastructure and I highly respect their expertise. They also recommend at least 3600 for records unlikely to change.
If the ISP is blocking Netlify, I’m curious if this is done at the DNS level or if they are blocking the IP addresses themselves. Would you be willing to test something to find out more?
If so, the test uses the command-line tool
dig. There are instructions for installing
dig on many common operating systems here:
If you are willing to test, please install
dig on the affected system (because you have to run the commands on the system where it does not work). Once dig is installed, would you please post the full output of both commands below:
dig +trace obiex.africa dig +trace obiex.africa @220.127.116.11
The two commands will perform “traced” lookups of the DNS records starting at the root DNS servers. The first command uses the default resolver for your system. The second command is using Google’s public DNS server as the resolver. If there is a difference between the two, it would be interesting to compare them.
Again, if you are willing to test, please post the output of both commands here and we will be happy to examine them. As always, if there are other questions please include them at any time.
I was able to recreate it on my device by using the same ISP. I tried the dig commands and I got these results respectively.
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> +trace obiex.africa ;; global options: +cmd ;; connection timed out; no servers could be reached
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> +trace obiex.africa @18.104.22.168 ;; global options: +cmd ;; connection timed out; no servers could be reached
When I tried with another ISP, I got the following results respectively.
;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> +trace obiex.africa ;; global options: +cmd ;; Received 56 bytes from 192.168.0.1#53(192.168.0.1) in 6 ms
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> +trace obiex.africa @22.214.171.124 ;; global options: +cmd . 86156 IN NS e.root-servers.net. . 86156 IN NS h.root-servers.net. . 86156 IN NS l.root-servers.net. . 86156 IN NS i.root-servers.net. . 86156 IN NS a.root-servers.net. . 86156 IN NS d.root-servers.net. . 86156 IN NS c.root-servers.net. . 86156 IN NS b.root-servers.net. . 86156 IN NS j.root-servers.net. . 86156 IN NS k.root-servers.net. . 86156 IN NS g.root-servers.net. . 86156 IN NS m.root-servers.net. . 86156 IN NS f.root-servers.net. . 86156 IN RRSIG NS 8 0 518400 20210125050000 20210112040000 42351 . HHd7qwdZWEMKZwHBoo7LdP6u13hsF39p/Io3P78/qzU6pbXJqWc2BafV 6usv3mnvc6EYSZCFazA9ixk0QnGdCEWoZypswEdssiSbYBzL9+vkxwdM NTyNUawYyUkv6e+4EmLJ6/dkMO1TYU7/N9lsSmR67ko1M+BXyTzN9eBu 5DRkARi+JAwORZKt9fNntpPg8oMeU25jwFfMOQsZ5KYmYZQiy+KLfruD vYmCqhVa9ossX5iE4+oRAF5GeQvMaYfvwbNkqwrb2pktSu5RTRcy14en fGsfk+23GQjnZSWLj8e7cu6Nhem4cMmdBswEC/LOtrcMYmhFHaSeNkgM QBb1Vg== ;; Received 525 bytes from 126.96.36.199#53(188.8.131.52) in 591 ms africa. 172800 IN NS ns.coza.net.za. africa. 172800 IN NS coza1.dnsnode.net. africa. 172800 IN NS ns2us.dns.business. africa. 86400 IN DS 44605 8 2 872009B128134F098AEB415390E1CCCE0DF64338F7D3345DF140C59F B15C7D82 africa. 86400 IN RRSIG DS 8 1 86400 20210125050000 20210112040000 42351 . mbPCGiM7CCpFVsKrpCejEljlRUYkJjH4MjHJfo9+/mZE73L4R9YzEJs2 qzrcw5CdBM9CYBjh/MwJoCTmOiD+BRjFhXuaFTkFUC2iWCZDmNb8r+Hv HE7Yl2OQYnjLUCWa3SCN5m6cAhUrsB31BMnAQNlJ0ejd69SQHFggiWIg vvQcC1CMQArbThn0k/4nC81l+3ZiMigjhfluYZBNedG1TyQPm8KUZcGF 3lNHjWhUgzyoZUrhx/zRrXMxe8GCgosS/IE4z3pH8UPpPEFxdaIpNN1l yigDMniNBsmmK4HiEFBdUTgYTo6chsz2mhCz1Btb95lDt9K/AFgZFtLf 0Pu25Q== ;; Received 599 bytes from 184.108.40.206#53(d.root-servers.net) in 76 ms obiex.africa. 7200 IN NS dns1.namecheaphosting.com. obiex.africa. 7200 IN NS dns2.namecheaphosting.com. 6cldgtab8fjabitlk81a80j7dclmbbng.africa. 86400 IN NSEC3 1 1 10 0B5DA91ED19A0E32 6OB36KKUDF09V1PREQS28KRDPC75CN5Q NS SOA RRSIG DNSKEY NSEC3PARAM 6cldgtab8fjabitlk81a80j7dclmbbng.africa. 86400 IN RRSIG NSEC3 8 2 86400 20210126071509 20210112054509 55759 africa. KBXs13aDe+5Pbkd0osFt5VoTOMVea6s4UemO0aSRBVBFSs3byNfjwU3n SpBMt3zPwi9XLWjV6VPthjXOtWx3wJJR3JjAQ9TphlmPV+10k76zBN05 U0S8I2n3qW9vOsSskooyGzDc6UIE+kO81ZH0/hp/0pUKYsUHslwF1VHZ uYo= 44f6gcrirr11758vhrgbm4qcq1e3aokn.africa. 86400 IN NSEC3 1 1 10 0B5DA91ED19A0E32 4O175TPHR61EHRO82HHF16Q0S2ETVRA5 NS DS RRSIG 44f6gcrirr11758vhrgbm4qcq1e3aokn.africa. 86400 IN RRSIG NSEC3 8 2 86400 20210126071509 20210112054509 55759 africa. I4kqQUDWDhxbU3DdU1q54c3nNaBwamXfhStNfCJw+AFPwZSzQ/FE3HEi Bp3iWchSR6V+A31RIR2JpNUG13hl3/3lqIlziuLOe+xO2IjKxWFRGRAm HeP7lgWiGFLlq9XQtcLurzSsEfOw4rhpwCRYLl7GYj1ISa5wIyzEENV3 rZs= ;; Received 634 bytes from 220.127.116.11#53(coza1.dnsnode.net) in 174 ms obiex.africa. 1 IN A 18.104.22.168 obiex.africa. 1800000 IN NS dns1.namecheaphosting.com. obiex.africa. 1800000 IN NS dns2.namecheaphosting.com. ;; Received 115 bytes from 22.214.171.124#53(dns2.namecheaphosting.com) in 181 ms
About the TTL, I would update that.
@luke if I try running.
Tracing route to obiex.africa [126.96.36.199] over a maximum of 30 hops: 1 5 ms 52 ms 4 ms 192.168.43.210 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete.
Hi, @dozieogbo. It does appear your ISP is both blocking the DNS lookup and blocking the IP address as well.
The resolver IP address and local system IP address are both part of the
192.168.0.0/16 subnet which is a private IP address range. Because they are private IP addresses, I cannot debug those directly (as I have no access to that internal private network).
I would recommend contacting your ISP and possibly your local network admin to ask them why this DNS lookup and traffic to this IP address are not working. This is a local network issue and the administrators of those networks (local and ISP) should be able to find out why this is happening.
If there are other questions, please let us know.
Alright. Thank you.
Will try that out.