The Real Blogger Status

Some blog owners are confused about how domain ownership verification works - or should work. The domain ownership verification process involves two challenges. Both accessing the registrars zone editor, and parsing the displayed content, is a challenge - for anybody but the domain owner. Or sometimes, including the domain owner. Blogger uses an intriguing technique, to verify that the blog owner, submitting a blog for domain publishing, is also the domain owner. They give the blog owner a token to add, to the domain - then verify that the token was added, before publishing the blog to the domain.

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.

Some blog owners, publishing their blog to a custom domain, wonder about the mysterious TTL setting for the domain. What is "3600"? Why do I see "7200" in my Dig log? and Why do I have to wait 8 hours, after changing my DNS addresses? DNS latency (aka "TTL") is not understood, by many blog owners. A mistake in setting TTL can cause anger and frustration.

People who speak (read / write) languages, that do not use Roman character sets, need to publish in their native language - and the Internet now supports that need . Some registrars will register domains which use non Roman character sets, in the URL. Not all Internet services will accept non Roman characters, however. My favourite online DNS diagnostic services, DigWebInterface , and intoDNS , and Rex Swain's HTTP Viewer , only use ASCII. One cannot use non ASCII ("non Roman") characters, with either service.

One of the features of custom domains, when purchased using " Buy a domain ", was the Transition period. Transition was Blogger, allowing that even with Blogger / Google controlling the domain authoritative servers (which they did, indirectly, by using eNom / GoDaddy as the registrars), and the initial DNS address setup (offered for GoDaddy purchased domains ), the stability of custom domains only starts with the domain authoritative servers, and the Root Name servers . Custom domain published blogs, to be consistently stable, can only rely on the DNS addresses being available on the local DNS servers, on a worldwide basis, 48 to 72 hours after the DNS addresses are added. This built in latency period has nothing to do with how custom domains are designed - and it's an issue over which Blogger and Google have no control.

We're seeing an increasing number of problem reports, mentioning Google Domains. Google Domains is becoming a popular registrar for new custom domains - and this leads to more problems, reported in Blogger Help Forum: Get Help with an Issue . Many reports look like timing problems, from long ago . The most common symptom is the mysterious Redirect Warning. I purchased a Google Domains site, and connected it to Blogger so it redirects my blog to my domain, no problem. The problem is now when accessing the BlogSpot URL, it now shows a redirect warning message, which is killing my web traffic. This blog is not hosted by Blogger and has not been checked for spam, viruses and other forms of malware. How do I publish my blog, and keep my readers, with this confusion?

This month, we're seeing an interesting collection of problem reports, in Blogger Help Forum: Get Help with an Issue , about custom domain setup. Why is my blog offline - occasionally? And Why do some (just some!) of my readers tell me they can't see my blog? Investigating the problem, we see that the domain is, indeed online - some of the time. Investigating the DNS addressing, robustly, we find an all too frequently seen set of name servers: mydomain.com. 14400 IN A 216.239.32.21 www.mydomain.com. 14400 IN CNAME ghs.google.com. What we see here is a domain, setup by someone who thought that one server would be 'good enough' to get by .

I've been using affinity analysis , and differential analysis , as tools for diagnosing intermittent problems with custom domain published blogs , for several years. Some people may be using a browser which is more forgiving of DNS problems than others - and people who use the right browser, when accessing a domain with righteous DNS addresses , should expect to generally get more consistent service. But that's only a small part of the story.

We've known about the Transition period , which has applied to domains purchased through Blogger , for a few years. Under Transition, domains purchased using "Buy a Domain" were only partially published, immediately after the domain purchase - with the publishing process completed, several days later. The Transition period allowed for the domain, newly setup by "Buy a Domain", to become fully visible on the Internet , before blogs subject to Transition were re published.

About a year after Blogger introduced custom domain publishing , they segmented the custom domain publishing process. In order to avoid database corruption, which was a frequent cause of the "Another blog ..." problem , they introduced a delay period, which we call "Transition" . Transition lets them delay key blog updates - until the world wide DNS infrastructure has a chance to reliably update with information about any new Google custom domains. In the beginning, Transition lasted almost exactly 72 hours, and delayed creation of the "301 Moved Permanently" redirect from the BlogSpot to domain URL. Later, when Following became a fixture on most blogs, we observed that the Followers gadget was also being updated on a Transition based delay.

Not all blog owners, who publish blogs outside the BlogSpot address space, have any feeling for the complexity of the DNS infrastructure . We see the questions periodically in Blogger Help Forum: Something Is Broken . My readers are still reporting seeing the well known problem 404 Server not found or I added the "CNAME" for my domain, and I'm still seeing another old friend (not) Another blog is already hosted at this address. when I try to publish the blog to the domain. or I added "blog.mydomain.com" to my domain, and published to it with no problem, but some readers are seeing 404 Server not found Why some - but not all?

As I wrote earlier , when I'm diagnosing a problem with a custom domain - and occasionally, with other blog and network problems - my most frequently used tool is a Kloth online Dig . With Dig being an important diagnostic procedure, it's a good idea to have more than one Dig utility available. The Kloth server may be down. The Kloth server may not offer the right options. It's good practice to occasionally (and sometimes, intentionally) cross check results against another server. For many Dig investigations, I like to use a second online Dig service - WhoIs, provided by All-NetTools . The All-NetTools WhoIs Dig actually provides more than a standard Dig. A WhoIs Dig, for a domain, provides much valuable information about the domain / registrar relationship. Here, for instance, we can see an All-NetTools WhoIs Dig for this domain, nitecruzr.net . http://www.who.is/whois/nitecruzr.net/ REGISTRY WHOIS FOR NITECRUZR.NET Domain Name: nitecruzr.net Registrar: GODADD...

Sometimes when we work on a custom domain problem, we'll recommend specific DNS changes, and we'll make plans to deal with the unavoidable DNS latency issues . Make the above changes, and wait for one full day, before continuing. The above caveat will be highly advisable, because of gross latency required by the DNS host (1 day TTL is pretty nasty). mydomain.com. 86400 IN A 74.53.137.215 As always, we'll be using a Dig utility to examine the DNS settings in question . The DNS settings, as noted, may not be visible immediately. If the existing DNS address record for "mydomain.com" includes a TTL of 86,400 seconds (1 day), then we should wait for one day, before assuming that any changes that we are making will take effect. Maybe we don't want to wait one full day, just to see if the blogger working on the problem (or worse, the DNS host support tech paid by the blogger for service) makes the right settings. Fortunately, we don't have to wait until TTL ex...

I read this frequently in the Blogger Help Group forums All that I read about redirecting the custom domain seems backwards - from my BlogSpot address to a personal URL. That's too complicated, I can't do that! Is it possible to just redirect traffic from my personal URL to Blogspot? and some helpers come back with Yeah, it's so much simpler. Why should you do it any differently? and they are right, it is far simpler to just redirect the custom domain URL to the BlogSpot URL. But it won't get you the same results. A standard custom domain is comparatively complex. Setup an "A" / "CNAME" referral , from the domain to Google. Publish the blog to the domain URL . Setup a "301 Moved Permanently" redirect, from the BlogSpot URL to the domain URL. Re publish the blog to the domain URL. Setup a Google redirect, from the Google server to the blog, published to the domain. Look how simple it is to just redirect the domain URL to the B...

Every week, at least one BHG forum thread, in which I provide advice about a custom domain setup, includes the question Why are custom domains so complicated? And the short answer is They are not at all complicated; they are elegantly simple - when you understand their simplicity, and follow the instructions . The long answer, which justifies the simplicity, is not so simple.

Many problems which are reported by bloggers have simple resolution procedures. Clear cache in the browser, and restart the browser. Some problems are slightly more complex. Clear both cache and cookies, and restart the browser. and, at the center of each procedure, we see Clear cache. Cache, or local storage of Internet content , is at the center of many problems with blogs and web sites. If a copy of your blog is in a cache somewhere, the computers that access the cached copy will continue to display that copy, until told to get a fresh copy. If you just updated your blog, folks accessing the cached copy won't see your changes. One way to ensure that you see fresh copies of everything is to clear cache, which forces fresh retrieval of everything. For all of its simplicity, clearing cache isn't a universal solution, and neither is it consistently productive - even for problems which are generally known to respond to clearing of cache.

One of the least understood details about Google Custom Domains is the need to wait, when setting up, or when making changes to, the DNS addressing for the domain. This is important, before publishing the blog within Blogger, or telling our readers about our new non-BlogSpot blog. Daily, we see anxious queries I just used the " Buy a Domain For My Blog " wizard, and paid for my domain with my credit card. The credit card company confirmed the charge. But I see that it's " In Transition"?? or You told me how to fix my DNS problem, and I did just what you told me. But I don't see my changes when I Dig the addresses for my domain. I know that I made the changes! What is going on here? Why do I have to wait, unpredictably?

Custom domains, to the typical blogger, should be incredibly simple to setup. Functionally, the setup process is two simple steps . Create a DNS entry for the URL of your choice, pointing to Google. Publish the blog to the URL. But for all of that simplicity, they are seemingly random in their failures. Why are custom domains so apparently randomly unreliable ? One example, where we can see random behaviour, is in surgical DNS changes. One of the recent causes of the flood of Another blog is already hosted at this address. and Server Not Found Error 404 is a reference to a DNS server that isn't in service any more . Many bloggers, lately, complain of the "Server Not Found Error 404" symptom. I'll look at an HTTP Access Log for the domain, and see Host IP address = 66.249.81.121 followed by <h1>Server·Not·Found</h1>(LF) <h2>Error·404< /h2>(LF) Next, I look at an excerpted Dig log for the domain, and see mydomain.com. 3600 IN A...

Blogger has thousands of computers that they control and support - their servers. They have millions of computers that they don't control, but still try to support - our computers. Then there are the remote servers, to where we (try to) publish blogs using FTP . They don't own, or support those computers, and that relationship creates a lot of challenges when we want to publish our Blogger blogs to those non-Google computers.