The "Buy A Domain" Wizard Has Limited Selections For TLD

The ability to publish a Blogger blog to a non BlogSpot URL is becoming a known - and desired - option for many bloggers. And with the retiring of FTP Publishing, many bloggers are turning to Custom Domain Publishing. Not everybody is satisfied with the TLD choice of ""com", "net", "info", "org", or "biz"", though.

• Some folks would like to publish to a "vanity" TLD, like ".me", ".tv", or ".us".
• Others would like the country relevant TLD of their residence, like ".au", ".de", or ".in".
• And I have seen one or two queries about using a ".gov" TLD.

Custom domains will support use of any properly registered domain that you can "buy". The limitation is with the "Buy a Domain" wizard, which lets you select only a ".biz", ".com", ".info", ".net", or "org" generic Top Level Domain. Additional TLDs are available from eNom or GoDaddy, or any third party registrar that you can use.

When you choose your registrar, please make sure that your prospective registrar will provide "4 x "A" / "CNAME"" referral - that choice is essential, for a reliable custom domain. That is the basic requirement.

>> Top

Deactivation Of The Google Sites Or Start Page Service

Unsolicited redirect to a Google AdServices, Sites, or Start page is a very common cause, right now, for the well known custom domain symptom "Another blog is already hosted at this address". And, it's a reasonably easy symptom to correct.

Start by logging in to Google Apps.

• If you're not registered for Google Apps, you'll have to register. Now that the Free Google Apps is not provided, you may have to setup a Trial version, to use Google Apps.
• If you just purchased your custom domain, using the "Buy A Domain For Your Blog" wizard, you're going to have to find your registration information and login to Google Apps.
• If you just bought your domain directly from eNom or GoDaddy (not using "Buy A Domain"), or from a third party registrar, you're going to have to setup a new Google Apps account, to start.
• Do not delete the Apps desktop account - deletion of the Apps account will not accomplish anything.

Then, deactivate the AdServices, Sites or Start Page service.

• When you login, you will be at the Google Apps Dashboard. If you're logged in using an account with administrative authority, you'll have the links that you need, there in front of you.
• You disable and enable a service, and set the publishing address, from the service settings screen.
• If simply disabling the service in question is not productive, you'll need to recycle the service settings. This will involve slightly more work.

If your Apps dashboard does not include a shortcut for the service that's a problem for you, you may be able to add that service to the dashboard, then deactivate it. If the service in question isn't on your dashboard, and you can't add it to your dashboard, then you'll have to do the full domain settings recycle, to methodically reset the "Another blog is already hosted at this address" symptom.

The Google Apps Services

You install and activate any needed service, using the "Organization & Users" - "Services" wizard.

The Service Settings Screen

You disable a service, and set the publishing address, from the service settings screen. You access the service settings screen using the "Settings" menu entry on the far right - or the "View all settings" dashboard link.

The CustomURL Screen

Besides the multiple mappings which may be active for Sites, you can display all installed services, and their mappings, using the CustomURL screen.

---

Note:

• Having disabled the service, or removed the web address mapping, never forget to publish back to Blog*Spot, then re publish to the custom domain.
• If simply disabling the service in question is not productive, you'll need to recycle the service settings. This will involve slightly more work.
• Do not delete the Apps desktop account - deletion of the Apps account will not accomplish anything.

---

>> Top

The Safari Browser And The FTP Blog Redirect Intersticial

I've been writing about browser display differences for a while - known differences between Firefox and Internet Explorer are legendary. Most differences, though, are in how the blog gets rendered - simply different display appearance. Cosmetic issues, not all so minor but still cosmetic.

Then we have the case of "run4istrun.blogspot.com", which is intended to be published to "run4istrun.com". The problem was originally reported as "blogspot URL not redirecting as Blogger says it should (for an FTP Published blog)", as indeed it wasn't redirecting, when viewed in Safari. In the latter case, it was just another "404 Not Found".

One intermittent problem with FTP Publishing is that blogs published using FTP are having an annoying redirect notice (called by Blogger Support, the "interstitial"), implying some degree of possible insecurity, inserted in front of the home page when the BlogSpot URL is loaded. I reported this, first, several months ago. The Safari browser, in this case, simply causes more confusion.


This is what you expect (though not prefer) to see, in Firefox.

You're about to be redirected.

This is what you see, in Safari, run in Windows.

You're about to be redirected.

This is what you see, in Safari, run in Apple.

This page can't be found.

A significant difference there, folks. Safari users, beware.

>> Top

FTP Publishing and Complications From Authentication

Long ago, when you attempted a two factor authentication (account name / password) process with a server, the normal connection procedure would verify for the existence of a given account, and verify the password against that account. If either verification failed, a properly written server based script would tell the user what he was doing wrong - either "Invalid account" or "Invalid password".

Then security experts realised that if you issue an error saying "Invalid account", you were, in effect telling a possible intruder what accounts did not exist on the server in question - enough connection attempts would then tell an intruder what accounts did exist. This is a known hacking technique, called by some security experts "account name mapping". Knowing the existing accounts, the hacker can then try to guess the passwords on those accounts.

Some secure servers, made resistant to mapping, don't issue any error messages, they simply ignore your unsuccessful attempts (non existent account or invalid password) . Make too many unsuccessful attempts, and your IP address gets blackholed.

If you're a person trying to connect, you just keep trying - try another password, or another account name. If your IP address is blocked, you wait a while (5 minutes or so) and try again.

But what if you're not a person connecting interactively, but a person running a script? Like publishing from Blogger by FTP, to a distant host server? That complicates matters.

One of the problems with establishing a connection with a distant server is not knowing if the server in question is there, or is there but not responding, or is there but intentionally ignoring you. The Blogger FTP publishing script has to allow for all of these possibilities. Blogger doesn't want for you (really, they don't) to sit and watch the Spinner Of Death any longer than you want to watch it. They also don't want to come back to you and say

We can't publish today, the other server isn't answering.

It's a tuning issue. Wait too long, and the bloggers get impatient. Don't wait long enough, and the bloggers get angry. Each distant host server will have different connectivity issues, and the issues will vary by current load, and by network status.

So add the authentication process on top of that, and add some servers that will simply ignore improperly authenticated connections. How is the Blogger FTP Process realistically expected to reliably connect (or not) to all distant host servers? Especially with some problems knowingly tolerated by the operators of the distant host servers?

So the next time that you can't publish your blog to your distant host server, don't just get into the forum and yell

Hey everybody, Blogger is hosed again.

Do some diagnostic work first. Please.

>> Top

FTP Publishing - Another Example Of The Complexity

Not all problems with FTP Publishing are caused by Blogger, directly or indirectly. Sometimes, the operators of the host servers, involved in the FTP publishing process, provide subtle yet significant clues to bigger problems. You have to keep your eyes open, though.

Here is an example, with a customer of Network Solutions.

My host is Network Solutions - yesterday they sent an e-mail reading

We are aware of an issue with FTP and UNIX packages. They will generally deny the first connection, but allow subsequent connections. We are requesting that our customers attempt to connect to their server twice until we have a resolution.

Blogger isn't going to (in reality, they can't, reliably) tweak their FTP publishing process to repeatedly attempt a connection with a host server, just because the operators can't solve their own server problems. This is a case where the customers have to get involved, and convince the server operators to fix their server problems.

>> (Update 8/25 5:00): It appears that this problem was related to security at Network Solutions.

Blogger publishes with "passive FTP". To overcome this, Network Solutions identified the IP addresses from which Blogger publishes, then "white-listed" those addresses to its servers so they would accept FTP uploads from Blogger.

>> (Update 8/4 14:00): We have an interesting communication (edited) from Network Solutions.

Hi this is Connie at Network Solutions. I’m writing to affirm that our engineering team is aware of the issue and they’re working diligently to resolve it. It’s a short-term issue, and we’re sorry about the difficulties you’ve experienced along the way. If you would, please try to reconnect to your server. If you continue to run into a snag please contact me at (email address edited).

>> Top

Path Variances When Publishing By FTP

Occasionally, settings which identify the location of your blog, relative to the FTP folder on the server where your blog is hosted, may change. Some changes may be related to changes at Blogger, other changes may be related to changes in the server itself. Symptoms may vary, but will typically mention denied access, or missing content.

Access is denied.
Requested action not taken: file unavailable.
The system cannot find the path specified.

Most frequently, the change required will be the relative root designation. The change will probably involve the main publishing path ("Settings" - "Publishing" - FTP Path) and / or the archives path ("Settings" - "Archiving" - Archive Path).

• If the current value is ".", change it to "/".
• If the current value is "/", change it to ".".
• If the current value is, for instance, "blog", change it to "/blog".
• If the current value is, for instance, "/blog", change it to "blog".

Publishing by FTP, to remote (third party) servers can be a challenge, and one of the unpreventable challenges will be the unpredictability of the third party maintenance policies. Try and be aware of changes being made, and encourage the support staff for the servers to provide you some documentation describing changes, when possible. Barring that, get used to trying these changes, on your own, when things stop working.

And, try to resist the temptation to blame Blogger for every problem. Some problem will require you, or you and the server support staff, to sort.

>> Top

Diagnosing Problems With Custom Domains - Case Study #8

Some time ago, I noted a technique being used by Blogger to combat the spread of spam blog referrals, which was creating some inconvenience for legitimate blogs using custom domains.

That inconvenience seems to continue, even today. A prettier display, but the same inconvenience.


This isn't good for your readers - nobody wants to surf to possibly malicious content - intentionally or otherwise. Nor is it good for your search engine reputation - this extra page will stop the spiders cold. Check your Google Webmaster Tools Logs if you see this one day, if you don't believe me.



Let's look at the browser logs for myblog, and mydomain.

7/14/2008 09:24:54  Trying http://myblog.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Date: Mon, 14 Jul 2008 16:24:56 GMT
Expires: Mon, 14 Jul 2008 16:24:56 GMT
Cache-Control: private, max-age=0
Content-Length: 3473
Content-Type: text/html
Server: GFE/1.3
Connection: Close

Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Date: Mon, 14 Jul 2008 16:24:58 GMT
Expires: Mon, 14 Jul 2008 16:24:57 GMT
Cache-Control: private, max-age=0
Content-Length: 3473
Content-Type: text/html
Server: GFE/1.3
Connection: Close

Neither redirect contains the new location, so the search engines won't update their records to indicate your new custom domain. That's not going to give your new URL any reputation at all.

Compare that with the log for this blog, "bloggerstatusforreal.blogspot.com".

7/14/2008 09:30:01  Trying http://bloggerstatusforreal.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://blogging.nitecruzr.net/
Content-Type: text/html; charset=UTF-8
Date: Mon, 14 Jul 2008 16:30:04 GMT
Expires: Mon, 14 Jul 2008 16:30:04 GMT
Cache-Control: private, max-age=0
Content-Length: 212
Server: GFE/1.3
Connection: Close

See the "301 Moved Permanently" here?

HTTP/1.0 301 Moved Permanently
Location: http://blogging.nitecruzr.net/

That's where the search engines pick up my new URL - "blogging.nitecruzr.net". And that's one of the benefits of having a properly operating custom domain.

>> Top

Server Changes At GoDaddy, And FTP Publishing Problems

Publishing a Blogger blog by FTP, to a third party server, presents a challenge, may I risk making an understatement. Bloggers choosing to host their blogs externally have traditionally been subject to numerous experiences, not all good. One of the least enjoyed is possibly seeing the advice

Your publish is taking longer than expected. To continue waiting for it to finish, click here.

It appears that a recent server change (some time in the last 3 to 6 months) at GoDaddy may be at least partially responsible for some of the FTP Publishing experiences, such as the latter advice.

GoDaddy appears to have 3 server configurations right now.

1. Linux, "hosting configuration 1.0", PHP 4.x.
2. Linux, "hosting configuration 2.0", PHP 5.x.
3. Windows, ASP.Net 1.1, IIS 6.0 .

In at least one case, service moved from Linux configuration 1.0 to configuration 2.0 appears to be related to the symptom discussed above.

According to the Original Poster in the thread linked above, service migrated from Linux V1.0 to Linux V2.0 is not reversible. That's not an unusual restriction for any IT service methodology. Unfortunately, that left him with the sole option of moving to the third configuration, hosting on a Windows platform. People changing from Linux to Windows server hosting (or vice versa) should be aware of some significant technical differences between the two platforms, such as (but probably not only) differences in case sensitivity and in path description.

>> Top

FTP Publishing and the Complexity

Blogger is constantly fixing problems with FTP publishing, and more problems come up at the same time. Anybody who says that there is one problem, and waits for the one problem to be fixed, is assuring that the one problem won't ever be fixed.

FTP Publishing involves scripted communication with hundreds of different "servers" (with Blogger acting like a "client") all over the world. Each different server, being owned by a different company, will be different from each other server; and each server will have different problems, which make the the Blogger scripts progressively more complex. Sometimes, changes by the server owner to some, though not all servers, may make a difference.

And just because you were able to publish to your blog last week, that doesn't assure that you will be able to publish this week. Nor does it assure that somebody else will be able to publish today.

What all of this means is that anybody who insists that his problem has to be fixed by Blogger, and waits while Blogger fixes it, will possibly be waiting a good long time. Some problems will involve you, and some will involve your server host support team. Each problem really should be attacked by three parties, working together.

When you have problems, checking your settings, and verifying them against updated instructions from your host support team, is a good place to start. Maybe a look at the server access logs is a good idea too.

Just don't post your complaint, go about your daily business, and wait. Get to work, and get involved.

>> Top

Diagnosing Problems With Custom Domains - Case Study #7

Google Apps, which I originally identified in my second custom domain case study, and later in a separate article, Custom Domain Publishing, And Google Apps, is what I shall call a Web Services Aggregator. Google Apps gives us the ability to combine a Blogger blog using a non-BlogSpot URL in a domain with other Google and non-Google services.

Google Apps is not the only web services aggregator that we have identifed recently. Yahoo provides a similar setup.

Let's look at a Yahoo Web Services setup, using a hypothetical domain, "mydomain.net" (name changed here to protect the unfortunate).

First, let's dig the DNS records for the primary domain "mydomain.net".

 ;; QUESTION SECTION:
 ;mydomain.net.   IN A
 
 ;; ANSWER SECTION:
 mydomain.net.  1200 IN A 68.180.151.21
 mydomain.net.  1200 IN A 68.180.151.22
 mydomain.net.  1200 IN A 68.180.151.23
 mydomain.net.  1200 IN A 68.180.151.24
 mydomain.net.  1200 IN A 68.180.151.25
 mydomain.net.  1200 IN A 68.180.151.26

p2w12.geo.sp1.yahoo.com (68.180.151.21)
68.180.128.0 - 68.180.255.255
Yahoo 

Next, the "www" alias "www.mydomain.net".

 ;; QUESTION SECTION:
 ;www.mydomain.net.   IN A
 
 ;; ANSWER SECTION:
 www.mydomain.net.  600 IN CNAME ghs.google.com.
 ghs.google.com.  40765 IN CNAME ghs.l.google.com.
 ghs.l.google.com. 300 IN A 72.14.207.121

You'll have no problem with publishing to "www.mydomain.net", as the primary URL for "mydomain.net". I don't think that Yahoo Web Services provides an option to "Redirect mydomain.net to www.mydomain.net.", though.

Yahoo provides 6 servers, in contrast to 3 provided by Google. To date, nobody has succeeded in configuring the 6 Yahoo servers to address anything but Yahoo content. This makes Yahoo Web Services useless for using the primary domain in a Google Custom Domain.

>> Top

Custom Domain Setup, Your Blog, and Your Readers

Periodically, someone interested but uncertain asks about the practical effects of publishing their blog to a custom domain.

Will all the posts (the comments, the customised template, ...) be the same?

or

Will my readers be able to find my blog?

or even

Will I lose Page Rank, and if so, how long?

These are all valid concerns.

Publishing your blog to a custom domain is pretty much like publishing it to another BlogSpot URL, except you end up with two (maybe 3) URLs, each of which will work equally well.

• The BlogSpot URL.
• The primary URL for the domain.
• A possible secondary URL for the domain.

There's no visible change to the content - it simply republishes to the new (non-BlogSpot) URL. If you want to go back to normal publishing, you republish to BlogSpot. Simple?

Since the BlogSpot URL continues to work, everybody who has the BlogSpot URL bookmarked can continue to access the blog, transparently. You'll experience a brief loss of page rank, but you'll still get some traffic from your established readers, and from the search engines, and other robotic services.

You will have to update your membership in external services, such as search engines and similar robotic processes.

If you are vigorously attentive to the needs of your readers, and external services, your search engine reputation / Page Rank will pick up, somewhat faster than you acquired it originally. And if you publish content and update the blog at the same rate as before you got the custom domain, your search engine reputation / Page Rank will keep on going up, after it has regained its former level. And that's what a custom domain will do for you.

>> Top

FTP Publishing and Network Issues

I've been discussing FTP Publishing, and comparing it to native BlogSpot and Custom Domain publishing, for many months. Besides the functionality and style differences, there are network issues - several key differences between custom domain and FTP publishing, which cause problems. The problems will come and go, and will randomly affect a different segment of the blogger population each time.

• Authentication. Blogs published by FTP are copied to servers with differing, and not always appropriately maintained, authentication policies.
• Control. Blogs published by FTP are copied to servers that aren't owned or supported by Google.
• Distance. Blogs published by FTP are copied to servers that are distant from Google.
• Dynamics. Blogs published by FTP are published statically. Each time a post is published, the entire blog is copied to the distant server.
• Overall. Looking at these issues, what should we expect?

Authentication
Authentication, the process of establishing your identity, and your right to access a given host server, isn't a simple process. Modern security precautions contribute to problems with establishing an authenticated FTP connection.

When you publish your blog to a Google server, you're already authenticated. This is simply not an issue.

Control
There are hundreds of servers, each with a different owner, that are used for FTP published hosting. Each server, with a different owner, will be setup and maintained differently. Sometimes, a server owner may even change the configuration on some, though not all, servers. Even though any single detail of the setup or maintenance, of any server, can affect the ability of Blogger to communicate with that server, Blogger has no way of knowing what problems it may face at any time. Any given server, that was successfully published to yesterday, may change at any time. Some controls may depend upon documentation by Blogger, which however benevolent the intent, simply won't be 100% reliable.

With blogs published to a Google server, the entire publishing process is controlled and supported by Google. Every detail of each server is predictable. This makes publishing to a Google server much more reliable.

Distance
The hundreds of FTP published host servers are located all over the world. Besides the ownership factor, the distance factor is different for each server. A constantly changing distance (and network speed) between the Blogger servers and the FTP publishing hosts servers makes for a challenge, and ever varying stability.

With blogs published to a Google server, the entire publishing process is local. Both Blogger and BlogSpot / Google servers are on the same network, again owned and supported by Google. This makes publishing through the Google network much more reliable.

Dynamics
When you publish a blog using FTP, you're doing static publishing. The entire blog is copied from the Blogger server to the FTP publishing host server.

Most Blogger blogs have Layouts templates and are published dynamically. Do you remember the Spinner of Death? For most of us, it's but a distant memory, as our publishing process involves each blog post, dynamically. If you publish or update 1 post, that's all that gets published, and that only when the post is initially referenced. If you update the template, each post is, again, published when it is referenced.

This lets you, the blog owner, get on with your life and work on the next post, while your readers initiate the actual publishing of the posts. The older posts don't even get republished at all, if they aren't needed (read by the blog readers). With the majority of bloggers using Layouts templates and dynamic publishing, you'll find that Blogger resources will be allocated for that.

When you publish a blog using FTP, the entire blog gets copied to the FTP publishing host server, each time that you publish a post, or each time that you update the template. Many blogs published by FTP are commercial in nature, making the average blog larger (you have to pay for blog hosting, and larger blogs are generally more profitable), and constantly growing even larger still. FTP publishing may be done from less Blogger servers too, increasing the overall workload on the specific servers used for that task.

Absolute size * ever increasing size * the necessity of copying the entire blog each time you publish * possible resource limitations makes static publishing a significant problem.

The Overall Effect
Taking these issues together, do you not see a problem? Combining authentication issues * lack of control * distance and network issues * static publishing issues, produces inevitable results.

• Speed. You never know how long a blog is going to take to publish, at any time.
• Stability. You never know if a blog is even going to publish successfully, at any time.

But wait - - there's more.

One of the challenges of FTP publishing is the diagnostics (or lack thereof) when publishing. If you can use an FTP client interactively sometime, watch the FTP log as you copy a file. You'll see a command or two when the copying process finishes, and a response from the FTP server when the copying finishes.

What if the FTP server simply stops responding? This will happen, and the client server (or Blogger script) has no way of knowing when this happens. At any time, if the script has not finished a copy, there's no definitive way to tell if the script (the copy process) will ever finish. Combine the speed and stability issues, and how do you know if an FTP copy process will be successful?

The Blogger script can only estimate how long the publishing should take, run a timer, and stop when the time expires. If the timer expires before the copy finishes, the copy is aborted, and your publishing doesn't complete. Or, you watch the Spinner Of Death for an eternity, before giving up.

Watch It Spin.

Small wonder that Blogger Support would prefer that more people publish to Google servers.

>> (Update 9/4): Besides the many details discussed above, there are two newly discovered tweaks, which have provided relief to some.

>> Top

Custom Domains - The Details In The DNS Settings

I've been helping people set up their custom domains for over a year now. We've dealt with simple setups, and complex setups - from a domain setup in 5 minutes using "Buy A Domain For Your Blog", to ones that take much longer because the domain itself is in use and requires Google Apps configuration. Occasionally, odd questions come up

Chuck, what is "3600"?

or

Does my blog have to be published to either "mydomain.com" or "www.mydomain.com"?

or

Do I have to point the blog to "ghs.google.com"?

The latter question wasn't easy to answer intelligently, basically I answered

You can point the DNS to any host name that you wish, but if you want a working custom domain, stick to "ghs.google.com", and lets get this done.

For an answer to the first two questions, and others, let's look at the setup process. Within the setup process, let's look at how this blog, "blogging.nitecruzr.net" is defined as a logical host in my domain, "nitecruzr.net".

If you're here looking for instructions on getting rid of the address entry for the recently decommissioned Google Apps server, see The GoDaddy Domain Manager: Removing An Address Entry.

You start with the GoDaddy Domain Manager, with the domain loaded. In this example, my domain is "nitecruzr.net". Once you're logged in, you do not re enter the domain name when you add an alias. Only enter the alias name, when prompted for "Alias".

Add One Virtual Host

blogging.nitecruzr.net. 3600 IN CNAME ghs.google.com.

Simply hit the "Add New CNAME Record" button, and you get the "CNAME (Alias)" applet.

• The Alias Name you enter as "blogging".
• The Host Name you enter as "ghs.google.com".
• TTL for .net domains defaults to 1 hour (3600 seconds).

Having successfully created the new CNAME record, we see it listed with the others.

• Host is "blogging".
• Points To is "ghs.google.com".
• TTL is 1 hour.

Add One Complete "SubDomain"

Some folks refer to this as a "subdomain", though it's actually 5 virtual hosts. This example shows an ASymmetrical DNS configuration.

nitecruzr.net.  3600 IN A 216.239.32.21
nitecruzr.net.  3600 IN A 216.239.34.21
nitecruzr.net.  3600 IN A 216.239.36.21
nitecruzr.net.  3600 IN A 216.239.38.21
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.

Do you see the 3 "@" entries for IP addresses "64.233.179.121, 66.249.81.121, and 72.14.207.121", in the "A (Host)" section? That's the 3 Google Apps servers previously defined for the primary domain ("@"). If you were setting the domain up initially, you would hit the "Add New A Record" button 3 times 4 times, and enter the 3 servers (as of 2008/12, we have 4 Google Apps servers - the 3 are now offline), using "@" to designate the primary domain, each time. You would next add a "CNAME" for the "www" alias, pointing to "ghs.google.com", using "www" to designate the "www" alias.



Note: When you define the destination of "ghs.google.com", be aware of whether your DNS host is configured to accept "ghs.google.com" as an absolute or a relative address. This is an essential distinction, and may not be universal.

Now, let's examine a brief Dig log for the new alias, "blogging.nitecruzr.net".

;; QUESTION SECTION:
;blogging.nitecruzr.net. IN A

;; ANSWER SECTION:
blogging.nitecruzr.net. 3600 IN CNAME ghs.google.com.
ghs.google.com. 586847 IN CNAME ghs.l.google.com.
ghs.l.google.com. 203 IN A 72.14.207.121

blogging.nitecruzr.net. 3600 IN CNAME ghs.google.com. This was provided by my DNS server, after I entered it above.

• "blogging.nitecruzr.net." is the defined host name. The "." at the end makes it an absolute host name. You will always define an absolute host name.
• "3600" is the TTL, in seconds. "3600" specifies a TTL of 1 hour.
• "IN CNAME" is the syntax which defines a "CNAME" referral.
• "ghs.google.com." is the referred host name, again specified as an absolute address.

ghs.google.com. 586847 IN CNAME ghs.l.google.com. This was provided by "ghs.google.com".

• "ghs.google.com" is further referred to "ghs.l.google.com".

ghs.l.google.com. 203 IN A 72.14.207.121 This was provided by "ghs.l.google.com".

• "ghs.l.google.com" currently refers to the server at "72.14.207.121". "ghs.l.google.com" is a load balancing proxy server. If the server at "72.14.207.121" had been offline or busy, you would have a different IP address here. This is why we always use a "CNAME" referral to "ghs.google.com" for a proper custom domain definition.

When you define your alias, you only add the first of the 3 records above. The latter 2 are provided by the Google servers.

The URL of this blog is "blogging.nitecruzr.net". If the DNS server that services your computer requests the IP address of the blog, it will be told, by the DNS server that services the blog, to "ask the host ghs.google.com". After "ghs.google.com" has provided an IP address, that address will be retained ("cached") by your local DNS server for 1 hour.

>> Top

Custom Domain Publishing, And Google Apps

I've been writing about setting up a Google Custom Domain for a while, and I've described the process of setting them up, and various configurations that are produced from the setup. Most of the setup processes have focused on new domains, where the blog owner simply wants to publish the blog to a non-Blog*Spot URL, and no complications exist.

But what if you want to use different services in your domain, which you may or may not be already using? Maybe you have email, an FTP server, and / or a third party (non-Google) web site, hosted on a third party server.

Or, maybe your DNS host won't let you redirect the primary domain using a "CNAME" referral.

That's what you use Google Apps for - integrating existing and new domain components.

Let's look at this domain, "nitecruzr.net", which I setup using the "Buy A Domain" wizard. You can do the same, or use Google Apps, which will give the same results for you without a lot of work. Or, if you already have your domain, and it has existing services, you can setup the domain in Google Apps manually.

First, you setup the DNS for the domain, using the domain manager wizard provided by your DNS host. You may find Custom Domains - The Details In The DNS Settings, to help you understand the information provided in the Dig logs, presented below. You may also wish to read about proper DNS configurations, and alternately about improper DNS configurations.

Let's examine a brief Dig log for the primary domain "nitecruzr.net".

;; QUESTION SECTION:
;nitecruzr.net.   IN A
 
;; ANSWER SECTION:
nitecruzr.net.  3600 IN A 64.233.179.121  <<== Do not include this server - See Below.
nitecruzr.net.  3600 IN A 66.249.81.121  <<== Do not include this server - See Below.
nitecruzr.net.  3600 IN A 72.14.207.121

There are the 3 Google Apps servers - and currently, only 1 of them is active. If we directed the primary domain to "ghs.google.com", you'd lose any email, FTP, and other special services, because "ghs.google.com" doesn't provide special services. Instead, we use Google Apps.

Next, a brief Dig log for the "www" alias "www.nitecruzr.net".

;; QUESTION SECTION:
;www.nitecruzr.net.  IN A
 
;; ANSWER SECTION:
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.
ghs.google.com.  586847 IN CNAME ghs.l.google.com.
ghs.l.google.com. 203 IN A 72.14.207.121

There we have "ghs.google.com". You will probably publish the blog to the "www" alias, and redirect the primary domain to the "www" alias, using Google Apps. See Google Custom Domains - The Two Step Domain Referral for detailed explanation.

Effectively, and showing what I call an excerpted Dig log, you should have

nitecruzr.net.  3600 IN A 64.233.179.121
nitecruzr.net.  3600 IN A 72.14.207.121
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.

And, remember to setup an updated sitemap, when it is all working.

If you get the well known "Another blog is already hosted at this address." error, and your DNS is absolutely setup per the above advice, recycle the domain settings in Google Apps. If you get another well known error, "404 Server Not Found", publish the blog back to its BlogSpot URL, then re publish to the "www" alias.

Having done the above, you'll have one blog published to your domain. If you have a multiple blog domain, this will be your "home blog", similar in function to my blog "www.nitecruzr.net". If you want more blogs published to your domain, you setup a virtual hosts cluster, ala my blogs "blogging.nitecruzr.net" and "recipes.nitecruzr.net".

(Update 10/13/2008): The complement of servers, as described above, has been changed.

>> Top

FTP Publishing - Moving Ahead

Some time ago, in my comprehensive comparison of Custom Domain vs FTP Publishing, I suggested that

FTP publishing has a limited life span. From an economic and support viewpoint, it makes more sense for Blogger to concentrate its attention on Custom Domain publishing.

This week, we have a new, annoying problem with FTP publishing, which, regardless of what may or may not be stated by Blogger, does not seem to be solved. And we have a possible reliability improvement in custom domain publishing, with the dreaded "404 Not Found" problem, recently, becoming less frequently reported.

It's possible that my prior suspicion may become reality sometime in the near future. Some of you, currently publishing your blogs using FTP Publishing, may do well to consider changing to Custom Domain Publishing. And in doing so, you should consider several key issues.

• If you initially published your blog to the FTP server prior to November 2007, it's possible that the original BlogSpot URL isn't associated with the external URL. If the BlogSpot URL is associated with the blog, it's probably through some workarounds that you may have put into place, on your own. With Custom Domain publishing, the BlogSpot URL used to setup the blog is automatically redirected to the Custom Domain URL. You'll need to publish the blog to BlogSpot, to ensure a BlogSpot URL is in place first.
• If you're hosting a domain on an external server, you're probably hosting photos there too. You may want to plan to migrate the photos, and host them on Google servers, unless you want to keep maintaining the FTP server with the existing photos. Unfortunately, migrating the photos will involve manual effort.
• If you're hosting a domain on an external server, you will need to ensure that the registrar for the domain provides DNS servers that support CNAME referral. If not, you'll want to find another registrar, or buy another domain.
• If you're hosting a web site on an external server, when you move to hosting the web site (blog) on a custom domain, the structure of the blog, and some URLs, may change. If the blog is part of a web site, you'll want to update the web site, to reflect the change.
• With an FTP published blog, you have folder and file control. You may have files, installed in the root of the blog, that enable automated processes, such as search engine spiders, to index the blog. You'll have to use meta tag records for similar functions, when your blog is published back to Blogger.
• When the blog is published back to Blogger, the URLs of some files will likely change, to include publishing month, and title hash, uniformly. If you have any external or internal references to individual posts (and most blogs do), be aware of this change. Plan to use a missing files host, to reduce the impact of this issue.

With all of that said, let's plan the actual move.

1. Carefully consider the relative advantages and disadvantages of FTP and Custom Domain publishing.
2. Go through the issues list above, and consider each as it applies to your blog.
3. If the move from FTP to custom domain involves a change in URL, let your readers know in advance.
4. Publish the blog back to a BlogSpot URL.
5. Update the DNS records to reflect the custom domain setup.
6. Publish the blog to the custom domain.

We can actually describe steps 5 and 6 in combination, as setup a custom domain. You'll have 2 alternatives, here.

• If you can use the existing domain, just update or add a "CNAME" referral for the blog, redirecting it to "ghs.google.com". Here, you'll use the "Advanced Settings" wizard.
• If you need a new domain for the blog, use "Buy A Domain", and you're done.

Either way, this task has been tried and tested by hundreds of bloggers before you, if you start from a BlogSpot published blog.

>> Top

More Granular Security For Your Blog

I've been writing about Private blogs, and the ability to limit even the readership of the blog, for some time.

What if you want to have some posts accessible by a few people, and others by everybody? Or maybe you would like some of your administrators to have the ability to edit only a portion of your blog.

A content management system might provide security settings on a post by post basis, but Blogger is a blogging platform.

With Blogger blogs, you can set security only on a blog by blog basis.

The ability to set security on a post by post basis was one of the many issues discussed in the Appspot forum, in early 2009. It did not receive a large amount of votes.

But nobody said that you have to have everything in one blog. Having different security levels for different blog sections is similar to having different template objects for different blog posts.

Setup a second blog, as like the current one as you wish - but with different security settings, or maybe as a private blog. Then combine the two blogs for your readers.

To your readers, you'll have 1 blog. To you, you can have many blogs. And your blog members will have only the access that you want each one to have.

Exchanging One Custom Domain For Another

Custom domains, which give us the ability to publish a blog, hosted on a Google server (and using a Layouts template), to a non-BlogSpot URL, are great.

If we don't plan what we're doing, though, sometimes we wind up with a URL that we later decide, just won't suit our long term needs.

Like used underwear, you can't return a used custom domain name. You buy it, you're stuck with it.

Buy another domain, and move on.

1. Publish the blog back to its original BlogSpot URL.
2. If you have properly setup DNS addresses for your new domain, use "Advanced Settings", and setup the new domain inside Google. If not, buy a new domain, using the "Buy A Domain" wizard.
3. If you run into the old "Another blog ..." error, recycle the domain settings using Google Apps.
4. Done.

Easy enough, if you think about what you're doing.

>> Top

Different Template Objects For Different Pages / Posts

Some bloggers like something different, and want to expand the concept of the template.

Occasionally, we see the query

I want to have different pictures in the header, for different posts.

or

How can I have a linklist in my sidebar for some posts, but not for others?

and the immediate answer is

You can't. With a template, everything is the same.

One blog = many pages / posts = one template.

Even though you can have only one template in a blog, nobody said that you have to have just one blog.

You can have as many different blogs as you have different needs. Setup a second blog, give it a different header picture, as you like. Or put a different linklist in one blog. Likewise a third blog, and so on.

If you have any controversial pictures, likewise display them in a second blog. You can have all of the links that you want from your main blog. The second blog may get an "Objectionable Content" interstitial, but the first blog, which contains all of the content to attract the search engines and your readers, can be indexed and viewed freely.

Some people are multi-lingual, and plan to publish identical content, translated into two, three, or more languages. One way to do this is to add a Language Translator gadget to your blog. Another way is to have multiple blogs, each blog published in the desired language, combined with each other using "hreflang".

Sometimes, the proper language setting makes a difference in the way the blog contents are displayed - and can make a blog easier to read for your various readers.

Then, simply combine the different blogs using blog feeds, custom domains, IFrames, links / linklists, and / or template cloning. The limit here is merely your imagination.

To the readers, you'll have 1 blog. To you, you can have many blogs. And your blogs can all have different templates, as pleases you.

Custom Domain Publishing, And A New 404 Error

Some time ago, I wrote about blogs, newly setup for custom domain publishing, undergoing a transition period, where both the Blog*Spot and Custom Domain URLs are active, but seemingly 2 separate web sites. This appears to be a (almost exactly) 72 hours while Google allows time for DNS propogation of the new URL to take effect, worldwide.

Now, it appears that some blogs, having gone through the transition period, are still not active.

Here's one case, "keith-in-training.com".

keith-in-training.com. 3600 IN A 64.233.179.121
keith-in-training.com. 3600 IN A 66.249.81.121
keith-in-training.com. 3600 IN A 72.14.207.121
www.keith-in-training.com. 3600 IN CNAME ghs.google.com.

Appears to be a normal, asymmetrical DNS setup made using either "Buy A Domain" or maybe Google Apps.

5/31/2008 19:52:36 Trying http://keith-in-training.blogspot.com
Redirect!
Header:
HTTP/1.0 301 Moved Permanently
Location: http://www.keith-in-training.com/
Content-Type: text/html; charset=UTF-8

The Blog*Spot URL redirected, by "301 Moved Permanently", to the custom domain "www" alias.

So far, so good.

But wait - there's more!!


No!! The whole URL is down, now.


One step forward, another back. But remember, this is a known symptom. If you are seeing the above display (but only the above display):

1. Publish the blog back to it's previous Blog*Spot URL, then republish to the custom domain URL.
2. If you get the old "Another blog ..." error, recycle your Google Apps settings.
3. Please, leave a comment here with your Blog*Spot and custom domain URLs, and whether or not the above procedure was successful.

>> Top

Custom Domain Publishing, And The 404 Error - Chronic Edition #2

A couple of weeks ago, I published Custom Domain Publishing, And The 404 Error - Chronic Edition. Since that time, I was able to contact Blogger Support more directly than through this blog, and I was able to pass on to them a few egregious cases which included the symptoms described in that post. Several of those cases, they were able to ultimately fix.

Many people were happy. Kudos, Blogger.

Until today that is; when 2 people, who were earlier using their blogs quite happily, reported to me, within the span of 1 hour, that their blogs were, now, displaying

Server Not Found
Error 404

Note, please, that the error, previously reported, was not identical.

Not Found
Error 404

Not Again!!



What does this mean? Only Blogger Support can say for sure.

If your custom domain published blog is now showing this new symptom, please let us know. Comments will be posted below.

Problem Log

Date	Domain	Remarks
5/14	deliverancegothic.com	-
	mycup2yours.com
5/15	fragrancediva.net
	greateststorytold.com
5/19	robjessica.com
5/23	lloydclaycomb.com
	yangor.com
5/29	shriramamgroup.info
	jetaaqld.org
	gabrielcusac.com

>> Top