Blogger Blogs Redirecting To "blogspot - ping . com"

Today, we see the latest in the never ending saga of blog owners, who previously (maybe / maybe not recently) installed some deviously created software - whether intentionally or not - and who now find their readers unable to view their blogs, and themselves even unable to access the template editor to remove the malicious code.

My blogs are redirecting auto to ping . blogspot - ping . com", can anybody tell me how to fix this?

The malicious redirecting appears to be cause by a small snippet of JavaScript code - which has been installed, in most cases, as template HTML. Alternatively, some blog owners have added separate HTML / JavaScript gadgets, to host this code.

It's easy enough to identify - not so easy to remove, as some owners have found. In many cases, we are seeing reports that even when directly accessing the Layout wizard or Template Editor, the malicious code activates, and redirects the blog owner's browser.

Since the redirect is running from a snippet of JavaScript code, blocking the malicious code will prevent the redirection, and allow corrective access to the Layout wizard or Template Editor.

<script src='http : // ping . blogspot - ping . com / ping . js' type='text/javascript'></script>

Whichever GUI wizard you use to remove the code, remember to clear cache and restart the browser after removal and before testing for success.

Since I routinely - and consistently - use Firefox with NoScript to browse, I was able to access one victim blog without the redirection occurring, view the blog source, and extract the above code. If you use NoScript, you (the blog owner) should be likewise able to access your dashboard, and the Template Editor, and remove the bogie.

Please note that the code snippet, excerpted above, has extra spaces inserted into the URLs, to prevent advertising of the actual hijacking domain.

Anybody who knows where this bogie originated, and how it was deviously conned upon the blog owners, can help a lot of people by identifying the origin. Only when this is done, can we try to prevent the problem - rather than advise how to remove the problem.

First, install the popular Mozilla browser, Firefox. Having added Firefox, install the add-on NoScript. NoScript uses a Unix level security policy.

Deny by default, permit by exception.

Keep in mind the different trust levels of Blogger and BlogSpot - with NoScript, you will have to allow Blogger, yet forbid BlogSpot. Code from unknown domains, such as "blogspot - ping . com", will not run on any NoScript protected computer - unless you, intentionally, enable it. Knowing the threat from this bogie, you will hopefully choose to not enable this domain.

>> Top

No Immediate Solution For 1And1 Customers With Unverifiable Custom Domains

Since Blogger restored Custom Domain Publishing last month, with the new domain ownership verification requirement, there have been a few complaints from customers of some registrars who just can't provide the required DNS address record for ownership verification.

My registrar says that I can't have two "CNAME" records in the same subdomain.

and

My registrar's domain manager wizard displays an error saying "Address too long.", when I try to add the "CNAME".

Blog owners contacting the registrar, and asking for help, are generally told

That's Blogger's problem!

---

(Update 2012/11): Blogger Engineering has provided a workaround for this problem, with any uncooperative registrar, such as 1And1 - use of a (free) third party DNS host.

---

What not all blog owners realise is that the new "CNAME" must be just that - there is no substitute here.

Some of the more patient blog owners have made various suggestions, to get us moving towards a solution.

1. Blogger Support needs to work with the problem registrars, and convince them to improve their service.
2. Blogger Support needs to provide an alternate ownership verification procedure - maybe equivalent to the Google Webmaster Tools meta tag verification procedure.
3. Blogger Support needs to clean up their "CNAME" setup instructions, and remove mention of the problem registrars - so future blog owners won't choose these registrars to host their domains.

About 3/4 of the problem reports have come from customers of 1And1. Using that registrar as a starting point, I contacted Blogger Support and suggested the 3 alternatives, outlined above. The Blogger Engineer responding seemed to think that only suggestion #3 - cleanup of the per registrar "CNAME" addition instructions was immediately possible.

It's possible, then, that we will eventually see less problem reports from 1And1 customers - and hopefully others - as Blogger Engineering cleans up their domain setup instructions. The current customers of uncooperative registrars, unfortunately, are unlikely to see relief, for the near future.

This is an unfortunate situation for these 1And1 customers. The best solution for them is to move domain registration to another, more helpful, registrar. Unfortunately, most registrars don't allow domain registration transfers immediately after initial purchase - waiting periods of 30, or even 60 - days are normal. And domain registration fees are not refunded.

This leaves new 1And1 customers, and similar victims, with several options - none of them good. First, publish the blog back to BlogSpot, so the blog can be accessed by existing readers.

• Wait 30 - 60 days, with the domain dead, then transfer domain registration to a more helpful registrar and activate.
• Purchase a second domain, from a more helpful registrar.
• Forget about custom domain publishing.

The latter alternative has motivated several victims to choose a fourth alternative.

• Move their blog hosting to a different service.

None of this can be good for Blogger's reputation.

>> Top

Schizophrenia And Custom Domain URLs - October 2012

Now that the custom domain publishing feature is back online again, there remains one feature of custom domain publishing to be restored to the Blogger dashboard.

The very popular Blogger dashboard option to redirect the domain root (aka "naked domain"), to the "www" alias, may not be reliable - or even available.

Too many people report

I can't redirect the naked domain - I can select the option, but the next time I look, the box will be un checked.

and

My "www" alias works just fine - but the domain root now returns a "404".

Fortunately, there are alternative solutions to provide the naked domain redirect.

There are 3 ways to redirect the domain root to the primary ("www" - or any alternate selection) alias.

• Registrar Domain Manager forwarding.
• Blogger Publishing redirect.
• Google Apps "Domain settings" redirect.

Registrar Domain Manager

The Registrar Domain Manager provides, for some blog owners, the currently most obvious alternative to the Blogger Publishing redirect - but it is not the simplest to use. Depending upon the registrar, and the nature of the domain manager / DNS servers, this procedure may not even work.

Some registrars will recommend simple DNS or frame forwarding to the BlogSpot URL - and this "solution", we know from experience, will not work at all. One problem here will be spurious spam classification, caused by what looks like an offsite redirect of the domain root.

Blogger Publishing

The Blogger Publishing redirect option is the most obvious alternative. This is the preferred option, in custom domain publishing - and re publishing - procedures.

Google Apps "Domain settings"

A less obvious option, the Google Apps "Domain settings" redirect option, is a third solution.

For any newly purchased domain - as well as for domains purchased directly from a registrar, it's possible (though currently, with some effort) to setup a Google Apps domain administrator account. Next, use the "Change how your naked domain is redirected" screen, and change or recycle the domain root redirect.

Which ever alternative you chose - or made to work, the domain root should now redirect to the alias of your choice.

Blogger Blogs Lack The Navbar, Though Not Removed By The Owner

Recently, a few Blogger blog owners are looking at their blogs and wondering

Where is my Navbar?

or

Why don't I have a "Sign In" ("Sign Out") link, at the top of the page?

When investigating further, they may discover that none of the blogs, that they view, shows the Navbar. And, they did not intentionally make any template changes, to their blog, to hide the navbar.

Many of these people, later investigating the problem in Blogger Help, learn that their browser, or another anti malware product, is blocking the navbar as suspicious code. This is another example of improperly configured layered security, planned to protect our computers.

If you are observing the lack of the navbar on your computer, and you request help in Blogger Help, please help us to help you better, and provide details.

• What browser (name and version - and precision matters) are you using?
• What add-ons are installed, in the browser (completeness matters)?
• What anti malware product(s) do you use, on your computer (again, completeness matters)?

If we can get an idea of what components are involved in this problem, maybe we can isolate the problem, itself. Please, be complete - and be precise.

>> Top

Custom Domain Purchase - Getting By Without "Buy a domain"

Now that custom domain publishing is once again available, though without the option to buy a domain through Blogger, too many anxious Blogger blog owners are asking the obvious question

How do I buy a domain?

Not a lot of blog owners want to be told

Contact the registrar of your choice.

The backup to "Buy a domain" would be to buy a domain directly from a registrar - however, this presents too many challenges to the casual blog owner.

---

(Update 2012/10/09): "Buy a domain for your blog" is once again part of the Publishing wizard.

---

Fortunately, there is a substitute to "Buy a domain", available through Google. Google Apps - which is the support organisation for "Buy a domain" itself - provides the option to buy a domain, along with the Google Apps Dashboard. Google Apps does not use easy to remember URLs, unfortunately.

To use the Google Apps equivalent of "Buy a domain", you start from the "Home Page" for Google Apps.

http://google.com/a/domain

This currently redirects to

https://www.google.com/a/cpanel/standard/new3

which is titled

Get started with Google Apps for free

From here, you find the all important advice

Don't have a domain yet?
No Problem. You can register a new domain starting from $8 a year.

accompanied by the button "Find domain".

Hitting the "Find domain" button, you get a display that's similar in functionality to "Buy a domain" - except the pulldown list of available Top Level Domains is currently a bit different from the selections offered by "Buy a domain".

To get a better selection of Top Level Domains, you'll have to go to

https://www.google.com/a/signup/?hl=en&source=gafb-globalnav-en

Here you will have to fill out the "You and your business" form, and hit "Next". The next display will start with "Check Availability" - and will provide a much longer TLD selection list.

>> Top

Ownership Verification Is Not A Standard Process

With the recently restored custom domain publishing feature, and the new domain ownership verification requirement, comes various queries from blog owners unable to verify domain ownership, and to publish their blog to their custom domain.

Can I use a "TXT" file, instead of a "CNAME"? My registrar suggests this as an alternative.

and

Why do I need this? My domain was working, just fine, before I had to re publish the blog!

Not all blog owners understand the historical need for verifying domain ownership.

---

(Update 2013/09): The second "CNAME" won't be required, in all cases. If you don't see instructions for adding a second "CNAME", focus your efforts on getting the domain working, with righteous base DNS addresses,

---

Ownership verification, allowing one to setup a given relationship between various Internet resources, varies according to the need of the application which uses the Internet resources in question.

Domain ownership verification, to provide urgently needed custom domain security, is simply one example of ownership verification, in general.

• If you have file / folder control of a web site, you may be able to add a specific named file, to the website. The application in question can check for the presence of the required file (possibly one with a complex name).
• Some applications such as Webmaster Tools can, alternatively, use a meta tag in the blog header, to verify blog ownership. Again, the tag will have a complex name / value.
• To verify domain ownership, Blogger requires you to install a unique "CNAME" as a DNS address into your domain. The "CNAME" will contain two complex values, provided only to the blog / domain owner.

In either case, the complex values provide an encrypted certificate, which is specific to the application and to the blog / website, which is provided only to the owner of the blog / domain / website.

The named file is a simple solution - both to setup and to verify - but using it requires that the blog / website owner have the ability to setup a specific named file, in a specific folder, containing the certificate. Blogger does not provide file / folder control, so that solution is out - for any application which is to be used with Blogger blogs.

Applications (such as Webmaster Tools) which work with Blogger blogs, and similar websites, can use meta tag verification. This requires that the blog owner add a meta tag in the blog header, with a complex tag name / value. The tag name / value contains the certificate in question.

Blogger blogs can use neither a named file, nor meta tags, for domain ownership verification. There is no domain header, where meta tags could be installed - and again, Blogger does not provide file / folder control.

To verify domain ownership, Blogger requires the domain ownership certificate to be installed as a unique "CNAME" DNS address. The complex values in the "Name" and "Destination" values of the "CNAME" contain the encrypted ownership certificate. Since the specific certificate values, for each different domain, are provided to the blog owner (in the "settings instructions" document) - and the "CNAME" can only be installed by the domain owner - when the proper "CNAME" exists, the blog owner and domain owner are certified to be one person.

The unfortunate problem with "CNAME" based domain ownership verification is that not all registrars can provide the required "CNAME"s, and can provide "CNAME"s with long "Name" or "Destination" values. This does not mean that the Blogger solution, for domain ownership verification, is faulty.

It's possible that Blogger Engineering has considered a second option for domain ownership verification, which will be added when - or after - the "Buy a domain" wizard is updated to support automatic domain ownership verification. It's also possible that blog owners, who use specific registrars which are unable to provide the required "CNAME", will be forced to abandon their current registrar.

Whatever the case, it's likely that the "CNAME" based domain ownership certificate was the best possible solution, to solve the urgent security problem, and allow custom domain publishing to be restored last week.

Blog Owners Seeing bX-afpmyd When Trying To Un Delete Custom Domain Published Blogs

We're seeing a few reports this week, from blog owners who recently deleted their custom domain published blogs - who now lament their decision - and who are unable to un delete the blogs.

I can't "undelete" my blog, that used to be published as a custom domain URL. I received the following error code: bX-afpmyd.

This problem, like others, appears to have started when custom domain publishing was restored, last week.

Blogs deleted when a custom domain URL is in use have always been a challenge. Similar to the abandoned custom domains problem, they have resulted in yet another cause for the well known custom domain problem

Another blog ....

Now that Blogger is requiring verification of domain ownership, by adding ownership certification using a new "CNAME", it's likely that either lack of the new "CNAME", or broken blog / domain pointers, are going to be a problem when un deleting blogs formerly published to custom domains.

If you are unable to un delete your previously deleted custom domain published blog - and you are otherwise able to restore the blog in question - you, like other blog owners trying to make changes to their custom domain published blog, will need to use the Publishing wizard, and the "settings instructions", and add a unique domain ownership certificate to your non BlogSpot domain. Then, if able to un delete the blog, you'll need to re publish the blog to the domain.

>> Top