There is something strange with your DNS settings, as www.openbloom.com return different results to openbloom.com, which would indicate something going on with your CNAME record. They should obviously be identical.
No, that is the SmugMug recommended configuration (openbloom.com resolves to 208.79.45.23, which is SmugMug's webserver which will just redirect the browser to www.openbloom.com). Then www.openbloom.com has a CNAME pointing to domains.smugmug.com.
Kygarden: I would try changing your Custom Domain name in your SmugMug settings to something else, then changing it back. That may cause SmugMug to update your site configuration at Akamai and flush out those broken entries.
Kygarden: I would try changing your Custom Domain name in your SmugMug settings to something else, then changing it back. That may cause SmugMug to update your site configuration at Akamai and flush out those broken entries.
Thanks. I'll do that again right now....but I did try that sometime yesterday too. Can't hurt to do it again ;-)
Oh? At this point I really think a SmugMug engineer needs to take one of your error reference numbers to Akamai and figure out why that caching server rejected the request. Akamai should have request logging that will let them know what the actual issue is.
Oh? At this point I really think a SmugMug engineer needs to take one of your error reference numbers to Akamai and figure out why that caching server rejected the request. Akamai should have request logging that will let them know what the actual issue is.
Yep. I've sent smugmug support all the info I've been posting here. I removed my custom domain name on my smugmug account page and saved it....checked the openbloom link and got the error message from SM saying it can't find what I'm looking for (which is what I'd expect when the domain name is removed) and then re-entered and saved it...then it loaded correctly again. I'll keep an eye on it and hopefully it'll stay working now, going forward.
Just tried your site and worked fine for me on Mac and Chrome.
It's dead again for me now :-( SM support claims it's a problem with Go Daddy DNS, yet I was not a Go Daddy customer until Andy or Zac told me it was Yahoo's problem, so I switched to Go Daddy....but my transfer of the domain was not officially transferred until yesterday. I"m still trying to find out what's up.
I checked my site with urlm.co/www.southeasternphotography.com and got the following (didn't let me just copy the stuff I wanted)(shows me using the Akamai Servers):
Got this for yours - Notice this string difference - maybe it will help - PING e1021.c.akamaiedge.net ##########):
Openbloom.com Go to site >>
Openbloom is ranked 5,124,068 in the United States. 'www.openbloom.com - Photography - Nature, Landscapes, Travel and More.'
AnalysisVisitorsLinksServer
5,124,068
Rank in United States
4,948,027
Worldwide Rank
Monthly pages viewed 4,536
Monthly visits 765
Value per visitor $0.07
Estimated worth $1,294.98 *
External links 19
Number of pages 18
Keywords
Unavailable
Country Rank
Unavailable
*Estimated data, read disclaimer.
Last Updated: 08/20/2013
openbluelab.org NetSuite CRM, Microsoft CRM, Maximizer CRM
openbluelab.org 0 comments, Miktex Portable Version, 4:05 PM, 0 comments
openboilers.blogspot.com
openboltguns.blogspot.comOpen Book Company Library Services Ltd. Bookshop Home
openbook.ieOpen Book Books, Writing and Reading
openbook.net.au
Visitors
Traffic History 90 Day Average
Worldwide Rank 4,158,006 -712,926
Daily Visitors 62 +30%
Daily Visitors Rank 3,885,141 -978,864
Daily Pageviews 0 +2%
Daily Pageviews Rank 5,265,807 -249,228
Pageviews Per User 1.50 -20% www.Openbloom.com
There are links labelled, Galleries, Nature & Landscapes, Creative & Other Subjects, Travel - Places, Animals & Insects, Vacation And Short Trips, Gear, and Etc.
Content
Some of the 60 pages on the site, include, "openbloom.com - Photography - Nature, Landscapes, Travel and More," "Panasonic LX3 Gallery - openbloom.com - Photography - Nature," and "Nikon 1 V1 Gallery - openbloom.com - Photography - Nature."
The site has about 68 users daily, viewing on average 1.50 pages each.
I checked my site with urlm.co/www.southeasternphotography.com and got the following (didn't let me just copy the stuff I wanted)(shows me using the Akamai Servers):
Is my www.openbloom.com still working for you at this moment? Seems to be dependent on where people are if they see it working or not.
It's dead again for me now :-( SM support claims it's a problem with Go Daddy DNS
Hahaha, they really don't have a clue, do they? I wonder what their explanation is for the problem occurring while your domain provably resolves to domains.smugmug.com, taking it utterly out of the hands of your DNS provider.
Sorry, it looks like you're not going to get this solved.
While I can't tell exactly what you changed on the DNS end without your help, the whois record lists the last change on openbloom.com as 26-aug-2013, and DNS for openbloom.com shows a 28800 TTL, meaning that it'll take up to that many seconds for other DNS providers to expire their cache of previous DNS entries for it. Furthermore, if your previous DNS had larger TTL settings, those may be cached for even longer. If there was a gap in the time between when the domain was being transferred (i.e. you didn't have DNS service on both registrars during the transition period), the domain may have had cached a no-DNS result. Different customers will see different results depending on what result their local DNS has cached under openbloom.com.
After that TTL period is over, if you're seeing some error that begins with "Reference #[some number], send that to Bonocore and he'll be happy to investigate!
If you know your way around a command line, you could run "ping openbloom.com" and "ping www.openbloom.com" from your local computer and post the results here.
I work at SmugMug but these opinions are usually my own.
Different customers will see different results depending on what result their local DNS has cached under openbloom.com.
I'm sorry, but customer's DNS caches are completely irrelevant here. OP has already provided Wireshark traces which demonstrate that in their local DNS cache, their domain name www.openbloom.com correctly resolves a CNAME to domains.smugmug.com. That's the end of anything to do with his domain name in his local cache, the rest is entirely due to caching of Akamai and SmugMug DNS results, over which OP has no influence. And he shows that all of the following names in the DNS chain had really short TTLs; once you get inside Akamai's DNS chain, the TTL was clearly only a couple of hours:
And yet he's still getting an Akamai error message on his computer with his DNS cache. Can you explain which cached result in OP's local DNS cache could be causing this issue?
Ok, I went to it again just now. Your website keeps coming up fine for me. Every time. I go back to the thought that my site is using a different Akamai server address than his. So perhaps an Akamai server address serving his area is corrupt. And what about the data that Akimai servers have been having major problems for the last week that they do not know what is the root cause? A denial of service attack??? Something is obviously wrong for him and the biggest dog in the fight at SmugMug should be helping him solve this instead of just telling him to go to service providers for help. Dang, with the number of SmugMug's users base, SmugMug should have some super clout. If not - time to leave.
Is my www.openbloom.com still working for you at this moment? Seems to be dependent on where people are if they see it working or not.
I've gone to it a number of times while reading this thread, and it always works for me. I'm in Eastern Pennsylvania, using FF. But I'll check now & then and let you know if anything different happens. I got the same 404 Error that you did when you went to that Akamai URL a couple pages back.
Welcome to the world of global internet operations, where everything is more complicated than it seems!
Yahoo's DNS (for domain customers, not yahoo.com) outage last week is mentioned in http://www.ysmallbizstatus.com/status/archives/12749 , although they seem to have lost the details of their actual outage. Their outage appeared to be a partial one for their global DNS system, meaning that some regions had brief sporadic outages, some had complete outages, and some regions had no problems. In a global caching system, caching results from a domain that is served from yahoo DNS, these outages would get cached according to their TTL or negative TTL set in their SOA record, although this can get more tricky if their DNS is completely out, or worse, returning corrupt/poisoned records. Unfortunately I don't have details on exactly what their problem was, aside from reports that DNS queries to many of their servers was hanging. Yahoo smallbiz DNS seem to have frequent problems, and I personally would not recommend them.
Anyway, what this means is that if your domain uses DNS with a global distribution/load balancing (a good idea, but difficult and complex in practice, and usually only delivering marginal improvements in performance) to serve a web site with global caching (huge performance gains), you need the following to be functional within certain time windows:
1. your local DNS (the one your computer talks to)
2. your upstream DNS, if your computer talks to a caching DNS on your local router (a very common config for US ISPs), that talks to...
3. the DNS that serves your domain that is local to you
4. the local web caching server that you connect to
5. the DNS that your local caching server uses, that talks to...
6. the DNS that serves your domain that is local to your local caching server
That's only the part that's directly relevant here, and is of course, simplified. I'm sure I could drone on and on about the different places where things get cached and for how long, but dgrin is probably already asleep by now reading this. What causes a domain to be resolved correctly locally but not on the caching level is when parts 1-3 work but some part of step 4-6 fails. This means that for a modern high performance web site, reliable DNS is absolutely critical for high availability service. For an old school single-point web site, reliable DNS is important as well, but problems are easier to diagnose because you have access to all of the parts.
Changing DNS providers or registrars can result in similar problems as an outage if full coverage is not provided or if one of the parties involved doesn't handle some part of the process correctly.
To sum up, if you're still seeing problems and want to get things working, these will help diagnose which of steps 4-6 are at fault:
- show the output of "ping openbloom.com" and "ping www.openbloom.com"
- show the result that shows on your web browser when you visit "http://openbloom.com/"
Send those to Bonocore, and he'll deliver results for you.
I work at SmugMug but these opinions are usually my own.
The OP has demonstrated that his domain resolves to domains.smugmug.com when the problem occurs, so all this waffle about what could go wrong is completely irrelevant. OP has demonstrated that his domain is resolving successfully.
Perhaps you would like to venture a hypothesis as to why OP sees an error message from Akamai if his domain isn't resolving to domains.smugmug.com?
Again, OP has posted actual Wireshark capture results that show precisely how his DNS resolved, you can see that there is no question that his domain name is correctly configured with a CNAME for domains.smugmug.com:
And then precisely the response he received from the resulting Akamai cache server at the A record:
This is considerably more detailed information than the ping results you suggest he collect.
Thanks for the replies and info everyone. The good news is, at this moment my site is working (for me locally)...and it was working fine right before I went to bed. I'm crossing my fingers and hoping that it won't stop working again. For some people, it has always been fine. It definitely seems regional....but whatever it was/is, I really hope it's fixed because it was very frustrating. I did call Go Daddy yesterday evening and the support guy said he had nothing on his board about any DNS outage at Go Daddy, but he did admit it's possible that other's in his company could have more technical detail about that if it was somewhat isolated and not widespread that many customers would be calling about. The wait time for support on the phone was only 2 minutes, so not many people were calling for help ;-) I suppose it's possible that I just got caught in a mix of really bad timing and bad luck. In case anyone missed the early part of this thread, I was using Yahoo for my domain when this problem started about a week ago and then changed to Go Daddy. So maybe that's where my bad timing came in....by deciding to go ahead and switch providers. Maybe it would have been ok quicker if I had waited out the Yahoo trouble. Either way, I really hope it's fixed because it's not just me that noticed it. I posted a video on youtube with a link to my Fuji X100S gallery and someone replied "Invalid URL?"....so I had to change the link to the smugmug link since that person was seeing my site as dead too. That comment is posted on my video: http://www.youtube.com/watch?v=_J0uG3D1AN0&feature=c4-overview&list=UUYFWP_KVkHCXoI88shZOu2Q
Kygarden, thanks for your patience. Please let Bonocore know if you're still seeing any problems as I'm no longer following this thread.
As mentioned previously, this relevant error occurs when steps 1-3 (listed in my post above) work but some part of step 4-6 fails. Wireshark only sees 1-3; the very relevant 4-6 are not available to wireshark.
This was exactly the case here, and to be precise, #4 and #6 were regionally faulty at different times and having #6 change added some further complexity.
I work at SmugMug but these opinions are usually my own.
Kygarden, thanks for your patience. Please let Bonocore know if you're still seeing any problems as I'm no longer following this thread.
As mentioned previously, this relevant error occurs when steps 1-3 (listed in my post above) work but some part of step 4-6 fails. Wireshark only sees 1-3; the very relevant 4-6 are not available to wireshark.
This was exactly the case here, and to be precise, #4 and #6 were regionally faulty at different times and having #6 change added some further complexity.
Thanks :-) So far, so good today. I haven't noticed any problems since I went to bed last night. I'm hoping that all the various parts of this are fixed as well as up to date with my change to Go Daddy. I have hope :-)
Comments
No, that is the SmugMug recommended configuration (openbloom.com resolves to 208.79.45.23, which is SmugMug's webserver which will just redirect the browser to www.openbloom.com). Then www.openbloom.com has a CNAME pointing to domains.smugmug.com.
Kygarden: I would try changing your Custom Domain name in your SmugMug settings to something else, then changing it back. That may cause SmugMug to update your site configuration at Akamai and flush out those broken entries.
Please check out my gallery of customisations for the New SmugMug, more to come!
Thanks. I'll do that again right now....but I did try that sometime yesterday too. Can't hurt to do it again ;-)
Please check out my gallery of customisations for the New SmugMug, more to come!
Yep. I've sent smugmug support all the info I've been posting here. I removed my custom domain name on my smugmug account page and saved it....checked the openbloom link and got the error message from SM saying it can't find what I'm looking for (which is what I'd expect when the domain name is removed) and then re-entered and saved it...then it loaded correctly again. I'll keep an eye on it and hopefully it'll stay working now, going forward.
It's dead again for me now :-( SM support claims it's a problem with Go Daddy DNS, yet I was not a Go Daddy customer until Andy or Zac told me it was Yahoo's problem, so I switched to Go Daddy....but my transfer of the domain was not officially transferred until yesterday. I"m still trying to find out what's up.
Southeasternphotography.com Go to site >>
Southeasternphotography is ranked 4,534,420 in the United States. 'Southeastern Photography - © Troup Nightingale.'
AnalysisVisitorsLinksServer
4,534,420
Rank in United States
8,249,762
Worldwide Rank
Monthly pages viewed 6,804
Monthly visits 1,526
Value per visitor $0.05
Estimated worth $1,730.48 *
External links 27
Number of pages 3
Keywords
Unavailable
Country Rank
Unavailable
*Estimated data, read disclaimer.
Last Updated: 08/21/2013
southeasternpowersports.net Lawrenceville Honda Yamaha, Honda, Yamaha
southeasternpowersports.net Football Score, Sports Trivia, Fantasy Sports, Sports Headline
southeasternpreps.com
southeasternproducts.comFireworks Display Company, Pyro, Shows, Special Effects, | SC, NC, GA, AL, TN
southeasternpyrotechnics.comSoutheastern Railway - A commuters blog
southeasternrailway-forum.co.uk
Visitors
Traffic History 90 Day Average
Worldwide Rank 6,932,573 -3,479,264
Daily Visitors 30 +40%
Daily Visitors Rank 6,545,368 -2,499,934
Daily Pageviews 0 +110%
Daily Pageviews Rank 8,306,373 -4,660,529
Pageviews Per User 1.40 +40%
www.Southeasternphotography.com
Browsing the site, we can see that there are pages about, Galleries, Slideshow Images, Recent Images, Guestbook, Gear, Portfolio, Nature, Boats, and Landscapes.
Content
Some of the 10 pages on the site, include, "Southeastern Photography - © Troup Nightingale," and "The Trumpy Yacht "Drifter" - Southeastern Photography - © Troup."
33 users visit the site each day, each viewing 1.40 pages.
Links
Links in
maritimesalvagerecover.. Maritimesalvagerecovery
Server
Server Location
Akamai Technologies
Massachusetts
Cambridge
United States
42.3933, -71.1333
Map data ©2013 Google - Terms of Use
dns235.c.register.com, dns239.b.register.com, and dns249.d.register.com are some of its 4 Nameservers. It is hosted by Akamai Technologies (Massachusetts, Cambridge,) using Apache web server. SmugMug/0.9 is its coding language environment. Pinging the server, resulted in a 11.7 ms response. Southeasternphotography.com's server IP number is 23.1.52.77.
PING e1021.c.akamaiedge.net (184.50.228.77) 56(84) bytes of data.
64 bytes from a184-50-228-77.deploy.akamaitechnologies.com (184.50.228.77): icmp_seq=1 ttl=57 11.7 ms
64 bytes from a184-50-228-77.deploy.akamaitechnologies.com (184.50.228.77): icmp_seq=2 ttl=57 11.6 ms
64 bytes from a184-50-228-77.deploy.akamaitechnologies.com (184.50.228.77): icmp_seq=3 ttl=57 11.6 ms
--- e1021.c.akamaiedge.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 11.612/11.654/11.736/0.105 ms
rtt min/avg/max/mdev = 11.612/11.654/11.736/0.105 ms
Server Setup
Server: Apache
Expires: --
Cache-Control: private, max-age=1, must-revalidate
X-S: 27.241:13560
X-Powered-By: SmugMug/0.9
X-SmugMug-Hiring: How to love what you do: www.smugmug.com/jobs/
X-SmugMug-Values: 2/4 - Love your employees
Content-Type: text/html; charset=utf-8
Date: --
Transfer-Encoding: chunked
Connection: keep-alive
Connection: Transfer-Encoding
Got this for yours - Notice this string difference - maybe it will help - PING e1021.c.akamaiedge.net ##########):
Openbloom.com Go to site >>
Openbloom is ranked 5,124,068 in the United States. 'www.openbloom.com - Photography - Nature, Landscapes, Travel and More.'
AnalysisVisitorsLinksServer
5,124,068
Rank in United States
4,948,027
Worldwide Rank
Monthly pages viewed 4,536
Monthly visits 765
Value per visitor $0.07
Estimated worth $1,294.98 *
External links 19
Number of pages 18
Keywords
Unavailable
Country Rank
Unavailable
*Estimated data, read disclaimer.
Last Updated: 08/20/2013
openbluelab.org NetSuite CRM, Microsoft CRM, Maximizer CRM
openbluelab.org 0 comments, Miktex Portable Version, 4:05 PM, 0 comments
openboilers.blogspot.com
openboltguns.blogspot.comOpen Book Company Library Services Ltd. Bookshop Home
openbook.ieOpen Book Books, Writing and Reading
openbook.net.au
Visitors
Traffic History 90 Day Average
Worldwide Rank 4,158,006 -712,926
Daily Visitors 62 +30%
Daily Visitors Rank 3,885,141 -978,864
Daily Pageviews 0 +2%
Daily Pageviews Rank 5,265,807 -249,228
Pageviews Per User 1.50 -20%
www.Openbloom.com
There are links labelled, Galleries, Nature & Landscapes, Creative & Other Subjects, Travel - Places, Animals & Insects, Vacation And Short Trips, Gear, and Etc.
Content
Some of the 60 pages on the site, include, "openbloom.com - Photography - Nature, Landscapes, Travel and More," "Panasonic LX3 Gallery - openbloom.com - Photography - Nature," and "Nikon 1 V1 Gallery - openbloom.com - Photography - Nature."
The site has about 68 users daily, viewing on average 1.50 pages each.
Links
Links out
smugmug.com Photo Sharing. Your Photos Look Better Here. | SmugMug
smugmug.com Photo Sharing & Video Hosting. Browse more than 1,648,662,883
dpreview.com Nikon D700 Review: 1. Introduction: Digital Photography Review
dpreview.com Panasonic Lumix DMC-LX3 Review: 1. Introduction: Digital
Server
Server Location
Akamai Technologies
Massachusetts
Cambridge
United States
42.3933, -71.1333
Map data ©2013 Google - Terms of Use
It has 4 nameservers, including ns9.san.yahoo.com, yns1.yahoo.com, and yns2.yahoo.com. Its IP Number is 23.0.20.77. A ping to the server is timed at 11.4 ms. The programming language environment is SmugMug/0.9. It is hosted by Akamai Technologies (Massachusetts, Cambridge,) using Apache web server.
PING e1021.c.akamaiedge.net (23.1.164.77) 56(84) bytes of data.
64 bytes from a23-1-164-77.deploy.akamaitechnologies.com (23.1.164.77): icmp_seq=1 ttl=57 11.4 ms
64 bytes from a23-1-164-77.deploy.akamaitechnologies.com (23.1.164.77): icmp_seq=2 ttl=57 11.3 ms
64 bytes from a23-1-164-77.deploy.akamaitechnologies.com (23.1.164.77): icmp_seq=3 ttl=57 11.5 ms
--- e1021.c.akamaiedge.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 11.371/11.427/11.510/0.105 ms
rtt min/avg/max/mdev = 11.371/11.427/11.510/0.105 ms
Server Setup
Server: Apache
Expires: --
Cache-Control: private, max-age=1, must-revalidate
X-S: 27.229:29289
X-Powered-By: SmugMug/0.9
X-SmugMug-Hiring: How to love what you do: www.smugmug.com/jobs/
X-SmugMug-Values: 1/4 - Thrill your customers
Content-Type: text/html; charset=utf-8
Date: --
Transfer-Encoding: chunked
Connection: keep-alive
Connection: Transfer-Encoding
Mine has been working fine non-stop the whole time of your troubles.
Is my www.openbloom.com still working for you at this moment? Seems to be dependent on where people are if they see it working or not.
Hahaha, they really don't have a clue, do they? I wonder what their explanation is for the problem occurring while your domain provably resolves to domains.smugmug.com, taking it utterly out of the hands of your DNS provider.
Sorry, it looks like you're not going to get this solved.
Please check out my gallery of customisations for the New SmugMug, more to come!
After that TTL period is over, if you're seeing some error that begins with "Reference #[some number], send that to Bonocore and he'll be happy to investigate!
If you know your way around a command line, you could run "ping openbloom.com" and "ping www.openbloom.com" from your local computer and post the results here.
I'm sorry, but customer's DNS caches are completely irrelevant here. OP has already provided Wireshark traces which demonstrate that in their local DNS cache, their domain name www.openbloom.com correctly resolves a CNAME to domains.smugmug.com. That's the end of anything to do with his domain name in his local cache, the rest is entirely due to caching of Akamai and SmugMug DNS results, over which OP has no influence. And he shows that all of the following names in the DNS chain had really short TTLs; once you get inside Akamai's DNS chain, the TTL was clearly only a couple of hours:
And yet he's still getting an Akamai error message on his computer with his DNS cache. Can you explain which cached result in OP's local DNS cache could be causing this issue?
Please check out my gallery of customisations for the New SmugMug, more to come!
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
Yahoo's DNS (for domain customers, not yahoo.com) outage last week is mentioned in http://www.ysmallbizstatus.com/status/archives/12749 , although they seem to have lost the details of their actual outage. Their outage appeared to be a partial one for their global DNS system, meaning that some regions had brief sporadic outages, some had complete outages, and some regions had no problems. In a global caching system, caching results from a domain that is served from yahoo DNS, these outages would get cached according to their TTL or negative TTL set in their SOA record, although this can get more tricky if their DNS is completely out, or worse, returning corrupt/poisoned records. Unfortunately I don't have details on exactly what their problem was, aside from reports that DNS queries to many of their servers was hanging. Yahoo smallbiz DNS seem to have frequent problems, and I personally would not recommend them.
Anyway, what this means is that if your domain uses DNS with a global distribution/load balancing (a good idea, but difficult and complex in practice, and usually only delivering marginal improvements in performance) to serve a web site with global caching (huge performance gains), you need the following to be functional within certain time windows:
1. your local DNS (the one your computer talks to)
2. your upstream DNS, if your computer talks to a caching DNS on your local router (a very common config for US ISPs), that talks to...
3. the DNS that serves your domain that is local to you
4. the local web caching server that you connect to
5. the DNS that your local caching server uses, that talks to...
6. the DNS that serves your domain that is local to your local caching server
That's only the part that's directly relevant here, and is of course, simplified. I'm sure I could drone on and on about the different places where things get cached and for how long, but dgrin is probably already asleep by now reading this. What causes a domain to be resolved correctly locally but not on the caching level is when parts 1-3 work but some part of step 4-6 fails. This means that for a modern high performance web site, reliable DNS is absolutely critical for high availability service. For an old school single-point web site, reliable DNS is important as well, but problems are easier to diagnose because you have access to all of the parts.
Changing DNS providers or registrars can result in similar problems as an outage if full coverage is not provided or if one of the parties involved doesn't handle some part of the process correctly.
To sum up, if you're still seeing problems and want to get things working, these will help diagnose which of steps 4-6 are at fault:
- show the output of "ping openbloom.com" and "ping www.openbloom.com"
- show the result that shows on your web browser when you visit "http://openbloom.com/"
Send those to Bonocore, and he'll deliver results for you.
Perhaps you would like to venture a hypothesis as to why OP sees an error message from Akamai if his domain isn't resolving to domains.smugmug.com?
Again, OP has posted actual Wireshark capture results that show precisely how his DNS resolved, you can see that there is no question that his domain name is correctly configured with a CNAME for domains.smugmug.com:
And then precisely the response he received from the resulting Akamai cache server at the A record:
This is considerably more detailed information than the ping results you suggest he collect.
Please check out my gallery of customisations for the New SmugMug, more to come!
Thanks again for your time and input!
As mentioned previously, this relevant error occurs when steps 1-3 (listed in my post above) work but some part of step 4-6 fails. Wireshark only sees 1-3; the very relevant 4-6 are not available to wireshark.
This was exactly the case here, and to be precise, #4 and #6 were regionally faulty at different times and having #6 change added some further complexity.
Thanks :-) So far, so good today. I haven't noticed any problems since I went to bed last night. I'm hoping that all the various parts of this are fixed as well as up to date with my change to Go Daddy. I have hope :-)