Custom Domain Publishing, And DNS Latency

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 advise

After 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:

• Ezine: DNS Propagation Explained - or Why You Have to Wait the 72 Hours
• InterMedia: What is DNS propagation?
• WebHosting: What is DNS propagation and why does it take so long?
• WikiPedia: Domain Name System

And, try these DNS Propagation Checkers, for experimentation.

• dnschecker.org
• preshweb.co.uk
• whatsmydns.net

---

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.

AutoSave, And Draft Mode Post Editor

Recently, we've been seeing a few reports, in Blogger Help Forum: Get Help with an Issue, suggesting more problems with Post Editor, in Draft mode.

I keep getting an error, when editing my posts.

An error occurred while trying to save or publish your post. Please try again.

I am editing Draft posts, some of which are fairly large.

This blog owner is discussing yet another facet of the Post Editor feature, AutoSave.

Early AutoSave Experience

Long ago, people would report a different problem, when composing posts.

When I compose my post, my typing is way ahead of what is displayed.

Blog owners, long ago, discovered that AutoSave, which applied to posts being composed before publishing, made their computers slow down. This made their on screen post content show noticeable delay, from their typing.

With newer and more powerful computers, and people who still type at the same speed, Post Editor slow down has become a thing of the past - but at a price.

With highway traffic engineering, a well known problem involves the regional effects of upgrading a local arterial street, to handle more traffic. This might improve traffic in your neighbourhood, but at the expense of another highway in the next city.

Similarly, upgrading the speed of your computer improves your Post Editor typing problem, but puts more load on the networks and Blogger servers. Thus we see the symptom, reported above.

An error occurred while trying to save or publish your post. Please try again.

Pre AutoSave Experience

As you compose a post, what you type is saved on your computer - and displayed in Post Editor. This lets you see what you are typing, in a "what you see is what you get" display. If you hit "Save", periodically, what you have typed gets saved to the Blogger servers.

Originally, many blog authors did not think to Save, when composing a post. Some would just type - then eventually Publish, when convenient. This technique created two problems.

1. The longer an author waited before Publishing, or Saving, the greater the chance that something would happen with the computer being used, causing loss of what was being typed. And the greater the catatrophe from the loss.
2. The longer the author waited before Publishing or Saving, the more work would be done by the Blogger servers, when the author finally did Save, then Publish.

Blogger added AutoSave to Post Editor, so the effects of Publishing massive amounts of unsaved post content would not affect Blogger resources so abruptly - and so less people would see their hard effort go down the drain.

Current AutoSave Experience

One known problem with AutoSave is that it generates load on the local computer, on the networks connecting to Blogger, and on the Blogger networks and servers - thus the slow typing problem, long ago.

Another problem is that it saves automatically (hence the name) - and for some people, who may have just cleared the contents of a post, AutoSave saving an empty post tends to cause a problem. The longer people work on pages or posts, without publishing, the greater the chance that this disaster may happen.

Unfortunately, having a more stable publishing process, thanks to the reverse effect of AutoSave, will just encourage people to take longer before Publishing or Saving. Thus the complaint.

I was working on my new post for weeks. Right in the middle of highlighting a section for deletion, AutoSave kicked in, highlighted the whole post, deleted the highlighted section, and saved an empty post. How do I get my post back?

And for this unhappy author, there can be no helpful answer.

Future AutoSave Prognoses

For a while, I've been suggesting that when possible, you should publish a post immediately, then continue editing your post after publishing - since AutoSave only affects post editing, before the initial Publish. Recently, I discovered that it may be possible to use Google Docs as a Content Management System, for long term post development.

A third possibility is that you compose your unpublished posts in HTML mode, instead of Compose mode. The effects of AutoSave, in HTML mode, are not as objectionable. Some of my posts, I might develop for a week or two before Publishing, using HTML mode. If you use this technique, and you include anchor links in your posts, beware of switching back and forth between Compose and HTML.

A fourth alternative, use of Microsoft Word instead of Google Docs, is known to cause problems with auto pagination and with various posts newsfeed accessories. We do not recommend use of Microsoft Word.

However you develop a post, the longer you wait before Publishing, the greater the chance that AutoSave will make you unhappy - either by sudden destruction of your post - or by contributing to the latest symptom.

An error occurred while trying to save or publish your post. Please try again.

Publish sooner, develop offline, or become a victim.