Blocked from my own sites..............home only............

Joined
Oct 28, 2002
Messages
59,392
Location
Everson WA - Pacific NW USA
We use Bluehost (BLU) for sickbikeparts.com (SBP)
I use Wave cable as my internet provider (Wave)

Yesterday something weird happened.

Woke up. All is well. Check SBP, check SBP email. All well on my desk PC.

Go outside. Work for a couple hours. Come back in to check site, message, Fidelity, BITOG, AKFiles,WaGuns, Amsoil, etc............all well EXCEPT
Cannot access our SBP web site management side or public side. Cannot download emails. DNS blocked, DNS not responding, website doesn't exist. All on same PC
Try shop PC. Same. Try phone hooked to our wireless net, same. Try laptop same. Wife tries to access public site from her laptop and gets on.

Reboot, reboot and reset modem and routers. No help. Cleared all memory and cache.

Call Wave, no real help. Trouble ticket. At least the third person listened to me, The first two were useless and did not understand. He said they don't block ANY sites.

Business partner has no access problems whatsoever. He uses Comcast.

We have house guest - wife wanted to take them to farmers market. I try from my phone using cell service and get hooked right up. No problem.

Come home. Shut all down. Let stuff site quiet for 30 minutes. No help. Can access everything else.

2-3 hours later, all starts working just fine. This AM fine.

Explain.
 
That is weird but but maybe it was some kind of security not letting you in. At work we have our customers websites thru Liquid Web. I get calls all the time with people that can not access their site or anything to do with our companies websites, but every thing else is working fine. Inside my admin account in cPanel is a section called "Unblock IP". I have them go to ipchicken.com to get their IP address, enter it and it will unblock them. Usually it's because they forgot their log in info and kept trying to access their website/cPanel with the wrong credentials, after the third attempt the server grabs their IP and blocks them. But every once in a while I get a call and they say they were not trying to log in, only thing I can think of is someone was try to hack into their website or our server. After a certain amount of time if no other attempts were executed it will release the IP from being blocked.
 
Last edited:
My best **guess** is that some of your devices and/ or your ISP had cached some DNS information that had become outdated. Once those DNS caches were flushed and refreshed (and pointed to the right IP with the correct certificates) the problem was automagically resolved. The fact that this "just went away" over that time frame suggests DNS propagation.

In other words, hypothetically yourdomain.tld was known by DNS servers throughout the world as pointing to an IP address of a.b.c.d (BITOG, for example, resolves as of this writing to 104.20.122.71, sickbikespart.com to 35.227.243.103). The email services may point elsewhere; but for the sake of simplicity let's just stick with a.b.c.d. When I punch in yourdomain.tld then a DNS server somewhere - usually one's ISP but many will elect to use other DNS services like Google's 8.8.8.8 and Cloudflare's 1.1.1.1 or OpenDNS or other - resolves that name to an IP address such a a.b.c.d and sends you on your way.

However, from time to time, and for a variety of reasons, sometimes the IP address changes. (e.g. when I upgrade my servers I will often replicate the whole shootin' match, perform the upgrade and test it, and after confirming that nothing is going to blow up, simply redirect domain names to the new, replicated system's IP address.) Somewhere there is a nameserver that authoritatively couples yourdomain.tld with an IP address. If that IP address happens to change from a.b.c.d to e.f.g.h then the nameserver needs to propagate that information to every single DNS server on the planet; a process that will take anywhere from seconds to hours, depending on where you are. As with most other internet processes, computers will cache data so that we don't bog everything down by re-confirming every minute detail every time one computer wants to connect to another. So if your ISP - who is also likely your DNS provider - and/ or your own systems had cached the information "yourdomain.tld points to a.b.c.d" and was using that when in actuality it has (recently) changed to "yourdomain.tld points to e.f.g.h" then your system was being directed to the server at a.b.c.d which no longer hosts yourdomain.tld.

A real-world example might be a friend's address book: They have "Pablo's house" listed at 123 Yourstreet, Anytown, USA and simply look in that book when they want to visit you. If you move to another address and their reference ("cache") is not updated then people are going to get "Error: Pablo not found" errors when they show up at 123 Yourstreet. And you need to eventually, over time, make sure that ALL of your contacts, from your friends and family to the DMV and your bank, become aware of your move. And "you making them aware" and "they actually updating their information" can sometimes be abstracted to the point of error.
 
My best **guess** is that some of your devices and/ or your ISP had cached some DNS information that had become outdated. Once those DNS caches were flushed and refreshed (and pointed to the right IP with the correct certificates) the problem was automagically resolved. The fact that this "just went away" over that time frame suggests DNS propagation.

In other words, hypothetically yourdomain.tld was known by DNS servers throughout the world as pointing to an IP address of a.b.c.d (BITOG, for example, resolves as of this writing to 104.20.122.71, sickbikespart.com to 35.227.243.103). The email services may point elsewhere; but for the sake of simplicity let's just stick with a.b.c.d. When I punch in yourdomain.tld then a DNS server somewhere - usually one's ISP but many will elect to use other DNS services like Google's 8.8.8.8 and Cloudflare's 1.1.1.1 or OpenDNS or other - resolves that name to an IP address such a a.b.c.d and sends you on your way.

However, from time to time, and for a variety of reasons, sometimes the IP address changes. (e.g. when I upgrade my servers I will often replicate the whole shootin' match, perform the upgrade and test it, and after confirming that nothing is going to blow up, simply redirect domain names to the new, replicated system's IP address.) Somewhere there is a nameserver that authoritatively couples yourdomain.tld with an IP address. If that IP address happens to change from a.b.c.d to e.f.g.h then the nameserver needs to propagate that information to every single DNS server on the planet; a process that will take anywhere from seconds to hours, depending on where you are. As with most other internet processes, computers will cache data so that we don't bog everything down by re-confirming every minute detail every time one computer wants to connect to another. So if your ISP - who is also likely your DNS provider - and/ or your own systems had cached the information "yourdomain.tld points to a.b.c.d" and was using that when in actuality it has (recently) changed to "yourdomain.tld points to e.f.g.h" then your system was being directed to the server at a.b.c.d which no longer hosts yourdomain.tld.

A real-world example might be a friend's address book: They have "Pablo's house" listed at 123 Yourstreet, Anytown, USA and simply look in that book when they want to visit you. If you move to another address and their reference ("cache") is not updated then people are going to get "Error: Pablo not found" errors when they show up at 123 Yourstreet. And you need to eventually, over time, make sure that ALL of your contacts, from your friends and family to the DMV and your bank, become aware of your move. And "you making them aware" and "they actually updating their information" can sometimes be abstracted to the point of error.
All great stuff, especially the phone book analogy, I use it all the time explaining how DNS works to the average Joe. The only reason I didn't suspect DNS is because others could access the site. IP address, name server updates all take time and need to propagate even if forwarding is in place before the change and effects everyone trying to access the site but you make valid points about his ISP and local caching so who knows.

When I first started this job any changes we made thru Terminal had to wait until that evening when the server would run updates. In the morning we would check to make sure all updates were successful, if not we corrected them and had to wait until it ran updates that night then check again in the morning. Now it's all a matter of seconds, couple hours tops, even DNS propagation, like you mentioned is seconds.
 
All great stuff, especially the phone book analogy, I use it all the time explaining how DNS works to the average Joe. The only reason I didn't suspect DNS is because others could access the site.

If others are using cell data instead of WiFi, a different ISP or a 3rd-party DNS provider then it is entirely feasible they'd have different DNS responses. The first thing I do when I suspect a DNS SNAFU is turn of WiFi on my phone and try using the cell plan's data. I'd go from using the my home's DNS provider to the default provided by my cell provider. That one step usually clears up the picture for me (both for DNS and actual content caches!)
 
If others are using cell data instead of WiFi, a different ISP or a 3rd-party DNS provider then it is entirely feasible they'd have different DNS responses. The first thing I do when I suspect a DNS SNAFU is turn of WiFi on my phone and try using the cell plan's data. I'd go from using the my home's DNS provider to the default provided by my cell provider. That one step usually clears up the picture for me (both for DNS and actual content caches!)
Is there a method to TRULY clear all the various caches?

THANKS! Really SOLID responses here. Better than web searches and such. BITOG. Who knew(?) HAHAHAHA.
 
Is there a method to TRULY clear all the various caches?

THANKS! Really SOLID responses here. Better than web searches and such. BITOG. Who knew(?) HAHAHAHA.

It's been 100 years since I was a DNS admin. If we knew a change was coming, we would begin to advertise shorter cache intervals. I.E. 24 hours out, we might change the cache value from 24 hours to 1 hour, or 15 minutes.

The DNS admin sets the cache value, and anticipated changes means the administrator can shorten the "use by" date of the records it shares about domains it serves.

But it's been a while since I've done this, so perhaps newer DNS servers can advise other servers that have cached the value to update.

But I come from the "good old days" where we used named as a DNS server. I have no clue what is used today, so take this for what it is, history.
 
The only cache you can control would be your routers cache by restarting it but most home routers don't store/cache DNS unless you're running a home server of some type, that's what your ISP does or as @uc50ic4more mentions google and cloudfare. Each setting in the DNS has a TTL (time to live) which determines how often that record (A , TXT, cName, MX record) gets refreshed but it's also up to the closest router to honor that, they may have their own settings which takes precedence.
 
Last edited by a moderator:
It's been 100 years since I was a DNS admin. If we knew a change was coming, we would begin to advertise shorter cache intervals. I.E. 24 hours out, we might change the cache value from 24 hours to 1 hour, or 15 minutes.

The DNS admin sets the cache value, and anticipated changes means the administrator can shorten the "use by" date of the records it shares about domains it serves.

But it's been a while since I've done this, so perhaps newer DNS servers can advise other servers that have cached the value to update.

But I come from the "good old days" where we used named as a DNS server. I have no clue what is used today, so take this for what it is, history.
When I first started 14 years ago we would give new entries/changes a lower TTL time, say 300, problem with that is if you don't remember to go back in a raise it (14400 is average) then it creates more traffic on your server which is unnecessary because those type settings don't get changed often. Those numbers are seconds in case anyone is wondering.

Sorry if I rambled on but it's the one part of my job I really love and I just don't get to do it much anymore.
 
As a non-sequitur, who wants to talk about Sendmail.cf files.

A configuration file barely distinguishable from line noise. Now I am showing my age :)
 
As a non-sequitur, who wants to talk about Sendmail.cf files.

A configuration file barely distinguishable from line noise. Now I am showing my age :)
I really wish I would have entered this field earlier but I didn't even own a computer until 2001 at age 44. Went back to school in 2005 and took a Cisco class and have been hooked ever since.
 
As a non-sequitur, who wants to talk about Sendmail.cf files.

A configuration file barely distinguishable from line noise. Now I am showing my age :)
I've seen more readable text after a cat has walked all over a keyboard. A workaround for if you never want to deal with that again:
Code:
sudo apt-get OR dnf install postfix
;)
 
Is there a method to TRULY clear all the various caches?

THANKS! Really SOLID responses here. Better than web searches and such. BITOG. Who knew(?) HAHAHAHA.
Honestly, if your site is hosted on a fully-managed platform (ie. Bluehost) this should not be a concern for you, the customer. DNS resolving to the right flippin' IP address is a matter for whomever is running the show and there ought not to be any interruptions to service.

EDIT: By the way, you can keep an eye on what people in different parts of the world are seeing for your DNS here: https://www.whatsmydns.net/#A/sickbikeparts.com
This does NOT account for the myriad discrepancies that might occur for internet users mere houses from each other who have different ISP's or cell data providers; just some random clients at these locations (clicking on any result will show you the ISP or DNS provider being used). Whenever I make a change (responsibly, of course, using redundant servers) I like to watch that page dance as my info propagates globally.
 
Last edited:
There are two possibilities here:

1. A DNS caching issue, which would have, when the issue was occurring, been easy to test for with changing your nameserver to something like OpenDNS (208.67.222.222/208.67.220.220) and flushing your DNS cache (ipconfig /flushdns on Windows).

2. A routing table issue. Which is typically isolated to a single provider. In this instance, the site resolves to the correct IP address, but you simply can't get there.

I've had both happen. The 2nd typically involves getting in touch with somebody at the affected ISP (super fun, you have to fight all the tech support level bosses before you get to the final boss, who puts you onto somebody who actually knows what a routing table is) who can then look at why your traffic is being sent to the wrong hop or blackholed after several hops when trying to reach that particular address.

DNS issues typically self resolve after a stint (which this sounds like it did). Routing tables also automatically update, but if something is royally buggered, it may not get corrected and require manual intervention.
 
I actually got a call last night from WAVE/Astound. Missed the call.....:

Hi Paul this is Renee calling from us down broadband. I'm just calling to follow up on your case regarding your inability to access some websites there. There was in fact in an outage in the area for the server at that time. At this time it has been resolved. ...
 
Anytime you run into similar issues, where some sites work while others don't or where others (on different ISPs) can access while you can't, check using a different internet provider. Sounds like every device you used was on the same internet provider so there's your common denominator. It can be as simple as using a smartphone on data, not WiFi, to access.
 
Anytime you run into similar issues, where some sites work while others don't or where others (on different ISPs) can access while you can't, check using a different internet provider. Sounds like every device you used was on the same internet provider so there's your common denominator. It can be as simple as using a smartphone on data, not WiFi, to access.
Yep great first/second step
I usually try second device (phone vs computer) then phone on mobile data vs wifi.
 
Back
Top