The Internet is diverse and large - and the Internet directory system, aka the DNS Infrastructure, supports the diversity and size.
When we setup a new domain, the registrar frequently advises us to wait patiently, before continuing.Congrats on your new domain! Now, we suggest that you wait 24 - 48 hours for the new domain to propagate, before trying to publish to the domain.
When we update a domain - and add or delete a single DNS address - we won't always get advice about waiting, from the registrar.
Responsible helpers will occasionally provide advice to be patient, in Blogger Help Forum: Get Help with an Issue.
After you correct the addresses, please wait 8 hours (2 x "14400" seconds) before continuing. This will let all DNS servers on the Internet receive the corrected addresses.
This advice is generally given, for domains that use a 4 hour ("14400" second) or greater Time To Live or TTL.
Many registrars use a 1 ("3600") or 2 ("7200") hour TTL, for individual domain DNS addresses. Domains with 2 hour or less TTL generally do not require latency advice, because most forum topics take more than 2 - 4 hours to complete.
Adding a domain - and updating a domain - involve different latency.
The difference between "new domain" and "domain update" advice - and irregular presence of either - causes confusion.
Some advice about domain updates involves unnecessary waiting. In other cases, new domain owners jump right in, and try using their new domains, immediately - and regret later.
Moving too quickly, with Blogger custom domain publishing, can lead to Google database corruption. Fear of the apocryphal "Another blog ..." error - and similar Blogger access disruptions - leads many technical helpers to routinely advise unnecessary waiting periods.
People who make changes, and see their changes work immediately, cause similar confusion. Somebody who is advised to wait 2 to 4 hours, before publishing the blog to the domain - and who observe that the domain, perversely, is immediately operational - may misunderstand.
Remember that everybody who wants to read a blog won't have the same DNS service. Differences between one reader (or search engine), and another, will cause various confusions.
Waiting too long wastes time - but not waiting long enough can cause worse problems. For best results, there will be unnecessary waiting, sometimes.
Just be aware of the different latency periods - and try to provide relevant advice.
- Domain addition latency can be 24 to 48 hours ("86400" to "172800" seconds).
- Domain update latency can be 10 minutes, to 48 hours ("600" to "172800" seconds).
Domain addition latency can be 24 to 48 hours ("86400" to "172800" seconds).
Domain addition latency results from the different name servers - and server owners and update policies - all over the Internet. Any given name server updates their local domain master database periodically, by retrieving the zone file from the various master name servers.
If the domain master database on a given server is updated daily - and if your domain was setup 1 minute after the daily update, your domain will not be added to that server until the next daily update.
Now consider that there are thousands of name servers, owned by hundreds of registrars, ISPs, and other Internet services. All local name servers are updated on a schedule considered appropriate, by the owner of each service.
For best results, your domain needs to be indexed on any name server that might be used by any one of your readers - or any one of the search engines that provide necessary search results, for any one of your would be readers. Do you see the possibilities for confusion, for any new domain?
This justifies waiting "24 to 48 hours", so your new domain will be visible to everybody, at the same time. This strategy hopefully will prevent possible Google database corruption.
Domain update latency can be 10 minutes, to 48 hours ("600" to "172800" seconds).
Update of individual DNS addresses will generally be more prompt - and can be researched, using a Dig log or similar display. The TTL latency for any given DNS address - unlike the domain master updates - can be easily adjusted, and determined.
As an example, here is the DNS address which controls visibility of this blog, as shown in a Dig log.
See the "3600" for "blogging.nitecruzr.net"?
See the "3600" for "blogging.nitecruzr.net"? That tells us that "blogging.nitecruzr.net" updates on a 1 hour (3600 second) basis.
All things being equal, and every name server on the Internet properly updating, if I was to correct addressing for "blogging.nitecruzr.net", every name server would be issuing the updated Blogger addresses within 3600 seconds - and the average latency would be 1/2 hour. To increase reliability when advising address correction, I would adviseAfter you correct the addresses, please wait 2 hours (2 x "3600" seconds) before continuing. This will let all DNS servers on the Internet receive the corrected addresses.
Since most Blogger forum discussions about DNS addressing take place over hours or days, a 1 hour latency is generally inconsequential. Keeping it simple, I don't bother with a 1 to 2 hour latency, when providing address correction / update advice.
A 4 hour or greater latency, on the other hand, I generally mention in my advice.
After you correct the addresses, please wait 8 hours (2 x "14400" seconds) before continuing. This will let all DNS servers on the Internet receive the corrected addresses.
When adding a DNS address, as part of address correction, latency will be close to 0 seconds. If you need to retrieve an address for a new host, just defined by the blog owner, you'll either get it immediately from cache on the local name server, or from the local server requesting an immediate update from the domain master server.
Deletions and updates, which reference out of date / redundant addresses, are subject to address latency.
Understand the different latency numbers.
Additions are only relevant for NEW domains - and they lead to the "24 to 48 hour" advice, as the latency involves the Internet infrastructure in general. Address corrections are relevant for UPDATED domains, such as DNS address corrections - and latency is involved on an individual address basis.
By being more selective when we advise waiting "24 to 48 hours", we can provide more consistent and vigourous testing advice - and encourage more effective domain additions and updates. And this will be better for custom domain publishing, in general.
Need More Detail?
For more discussion, you can read:
And, try these DNS Propagation Checkers, for experimentation.
Not every Blogger blog owner understands the cause, and the effects, of DNS latency - or the detail that there are multiple latency figures, which affect custom domain publishing in various ways.
To better plan a custom domain update, it is good to understand the different causes of latency.
We've been advising people about the complications involved in recovering disabled GMail / Google accounts, for a few months. Recently, we've been seeing a new complication, in this scenario.I tried logging in to GMail, and it says that my account has been disabled. So I tried verifying by sending codes to my mobile phone - I managed to log in, and it now redirects into my dashboard. Unfortunately, it now tells meThe blog has been removed.
So, I have my Blogger / GMail account back - but no blog!
Apparently, there is a delay, between reinstatement of the Blogger / GMail account, and recovery of any owned blog(s), deleted when the account is disabled.
Shortly after seeing one's disabled GMail / Google account re enabled, the blog owner will login to Blogger, and see the next disappointment - all owned blogs will probably show as removed (when they are listed, at all). Members of team blogs, even the people whose GMail / Google accounts are not disabled - may see the blog(s) in question disappear from their dashboards, also.
There is good news here. Blogger Support is now aware of this problem, and is hoping to resolve it shortly.
>> Top
We've known for a while that private blogs have limitations, such as latency.
If you originally publish your blog as public, and later make it private, cached copies of the blog will be all over the Internet, for anybody to read, after it's supposedly private. This week, we see another, possibly more serious limitation.Why was my coworker able to read my very private, personal, password protected blog yesterday? I had it set to "Blog Author Only" and yet she found it and was able to read the whole thing.
It has never, ever been public. I started it last September and set the permissions to "blog author only" at the start for all posts. I have never invited anyone else to read it...and have never, ever logged into it at work.
The private blog interstitial may not be loaded, for any would be reader, for several reasons.
The private blog interstitial won't be loaded, before every access to the blog.
People with blog content cached locally - either on their computer, or their network - won't always requires Blogger server access, when a blog page is displayed. Some visitor logs will detect blog access, even when cached content is retrieved - and even when the private blog interstitial is not involved.
Some readers may inadvertently provide access to other network users.
Occasionally, while using slow Internet access, I might load a private blog.
As the blog loads, the browser identifies the various components of the blog, such as various pictures loading, in the browser status area. An odd interstitial notice might be seen.
This blog is open to invited readers only
It doesn't look like you have been invited to read this blog. If you think this is a mistake, you might want to contact the blog author and request an invitation.
This might come up well after the blog main page contents have loaded.
If you are surfing from a network which uses a caching proxy server, it's possible that one person who has permission could properly load the blog in their browser. With the blog having been loaded once, the proxy server may not load the interstitial page again. Anyone else on the network could later view the blog without the interstitial page - even if they do not, supposedly, have permission to do so.
If your Blogger profile is part of your public blogs, or people link to your profile while surfing profiles, and your private blog is listed as one of your blogs, someone may click on the link, and may get a view of the blog.
Invited readers may intentionally share their recently received invitations.
A second problem comes when you invite people as members of your blog. The invitation goes to specific people, who are free to forward the invitation to their other email accounts, and even to the email addresses of their friends. You may invite one person, and you may see a dozen persons later reading the blog. This may even account for a known discrepancy with the 100 member limit.
These security deficiencies are not ones that you can control. You have no way of denying anybody access to your profile, if it's published publicly. Nor can you stop people who you invite to your blog, from forwarding the invitation to their friends.
If you want to keep your blog private, it would be a good idea to at least remove it from the list of your blogs, in your profile.
Private blogs are not immune to referer spam.
Some entries in some visitor logs might make us think that unauthorised people are reading a private blog. Referer spam is not blocked by the private blog interstitial - since referer spam does not involve actual blog access.
As previously stated, visitor logs are not 100% accurate.
These various issues contribute more reasons why no visitor meter will ever be 100% accurate.
DNS, which is the backbone of Google Custom Domain publishing, is a distributed directory of all Internet hosts - like the Google servers where your domain is published.
We say that DNS is a "distributed" service, because the data provided to you, by DNS, resides not in one, or two, but millions of servers - all over the Internet, and owned by many different companies and individuals.
When you setup a new domain, using a DNS Management utility provided by your domain registrar or another DNS host, you can add the DNS entry when convenient to you. Some DNS management utilities will provide advicePlease wait 12 to 24 hours before trying to use your new URL.
or a similar message, simply because the DNS information that you enter, through the utility to your DNS server, has to be distributed to the other DNS servers, all over the Internet.
If your registrar's DNS servers aren't immediately accessible to the Google servers, and you try to publish to your brand new personal domain, you may see problems.
Seconds after you setup the new domain with your registrar, the Blogger "Advanced Settings" wizard may not be able to access the DNS entries which you just created. You'll probably see an old friendAnother blog is already hosted at this address.
where the wizard is simply saying to youWe don't see that domain pointing to "ghs.google.com".
In an alternative scenario, your registrar may be immediately accessible to the Google servers, you publish your blog to your custom domain, and you're happy. But wait - there's more! One of your readers, on the other side of the world, sees your advertisementHey! Checkout my new non-BlogSpot URL for my blog!
and checks it out, and gets another old friend404 Not Found
because your reader uses a DNS server that has no immediate access to your registrar.
The latter two scenarios involve you when you manually set up your custom domain - using your registrar's DNS utility, followed by the Blogger "Advanced Settings" wizard. If you use the Blogger "Buy A Domain For Your Blog" utility, you use neither of those wizards.
The latter wizard takes a mere few seconds, when you're properly prepared. That wizard, replacing both the registrar's utility and the Blogger "Advanced Settings" wizard, can't include a 12 to 24 hour delay. So instead of the wizard taking 12 to 24 hours, it does immediately the work of the registrar's setup, and queues up a separate task - the equivalent of the "Advanced Settings" wizard - to run after the (formerly) "12 to 24" hours. To make sure that the "12 to 24" hour period is not too short, Blogger gives you (the DNS system) "72 hours" to catch up.
When you finish the purchase and setup of your new custom domain, go to your dashboard, and click on the "View Blog" link. There, you will likely see an old friend in the makingYour blog is in transition
Unfortunately, as I state above, the observed transition period has been 72 hours, not "12 to 24 hours". During the 72 hours (currently, slightly longer)- The blog contents will be published, using the new domain URL.
- The BlogSpot URL will continue to load the blog with the BlogSpot URL.
- The custom domain URL "mydomain.com" will load the blog with the domain URL.
- You will, effectively, appear to have 2 separate blog aliases.
- Accessories like Following will issue mysterious error messages.
We're sorry...
This gadget is configured incorrectly. Webmaster hint: Please ensure that "Friend Connect Settings - Home URL" matches the URL of this site.
During the transition period, consider carefully the dual personality of the BlogSpot URLs. Remember that the "www" alias of the BlogSpot URL does not simply redirect to the root of the BlogSpot URL, in the same way that the root of the custom domain URL might redirect to the "www" alias. Expect unpredicted behaviour here, when comparing the BlogSpot URLs.
If you are concerned with search engine reputation and visibility, and are diligently keeping your blog's sitemaps updated, you'll want to consider these issues carefully. You should wait until after the transition period has ended, to update the sitemap.- You don't want the search engines trying to index a URL that might give them a "404" from their own DNS servers not having your new domain.
- You don't want the search engines trying to index the new URL while the old one is still active, and distinct, lest both the BlogSpot and domain URLs be perceived as "duplicate content".
- You don't want the search engines to start indexing the domain URL, until the BlogSpot URL provides the "301 Moved Permanently" to the domain URL, and gives the new domain its starting kick.
- You do want the search engines to start, re indexing the entire blog, as soon as possible - after migration completes.
Timing is everything, here. Wait until the Transition period ends, and the "301 Moved Permanently" is in effect. Be aware of the issues - and manage the migration, aggressively.
If you purchased the domain using "Buy a domain", the above details are not a problem, because Blogger applies the Transition time period, automatically. If you setup the domain yourself, after purchasing from a registrar - as is the case for every domain purchased after 2012 - you need to maintain a Transition period, yourself, or expect problems, during the first week or so.
