Social Icons

Pages

Showing posts with label Registrar. Show all posts
Showing posts with label Registrar. Show all posts

Saturday, 18 May 2013

Confusion About Referer Spam Can Have Unexpected Consequences

As referer spam continues to be reported in Blogger Help Forum: Something Is Broken, we see occasional signs of confusion.

Some blog owners, knowing how to use WhoIs lookups and similar online utilities, to their advantage, are looking up the referer spam targets - and are reporting the targets to their registrars and hosts. What these blog owners may not realise is that not all apparent "customers" of referer spam "services" may have actually contracted to be featured in the services.

In October - November 2011, this blog was featured in one wave of referer spam.

Somewhere, buried deep in my comment moderation queue for this blog, may be some odd comments
Chuck, I clicked on a link in my Stats log, and got this blog. Your blog does not link to my blog - so why do my Stats displays link here?

When I saw one such comment, I thought that it was just some spammer, messing with me - as many do (which is why I moderate comments, aggressively). As more such remarks appeared, both here and in Blogger Help Forum, I realised that what I had idly expected, long ago, had actually come to pass.

I've been using this blog, since I started it, as a weapon against spamming activity in general. In February 2011, I started using it as a weapon against referer spam. I did both knowing well that if I was ever seriously effective in my fight, the guys who I became effective against would eventually attack me.

In October 2011, I realised that my dream had become true. I was honoured by the providers of referer spam, as someone worthy of their attention. In spam fighter parlance, I was the victim of a "Joe Job".

Just as surely as I, personally, was a Joe Job victim, I know that other honest and righteous blog and website owners are similarly being attacked by referer spam, in other Joe Jobs. I know that I am not the only fighter of spam, worthy of the attention of the spammers.

Once we understand that not all blogs or websites featured in referer spam activity may be actual intentional customers of referer spammers, we have to realise that unfocused reporting of blogs and websites, mentioned in referer spam, will actually play right into the hands of the referer spammers.

What the referer spammers are doing, in their Joe Jobs, is also called a "Smurf Attack". The spammers are hoping that thousands of angry Blogger blog owners will report the blogs and websites, featured in the spam, as spam customers. This will cause the immediate recipients of the Smurfing, the registrars and Internet Service Providers, to discontinue service to the reported blogs and websites. In 2011, with such reporting taken seriously, this blog might have been damaged.

Hopefully, most ISPs and registrars know of Joe Jobs and Smurf Attacks - and know how to verify the nature of any individual service being reported for spamming. However, that's simply a complication which can have other effects.

The bottom line is that anybody seeing the referer spam, in their Stats logs, has to understand that not all blogs and websites should be reported for spamming. When you report all referer spam, indiscriminately, you are simply working for the spammers.

Please, don't work for the spammers. The existence of this blog (and other, much more significant blogs and websites) may depend upon your discretion.

>> Top

Wednesday, 1 May 2013

Renewing Your Custom Domain Registration

Some Blogger blog owners, having experienced the anxiety of custom domain setup, intend to carefully maintain their domain registration.

We see a few queries, in Blogger Help Forum: How Do I?, about domain registration renewal.
How do I make sure my registration gets renewed?
or
How do I renew registration before it expires?
or, possibly
My blog now displays a search page! Have I been hacked?

Some registration issues will depend upon how the domain registration was originally purchased.

Domains purchased directly from a registrar - whether using eNom, GoDaddy, or a third party registrar, will have to be renewed directly from the registrar. It's not possible to migrate a direct purchase to Blogger / Google registration for payment, any more than to use the Blogger / Google automatic DNS setup. Once you purchase domain registration from a registrar, you are on your own.

If you used Blogger "Buy a domain", Google Apps, or Google Wallet, to purchase the domain registration, you should get email reminders when registration is expiring. However, this will depend upon whether your Blogger / Google account, under which you purchased the registration, uses an active and accessible email address.

If you choose to anonymise yourself by using a bogus or inactive email address for your Blogger or Google activities, don't expect to get email reminding you, or allowing you to renew domain registration.

The most reliable way to assure the domain remains registered is to use domain auto renewal. You can check your auto renewal settings using the Google Apps administrator account, for the domain (now called the "Admin Console").

For domains purchased before December 2012, you'll use email from Google Apps, or an entry in your Google Wallet log, to retrieve the token to setup your Google Apps account. For domains purchased after November 2012, you will have only a limited access Google Apps account, which you should reset the password, to access.

If you intend to use domain auto renewal, make sure that the bank account (credit, or debit) is active, and currently paid. If your bank rejects the payment, you should get a notice - but again, this will come reliably when the email account associated with the domain is active and accessible by you.

If you do not renew registration on time, depending upon the registrar, the domain may be changed to point to a domain parking server, where the registrar will serve ads. Some registrars will serve ads which you, or your readers, won't appreciate.

If the domain registration has expired, and the domain was purchased from Blogger / Google, you may be able to submit late payment, and renew now.
If your original charge fails and you’re unable to resolve the form of payment issue within 7 days, you may still be within the grace period for renewals. If you’re still within 19 days of the renewal date, you can try again using any Google Wallet account by visiting http://www.google.com/a/cpanel/domain/renew-domain/primary-domain-name, where primary-domain-name is the domain name you are trying to renew.

In some cases, once late payment has been processed, your registration may resume, with no long lasting ill effects. In other cases, you may end up having to setup the DNS addresses.

The best renewal experiences, of course, start with advance planning.

>> Top

Friday, 12 April 2013

Using "Buy a domain", From Outside The USA

As custom domain publishing becomes more popular with Blogger blog owners, it's inevitable that people outside the USA would start using it, routinely.

Questions about payment options are seen regularly, in Blogger Help Forum: How Do I?.
How much does a domain cost?
This used to have a simple answer.
$10 US, charged against a major bank issued credit card.

With the internationalisation of Blogger, the answer becomes significantly more complex.

Using Google Wallet, one may purchase a domain in over 230 countries.
The Google billing system accepts payments in over 230 countries with an international credit card.

We now see mention of specific payment methods which are not accepted - though they appear to be important enough to be documented by Google.
  • Health Savings Account (HSA) cards.
  • Transit cards.
  • Western Union/Money Gram.
  • Any escrow type of payment.

From what I have observed, using a bank issued credit card involves pretty complex "peer to peer" type transactions, between at least 3 parties.
  1. Google.
  2. The bank providing the credit account for the blog owner.
  3. The bank providing the payment account for the registrar.

Item #2 provides intriguing options.
  • American Express (USD Only).
  • Discover (USD Only).
  • MasterCard.
  • Visa.
  • Visa Electron (Outside of US Only).
I have no idea what #3 may involve, internationally. I know that accepting payments, even within the USA, is not as simple as making purchases.

If these options do not satisfy you, personally, you are entitled to purchase a domain from almost any registrar which provides an acceptable payment method. However, you will need to accept some responsibility for the technical details involved, in setting up the domain.

The complexities of International Banking will make "simple" purchases such as non BlogSpot URLs, for Blogger blogs, interesting to watch.

>> Top

Friday, 5 April 2013

Adding Ownership Verification For Your Custom Domain? Examine The Error Display

Sometimes, you have to step outside the box, to complete a Blogger blog task.

The task of adding domain ownership verification, to a custom domain purchased using "Buy a domain", is one example of stepping outside the box. I advise people that tweaking DNS settings, in general, is a task best undertaken by someone with "Advanced" experience with Blogger custom domain publishing.

Unfortunately, domains purchased using "Buy a domain" are occasionally subject to incomplete setup - and correction of an incomplete setup involves republishing the domain. And republishing the domain requires verification of domain ownership.

To a first time domain owner, the task of verifying domain ownership is surely a bit scary.
We have not been able to verify your authority to this domain.

This initial accusation is followed by the instructions
On your domain registrar's website, locate your Domain Name System (DNS) settings and enter the following two CNAMEs:

The challenge, for many, is getting to the Domain Name System (DNS) settings, aka the Zone Editor.
  1. Login to Google Apps.
  2. Find the instructions for logging in to the registrar's website.
  3. Login to the registrar's website.
  4. Find the registrar's Zone Editor wizard.

Having completed Steps #1 - #4, adding the "CNAME" is almost an anticlimax. See the instructions?


On your domain registrar's website, locate your Domain Name System (DNS) settings and enter the following two CNAMEs:

Name, Label, or Host field Destination, Target, or Points To field

www ghs.google.com

i7vgls457wxc gv-fbz2zptam3ucji.dv.googlehosted.com

Once you have access to the Zone Editor, look for "www", added by "Buy a domain". See how it's formatted, in the display?
  • Add the second "CNAME", mirroring the format and syntax of the first.
  • Note the example of the second, shown here as "i7vgls457wxc" - though when you setup your domain, you will surely see different values for both "i7vgls457wxc" and "gv-fbz2zptam3ucji.dv.googlehosted.com")
  • Refresh the Zone Editor list, and compare the "www" and "i7vgls457wxc" entries.
  • If you added the new entry properly, the format and syntax, of the two entries, will be identical.

Having successfully added your new "CNAME", go back to the Blogger Publishing wizard, and publish the blog to the domain. Finally, wait a few days for Transition to expire - and while you wait, plan what to do, next.

>> Top

Wednesday, 3 April 2013

The Task Of Forwarding A Domain Requires Experience, Persistence, And Research

I constantly advise Blogger blog owners to avoid forwarding, when setting up custom domain publishing.

In the rare cases where forwarding is actually required, not every blog owner reports success.
My blog now displays a non Google search page!
or worse
My blog now displays
404 Not Found
What did I do wrong??
Depending upon what setup work was done by the blog / domain owner, and what effort is required by the registrar, one may expect to see, quite predictably, either of the above errors.

When you just publish your blog to the primary domain, you're using the Blogger Publishing wizard.

When you forward a secondary domain to the primary domain, you're using the DNS Manager wizard provided by the registrar, for that secondary domain. Frequently, this is a 2 step process.
  1. You use the DNS Manager for the secondary domain, and designate the primary domain as the forwarding target for this domain.
  2. You setup a DNS address for the secondary domain URL, and target the redirection server - as provided by the DNS host.
Some wizards will handle both steps for you automatically, while others will require that you do both steps separately. I have had both experiences, when forwarding different domains using the GoDaddy DNS manager. You may need to experiment, here - or ask an experienced technician at the registrar, for advice.

If your registrar requires that you perform both steps separately, and you only do the first, your domain gets redirected to the redirection server. If you don't define a redirection target, you have a parked domain, similar to an expired domain - and your domain will serve the ads display page provided by the registrar.

If your registrar requires that you perform both steps separately, and you only do the second, your domain will be properly redirected from the redirection server - but the redirection server will not be defined, for your domain. If the redirection server isn't defined, the domain will be "404".

If your registrar does not provide explicit instructions - or if you use the domain manager wizard and get either of the above results, it may be time to contact a customer service representative. Using a third party registrar, or a third party DNS hosting service, you may have to improvise.

Forwarding a domain - when you must serve two domains (or more) from one blog - is simply not a task for the inexperienced.

>> Top

Tuesday, 26 March 2013

When You Setup A Custom Domain, Please Know And Observe Your Limits Of Expertise

Too many blog owners, when they setup a custom domain for their blog, do not consider the details.

We see signs of the problem, too often, in Blogger Help Forum: Something Is Broken.
Can someone give me step by step instructions for setting up a custom domain with xxxxxxx registrar? I contacted xxxxxxx customer service - and they told me a lot of things I didn't understand! Would it be easier just to transfer the domain to GoDaddy?

The short answer here would be
Yes, it would be easier just to transfer the domain to GoDaddy.
Unfortunately, that answer is not completely correct - and the correction may leave you with a broken domain.

Too many blog owners, eager to setup a non BlogSpot URL for their blog, do not consider the details involved, when they bypass "Buy a domain".

Part of the blame, for this problem, has to fall onto Blogger's head. People using "Buy a domain", for their first domain purchase, see the domain purchase as such a simple process. They never become aware of the complexities involved in a domain purchase, until they setup their second domain, and decide to "roll their own".

Let's look at the levels of experience needed.
  • Beginner: Use "Buy a domain".
  • Intermediate: Use the Google Apps or Google Wallet wizard - or alternately, buy a domain from one of the 8 identified registrars.
  • Advanced: Buy a domain, directly, from any of the thousands of registrars, worldwide.


As of 2013 June, "Buy a domain" is not offered, as part of "Add a custom domain". This will leave everybody with one option - "Advanced".
Beginner blog owners are strongly advised to use "Buy a domain". Choose an available domain, provide payment details, and your domain is setup. Wait until Transition expires, and get to work referring your readers, search engines, and other Internet services, to your new, non BlogSpot URL.

Intermediate blog owners, able to understand simple instructions, should be able to use the wizards provided by Google Apps or Google Wallet. Alternately, Blogger provides reasonably complete and simple instructions for setting up a domain with the 8 most popular registrars.

Advanced blog owners are free to choose any registrar, of the thousands out there. But beware! You are on your own, when you do this.
So choose your registrar according to your needs - and according to your skill level. Don't start a custom domain project, before verifying that your experience is complete. Make the right choice, before you sign on the dotted line.

>> Top

Friday, 1 March 2013

eNom Hosted Custom Domains Again Showing Intermittent Connectivity Issues

This week, we have a few reports in Blogger Help Forum: Something Is Broken, about active and mature domains, suddenly stopped working.
I have used my domain with no problems, since last year. Today, it suddenly stopped working, and the browser reports
Oops! Google Chrome could not find www.mydomain.com.
I asked my friends about my domain - and they tell me that my blog is inaccessible to them, also. I didn't change any settings - and it was fine, until last night.

As we reported last year, the Google partner registrar eNom occasionally has a problem with their DNS server complement. Right now, one of their DNS servers appears consistently bad.

Using a comprehensive Dig tool, we can observe a given domain, and compare the DNS addresses being served by all authoritative name servers for a given domain, in a single transaction.

Here's a hypothetical example, of what we're seeing right now, for several eNom hosted domains.

mycustomdomain.com@dns1.name-services.com.:

mycustomdomain.com. 1800 IN A 216.239.36.21
mycustomdomain.com. 1800 IN A 216.239.34.21
mycustomdomain.com. 1800 IN A 216.239.38.21
mycustomdomain.com. 1800 IN A 216.239.32.21

mycustomdomain.com@dns2.name-services.com.:

mycustomdomain.com. 1800 IN A 216.239.36.21
mycustomdomain.com. 1800 IN A 216.239.34.21
mycustomdomain.com. 1800 IN A 216.239.32.21
mycustomdomain.com. 1800 IN A 216.239.38.21

mycustomdomain.com@dns3.name-services.com.:

mycustomdomain.com. 1800 IN A 216.239.36.21
mycustomdomain.com. 1800 IN A 216.239.32.21
mycustomdomain.com. 1800 IN A 216.239.34.21
mycustomdomain.com. 1800 IN A 216.239.38.21

mycustomdomain.com@dns4.name-services.com.:

mycustomdomain.com. 1800 IN A 216.239.36.21
mycustomdomain.com. 1800 IN A 216.239.34.21
mycustomdomain.com. 1800 IN A 216.239.32.21
mycustomdomain.com. 1800 IN A 216.239.38.21

mycustomdomain.com@dns5.name-services.com.:

org. 3601 IN
SOA dns1.name-services.com. info.name-services.com. 2010 10800 3600 604800 3600


www.mycustomdomain.com@dns1.name-services.com.:

www.mycustomdomain.com. 1800 IN CNAME ghs.google.com.

www.mycustomdomain.com@dns2.name-services.com.:

www.mycustomdomain.com. 1800 IN CNAME ghs.google.com.

www.mycustomdomain.com@dns3.name-services.com.:

www.mycustomdomain.com. 1800 IN CNAME ghs.google.com.

www.mycustomdomain.com@dns4.name-services.com.:

www.mycustomdomain.com. 1800 IN CNAME ghs.google.com.

www.mycustomdomain.com@dns5.name-services.com.:

org. 3601 IN
SOA dns1.name-services.com. info.name-services.com. 2010 10800 3600 604800 3600
Right now, it appears that server "dns5" is consistently broken.

It's possible that this problem will affect more eNom customers, as the day progresses, cached DNS addresses expire, and readers of various eNom hosted domains request DNS addresses. I hope that eNom Customer Service can react to this problem more promptly than they have reacted to the immediately previous problem.

>> Top

Saturday, 8 December 2012

Google Apps Ends Availability Of Their Free Edition

Last week, Google dropped a bombshell on many small client developers.
Starting on December 6, 2012, Google will no longer offer new accounts for the free edition of Google Apps. Google Apps free edition is sometimes referred to as "Standard Edition."

This announcement will bring changes to Blogger, and to custom domain publishing. Many owners of Blogger blogs published using the Google Custom Domain feature have learned to use various Google Apps wizards, to setup and to maintain their domains.

Blogger blog owners have learned (some unwillingly) to use Google Apps for various tasks.
  1. Access the registrar's Domain Manager wizard, after using "Buy a domain".
  2. Deactivate service redirects, such as the Sites service.
  3. Maintain domain "auto renew" settings.
  4. Reset the ever painful "Another blog ..." symptom of database corruption.
  5. Set the option to "Redirect mydomain.com to www.mydomain.com".
  6. Setup email delivery for the domain.
Each of these tasks will have to be performed in different ways, for blog owners who purchased their domains after last week. Previously setup Apps accounts, for the immediate future, are safe.
If you already have the free edition, you can continue to use it for free. This change has no impact on existing users of the free edition.

So far, we've seen some new domain owners use the Trial version of Google Apps, to recycle domain settings, when dealing with "Another blog ...". We hope that this technique will allow temporary access to the domain root redirect, and to service redirect, settings also. We are also seeing a limited functionality free version, which requires some effort to setup, in some cases.

I'm still wondering where Google will hand out Registrar login instructions, and let us maintain domain renewal settings. The popular option to have custom email addresses, based on the domain URL, is most likely gone.

I'll update this article, as details are provided.

>> Top

Sunday, 18 November 2012

Blog Owners Seeing "Error 14" Or Similar Symptom, When Attempting To Publish To A Custom Domain URL

We're seeing a small but steady flood of reports, in Blogger Help Forum: Something Is Broken, from blog owners attempting to publish their blogs using a custom domain URL.
I am not able to redirect my blog from blogspot to my own domain! Blogger is giving me the error
We have not been able to verify your authority to this domain. Error 14.

This specific problem has been observed numerous times in the past, ever since Blogger added the domain ownership verification process to the custom domain publishing feature. Problem reports require careful diagnosis, involving examination of the basic DNS addresses setup with the registrar, to verify the "Error 14" as the primary problem.

Because careful diagnosis is required, for each case reported, we're not adding a Rollup Discussion in the forum. Instead, we request that each blog owner, observing this problem, post her / his problem report in a topic started for that purpose, by himself / herself only. This will allow us to inventory this problem properly, and assist Blogger Engineering in isolating and fixing this problem promptly, so the blog owners can get on with the after publishing process.

Reports of this problem appear to have started in volume late Saturday, 11/17, Pacific time - though some reports, examined in detail, mention the problem initially observed several days ago. The initial volume of the problem appeared to come from SouthEast Asia - but as additional reports were posted, we see Europe and the Americas apparently represented.

Blogger Engineering is now aware of the problem, and will investigate. We'll continue to monitor the forum topics, and to post an initial advisory FAQ, as a response to the reports observed - when reports contain clear evidence of the "Error 14" being a primary symptom. Please monitor that FAQ, and this post, for any ongoing updates.

>> Top

Thursday, 15 November 2012

The Free Domain Registration Service "co.cc" Appears To Be Down

Some Blogger blog owners, trying to save a few dollars while publishing their blogs to a non BlogSpot URL, have used the free service "co.cc" for registering their domains.

As "co.cc" increased its base of "customers", their reputation for providing free registration grew - and they became popular with scammers and spammers.

Last year, Google, weary of the overall poor search engine reputation of co.cc customers, de indexed all websites registered by co.cc. This week, co.cc apparently stopped serving DNS information for its "customer domains".

Strictly speaking, "co.cc" was not a registrar - and the blogs and websites published by its customers were not using registered domains.

The "Top Level domain co.cc" - which by its name implied an Internet service operating from the Cocos (Keeling) Islands - was in fact the domain "co", operating out of Korea, and registered in the Cocos (Keeling) Islands. All "domains" given out by "co.cc" were in fact sub domains to the domain co.cc - and this is where the problem started.

All blogs and websites, published to a "co.cc" subdomain, were aggregated by the search engines as the "co.cc" domain. As the number of co.cc registered scammy and spammy websites increased, their search engine reputation dropped. Non spammy blogs and websites either went out of business, or were transferred to legally registered domains, because of the low reputation and lower search engine originated traffic.

Finally, the owners of co.cc - supposedly "JONG SUNG, KIM" of "GOYANG,GYEOUNGGI" - realised that their run was over, and that they could no longer hide their scams and spams behind legitimate blogs and websites. Apparently, they have now shut their doors.

The old adage comes to mind.
You don't get something for nothing.


If you registered your custom domain using co.cc - and your blog is now offline - you're going to have to publish the blog back to BlogSpot, to get it online again. If you want to use a domain URL, you have to repeat the custom domain setup process - starting with a new, properly paid for, domain URL.

>> Top

Sunday, 11 November 2012

Observe DNS Address Entry Conventions, When Setting Up Your Custom Domain

One of the more frustrating steps involved in setting up a custom domain comes with entry of the DNS addresses, into the domain host or registrar's Domain Manager wizard.

Whether you are setting up a new domain, just purchased directly from a registrar - or re publishing an existing domain, purchased using "Buy a domain" - the addition of the proper DNS addresses is essential to successful custom domain publishing.

Sometimes, you just can't get the domain manager wizard to accept what you are provided by "settings instructions". Other times, you enter the proper values, your Zone Update is accepted by the domain manager wizard - and the Blogger Publishing wizard rejects your attempts.

Even after repeated attempts to publish your blog to the domain, you can get another "Another blog ..." error - maybe an "Error 12" or variant.

This may be in spite of the fact that you are retrieving a new "Name" / "Destination" periodically from "settings instructions", and dutifully adding or updating the domain ownership verification "CNAME" Alternately, you may just be adding the base DNS "A" or "CNAME" addresses.

Every blog owner needs to realise that the Domain Manager wizards have conventions for entry of both the "Name" ("Label" / "Host"), and the "Destination" ("Target" / "Points To") values in the DNS address records ("Zone Entry"). The conventions used will vary, from Domain Manager to Domain Manager - and the differing conventions will affect the success of your domain publishing attempts.

In some cases, the Domain Manager will immediately reject your entry, if you mis enter the value. In other cases, the entry will be accepted - but Blogger will reject your attempts to publish. Either scenario can be caused by misentry of either the "Name" or "Destination" value, and your overlooking the differences between "absolute" vs "relative" addresses.

This problem is observed by some as the mysterious "period" / "full stop".
  • If you omit the period, and it is required, the Zone Update may take place - but the Blogger Publishing wizard will overlook or reject the resulting DNS address.
  • If you add the period, and it is not allowed, the Zone Update will reject your attempt.
This can happen for either the "Name" or "Destination" value.

Here, I will note that this problem is one which neither Blogger nor Google can resolve. Whether you purchased the domain using "Buy a domain" - or directly from the registrar - if you must use the Domain Manager wizard provided by the DNS Host / Registrar, your understanding of the conventions observed by that Domain Manager are your responsibility. There are conventions for the "Name" and for the "Destination" values - and you have to find out, and follow, each.

For a domain of "mydomain.com", you will probably enter the published address - "www.mydomain.com" - as "www". This says that the "Name" value is "relative" to the domain URL. You can't enter the domain root, "mydomain.com", as "mydomain.com" - as this would give you a DNS address of "mydomain.com.mydomain.com" - and yet another "Another blog ..." error. You will probably need to enter the domain root as "@" or a similar special character. This, too, is your responsibility to verify.

If you are asking for help in Blogger Help Forum: Something Is Broken, and I am advising you, I'll be asking you for three essential values.
  1. The BlogSpot URL.
  2. The domain URL.
  3. The "Name" value provided by the "settings instructions" document.
None of these values are optional - and strict attention to accuracy, in your reply, is essential.

>> Top

Thursday, 8 November 2012

Accessing The Registrar's Domain Manager, After Using "Buy a domain"

Setting up a custom domain, and publishing a blog to a non BlogSpot URL, is a simple enough task - when we are able to use the "Buy a domain for your blog" wizard. Sometimes, after using "Buy a domain ...", we may still have to access the registrar's Domain Manager wizard.

When we use "Buy a domain", along with setting up the domain for us, the Blogger / Google wizard sets up a new eNom or GoDaddy domain owner account. To let us later login to eNom or GoDaddy, the "Buy a domain" wizard saves the login information, for our new account - in a Google Apps desktop wizard. Here is yet one more reason why we absolutely must setup the provided Google Apps account, after receiving the Google Apps email.

The process of managing a domain, when setup using "Buy a domain", is not too complicated.
  1. Setup a new Google Apps account. Since free Google Apps accounts are no longer offered, you'll have to setup a Trial - or limited function - account.
  2. Login to Google Apps.
  3. Retrieve the Google Apps registrar login information, from "Advanced DNS settings".
  4. Login to the registrar (eNom or GoDaddy).


The domain owner registrar login information is right there, in "Advanced DNS settings".


The domain owner login information is in the Google Apps desktop.
  1. Go to "Domain settings" - "Domain names" - "Advanced DNS settings".
  2. Open a new browser tab or window, clicking on "Sign in to DNS console".
  3. Copy the Sign-in name, and the Password, to the appropriate boxes on the sign-in dialogue, and click "Login".
  4. This will put you into the Domain Manager wizard, for the new domain.


If you already had an eNom or GoDaddy account, that will be a separate account - but with this new account maintained for you, by Google. Just keep your new Google Apps account accessible and active, keep the domain registration up to date - and you'll have no problem accessing the Domain Manager wizard, and managing the domain, whenever you need.

>> Top

Saturday, 3 November 2012

Use Third Party DNS Servers, For Domains Registered By 1And1, And Similar Registrars

Not all registrars are able to support the new Blogger domain ownership verification requirement.

Some registrars won't allow a second "CNAME" in the same subdomain - and others can't handle the excessively long target address. Ever since Blogger added domain ownership verification, we've been seeing complaints from some blog owners, who have purchased domains directly from registrars who can't provide the required DNS addresses on their servers.

Even though not all registrars have DNS servers that will provide the right DNS address entries, most registrars will allow us to use third party DNS servers. The use of publicly available DNS servers, which can provide the required DNS addresses, will eliminate the need to transfer domain registration - when the registrar is unable to provide the right DNS addresses, using their own servers.

If you're trying to setup your domain, purchased from 1And1 or a similar registrar, you need only to setup a suitable third party DNS server.

Use of a third party DNS host will also help victims of the eNom DNS Infrastructure problem - and those who purchased Name Registration, directly from the registrar.

Marc Ridey, of Blogger Engineering, provides How to setup your Blogger blog with a custom domain from 1and1.com, and adds three simple steps to the normal third party registrar domain setup process.
  1. Setup a (free) ClouDNS account.
  2. Setup your normal DNS addresses (including the required domain ownership verification "CNAME") in ClouDNS, using the ClouDNS Domain Manager wizard.
  3. Setup your domain, using your registrar's domain manager wizard, pointing to the ClouDNS DNS servers.

When you update DNS addresses, such as adding additional hosts, and ownership verification, you use the ClouDNS Domain Manager wizard.

If you are using your third party registrar because you have non Blogger services (a web site, email, files, or other service) hosted by the registrar, please note the warning by Marc!
Warning: If you are using 1and1 hosting services to display a website as well as a Blogger blog, these instructions will disable the website. Please post a comment with your website address and I'll check how these instructions must be updated. If you're using eMail, remember to complete the optional eMail step.

Note that ClouDNS, when setup, may offer the option to redirect the domain root (aka "naked domain") to the "www" alias (or whatever DNS address you may setup). For best results, ignore that option, and use the Blogger or Google Apps redirect. There are still only three acceptable DNS models - use of ClouDNS, or any similar third party DNS host, will not change that.

This may not be an ideal solution for the problem - it introduces a bit of complexity into the domain setup process - but it will allow owners of newly purchased domains from 1And1, Network Solutions, and others to get their domains verified, and get their blogs online again. And, since this starts with blog owners who elected to purchase their domain directly from a registrar - and setup the domain themselves - maybe it's not too much, technically.

>> Top

Tuesday, 16 October 2012

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

Monday, 2 July 2012

eNom: Fix Your DNS Servers!

For over 2 months, we've been seeing reports from blog owners who published their blogs to custom domains, with domain DNS hosted by eNom, in Blogger Help Forum: Something Is Broken.
I bought my domain name through Blogger,last week. It is being hosted by eNom. Ever since I bought it some of my followers, and sometimes myself, can't access my site. There is either a DNS search or a "Ooops, Google Chrome can't find..."

I tried contacting eNom, and they said they can see my site and that all of my settings are correct. They say it must be Google's problem.
The keyword here is "sometimes".
Ever since I bought it some of my followers, and sometimes myself, can't access my site.

A simple Dig, for the domain in question, will frequently show normal results. The usual DNS configuration, for a domain purchased using "Buy a domain", will be asymmetrical aka "Google Apps".
enomhosteddomain.com. 1800 IN A 216.239.32.21
enomhosteddomain.com. 1800 IN A 216.239.34.21
enomhosteddomain.com. 1800 IN A 216.239.36.21
enomhosteddomain.com. 1800 IN A 216.239.38.21
www.enomhosteddomain.com. 1800 IN CNAME ghs.google.com.
The problem, which not so many people appreciate, is that eNom uses multiple DNS servers, possibly geographically separated. This is normal DNS hosting technique, and guarantees redundancy if one data center goes offline.

However, for redundancy to work, all DNS servers have to be kept consistently synchronised. If we examine the 5 eNom DNS servers individually, we will frequently see discrepancies.
enomhosteddomain.com @ dns1.name-services.com.:

enomhosteddomain.com. 1800 IN A 216.239.32.21
enomhosteddomain.com. 1800 IN A 216.239.34.21
enomhosteddomain.com. 1800 IN A 216.239.36.21
enomhosteddomain.com. 1800 IN A 216.239.38.21
enomhosteddomain.com. 3600 IN NS dns1.name-services.com.
enomhosteddomain.com. 3600 IN NS dns2.name-services.com.
enomhosteddomain.com. 3600 IN NS dns3.name-services.com.
enomhosteddomain.com. 3600 IN NS dns4.name-services.com.
enomhosteddomain.com. 3600 IN NS dns5.name-services.com.

enomhosteddomain.com @ dns2.name-services.com.:

enomhosteddomain.com. 1800 IN A 216.239.34.21
enomhosteddomain.com. 1800 IN A 216.239.38.21
enomhosteddomain.com. 1800 IN A 216.239.32.21
enomhosteddomain.com. 1800 IN A 216.239.36.21

enomhosteddomain.com @ dns3.name-services.com.:

com. 3601 IN SOA dns1.name-services.com. info.name-services.com. 2010 10001 1801 604801 181

enomhosteddomain.com @ dns4.name-services.com.:

enomhosteddomain.com. 1800 IN A 216.239.32.21
enomhosteddomain.com. 1800 IN A 216.239.36.21
enomhosteddomain.com. 1800 IN A 216.239.34.21
enomhosteddomain.com. 1800 IN A 216.239.38.21

enomhosteddomain.com @ dns5.name-services.com.:

enomhosteddomain.com. 1800 IN A 216.239.32.21
enomhosteddomain.com. 1800 IN A 216.239.34.21
enomhosteddomain.com. 1800 IN A 216.239.36.21
enomhosteddomain.com. 1800 IN A 216.239.38.21
enomhosteddomain.com. 3600 IN NS dns1.name-services.com.
enomhosteddomain.com. 3600 IN NS dns2.name-services.com.
enomhosteddomain.com. 3600 IN NS dns3.name-services.com.
enomhosteddomain.com. 3600 IN NS dns4.name-services.com.
enomhosteddomain.com. 3600 IN NS dns5.name-services.com.


www.enomhosteddomain.com @ dns1.name-services.com.:

www.enomhosteddomain.com. 1800 IN CNAME ghs.google.com.

www.enomhosteddomain.com @ dns2.name-services.com.:

www.enomhosteddomain.com. 1800 IN CNAME ghs.google.com.

www.enomhosteddomain.com @ dns3.name-services.com.:

com. 3601 IN SOA dns1.name-services.com. info.name-services.com. 2010 10001 1801 604801 181

www.enomhosteddomain.com @ dns4.name-services.com.:

www.enomhosteddomain.com. 1800 IN CNAME ghs.google.com.

www.enomhosteddomain.com @ dns5.name-services.com.:

www.enomhosteddomain.com. 1800 IN CNAME ghs.google.com.

This is one of the more subtle discrepancies, which I have observed, in the past couple months - only DNS Server #3 is out of synch, in this case. But that's enough, to make the domain unreliable.
The problem is intermittent. All of a sudden my site loads, but 10 minutes ago it didn't.
That's one eNom customer, out of over a dozen, which I have documented. And that's one eNom customer, who should be complaining, to someone above eNom Customer Service.

eNom: fix your servers!


(Update 2012/07/03): Suspicion that the problem is related to Anycast DNS led me to a bud, who is a fellow TC, and a network expert in India, and who provided an intriguing blog post, neatly diagnosing the underlying problem. It appears that eNom server monitoring policies may be a bit superficial.


Use these links, for convenient reference:

>> Top

Tuesday, 19 June 2012

Custom Domain Diagnoses - Identify DNS Address Inconsistencies

One of the more intriguing causes of intermittent custom domain problems starts with inconsistent DNS server configuration. Recently, eNom, one of the "partners" in "Buy a domain", has been serving inconsistent DNS configurations, from time to time - including one very blatant episode the afternoon of 6/18/2012, which was reported by several dozen angry blog owners.

Detecting, and diagnosing, the inconsistencies is typically a complicated process.
  1. Identify the domain authority servers, typically using a Who Is lookup.
  2. Dig each domain address (typically "naked domain" and "www" aliases), from each of the identified domain authority servers.
  3. Extract and aggregate each Dig log.
  4. Compare aggregated Dig snippets.
This was not a task for the faint of heart, or tech challenged, blog owner.

Recently, I was given a handy tool which does all of this, in one quick GUI transaction.

The Dig Web Interface, yet another free online tool, provides us the ability to diagnose inconsistent DNS servers - such as the problem eNom seems to have, in a 30 second transaction.
  1. Provide the "naked domain" and "www" aliases.
  2. Select "A" for "Type" ("A" / "CNAME" / "NS" lookups).
  3. Select "Authoritative" for "Nameservers".
  4. Hit "Dig".
Finally, just copy the log produced, for examination.

It's not a fancy tool, but it does the job - very well. Here, we see the log for this domain, "nitecruzr.net".
nitecruzr.net@ns11.domaincontrol.com.:
nitecruzr.net. 3600 IN A 216.239.36.21
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.38.21
nitecruzr.net. 3600 IN NS ns54.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns53.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns12.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns11.domaincontrol.com.


nitecruzr.net@ns12.domaincontrol.com.:
nitecruzr.net. 3600 IN A 216.239.36.21
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.38.21
nitecruzr.net. 3600 IN NS ns54.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns53.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns12.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns11.domaincontrol.com.


nitecruzr.net@ns53.domaincontrol.com.:
nitecruzr.net. 3600 IN A 216.239.36.21
nitecruzr.net. 3600 IN A 216.239.34.21
nitecruzr.net. 3600 IN A 216.239.38.21
nitecruzr.net. 3600 IN A 216.239.32.21
nitecruzr.net. 3600 IN NS ns54.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns53.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns12.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns11.domaincontrol.com.


nitecruzr.net@ns54.domaincontrol.com.:
nitecruzr.net. 3600 IN A 216.239.36.21
nitecruzr.net. 3600 IN A 216.239.34.21
nitecruzr.net. 3600 IN A 216.239.38.21
nitecruzr.net. 3600 IN A 216.239.32.21
nitecruzr.net. 3600 IN NS ns54.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns53.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns12.domaincontrol.com.
nitecruzr.net. 3600 IN NS ns11.domaincontrol.com.


www.nitecruzr.net@ns11.domaincontrol.com.:
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.


www.nitecruzr.net@ns12.domaincontrol.com.:
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.


www.nitecruzr.net@ns53.domaincontrol.com.:
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.


www.nitecruzr.net@ns54.domaincontrol.com.:
www.nitecruzr.net. 3600 IN CNAME ghs.google.com.
The log is not complicated, to parse. For each URL, each authority server is identified, and Dug. In the case of this domain, hosted on GoDaddy, we see each URL, Dug from each of 4 authority servers, one by one.

If a DNS inconsistency existed, the above log would show the differing DNS addresses - such as eNom hosted domains show, from time to time. Given this tool, it may be easier to look for DNS inconsistencies, when problems with custom domains are reported, in Blogger Help Forum: Something Is Broken.

>> Top