If you're reading this, you have a computer (or at least access to one). Your computer is being used as a client, to read this blog, which is located on a server. The Internet is a "Client - Server" application, and Google has thousands of servers, which they use to provide us access to our blogs, and other activities.
I won't go into the details here, but aside from the fact that both clients and servers are types of computers, there are not a lot of significant similarities between the two. Servers are generally not, in a well designed and secured environment, used as clients.
Then there's Google. If a Google server needs to provide you access to your blog that's published to a custom domain, it has to contact a Google DNS server to get the IP address of your blog, located on another Google server. That is, a server becomes a client. And there is one of the weaknesses of the custom domain product, in general.
The Google DNS server has to contact the DNS server for your domain, to get the information that it passes back to the Google "client server". This allows the Google "client server" to access the Google "server server", and provide you access to your blog.
Custom domains are very dependent upon DNS settings, and DNS settings for custom domains are provided, by design, by outside parties, located all over the Internet. DNS information for your custom domain is not provided by Google, it has to be provided by a third party.
The stability of your custom domain, with its content hosted on Google servers, is affected by DNS servers that are part of the public Internet infrastructure, and can be located anywhere in the world. And, it's affected by "servers" that are being used as "clients". That's a paradigm shift, and considering the differences between "clients" and "servers", it's substantial.
A second paradigm shift is seen when you try to diagnose a problem with your custom domain. You can run local diagnostics which show what you see, using your local DNS server. You may use a web based diagnostic like Rex Swain's HTTP Viewer, which will show you what can be seen from the DNS server that provides service to Rex Swain's "client server". Neither your local diagnostics, nor diagnostics from Rex Swain or other Internet services, will be predictably identical to the DNS information which the Google "DNS client server" is getting.
And there you see reasons why I say over and over, that the "Magical" Custom Domain Reset Form won't be retired any time soon.
>> Top
I won't go into the details here, but aside from the fact that both clients and servers are types of computers, there are not a lot of significant similarities between the two. Servers are generally not, in a well designed and secured environment, used as clients.
Then there's Google. If a Google server needs to provide you access to your blog that's published to a custom domain, it has to contact a Google DNS server to get the IP address of your blog, located on another Google server. That is, a server becomes a client. And there is one of the weaknesses of the custom domain product, in general.
The Google DNS server has to contact the DNS server for your domain, to get the information that it passes back to the Google "client server". This allows the Google "client server" to access the Google "server server", and provide you access to your blog.
Custom domains are very dependent upon DNS settings, and DNS settings for custom domains are provided, by design, by outside parties, located all over the Internet. DNS information for your custom domain is not provided by Google, it has to be provided by a third party.
The stability of your custom domain, with its content hosted on Google servers, is affected by DNS servers that are part of the public Internet infrastructure, and can be located anywhere in the world. And, it's affected by "servers" that are being used as "clients". That's a paradigm shift, and considering the differences between "clients" and "servers", it's substantial.
A second paradigm shift is seen when you try to diagnose a problem with your custom domain. You can run local diagnostics which show what you see, using your local DNS server. You may use a web based diagnostic like Rex Swain's HTTP Viewer, which will show you what can be seen from the DNS server that provides service to Rex Swain's "client server". Neither your local diagnostics, nor diagnostics from Rex Swain or other Internet services, will be predictably identical to the DNS information which the Google "DNS client server" is getting.
And there you see reasons why I say over and over, that the "Magical" Custom Domain Reset Form won't be retired any time soon.
>> Top
Comments
There are plenty of times when a server becomes a client. Sometimes what we connect to is nothing more than a cache, that will contact a web server for non-cached bits, and that now indirect server will then contact a SQL server of some type, and then collect other bits from other servers, such as Networked Attached Storage (NAS).
And then there are times when the client is actually referred to as the server.
Server/client is confusing anytime.
I refer to my machine as just that, my machine, and everything else outside of my little 192.168.0.x network as the Internet. It either works, or it doesn't.
As far as "Cute DNS Tricks by Google", what actually happens with DNS is really convoluted, and even certified and seasoned professionals will tell you they sometimes don't understand the subtleties.
And obviously even Google has troubles, as the issues with DNS and custom blog publishing are showing.
Do you have any understanding about the reasoning behind the "Transition" period for new custom domains?
I see TTL latency, which affects existing domains, where existing address records remain in local DNS cache all over the world, until they expire. But why is there latency for new domains, where address records do not exist yet?