Assigned
Status Update
No update yet.
Comments
cb...@google.com
Do you want to setup in Cloud DNS the root domain as an ¨ALIAS¨?
i.e. instead of
example.com pointing to A record
example.com pointing to an alias record (as defined here [1]) with value myapp.inthecloud.com
The approach does not seems to comply with standard record types [2] defined in the RFC. I would like to fully understand your use case. Please provide me additional insight on how you would benefit from this.
Would Cloud CDN [3] serve as a workaround?
[1]https://help.github.com/articles/setting-up-an-apex-domain/
[2]https://en.wikipedia.org/wiki/List_of_DNS_record_types
[3]https://cloud.google.com/cdn/docs/
i.e. instead of
The approach does not seems to comply with standard record types [2] defined in the RFC. I would like to fully understand your use case. Please provide me additional insight on how you would benefit from this.
Would Cloud CDN [3] serve as a workaround?
[1]
[2]
[3]
th...@hollandware.com
[1] That is correct
[2] Also correct, if the Google Cloud DNS configuration is a 1 to 1
translation to your DNS server then this issue is a won't fixer. But if
there is a possibility to create a proxy from the hostname that will
translate to multiple A records for each edge DNS server then this will be
a great feature.
*Please provide me additional insight on how you would benefit from this. *
At this moment we have an experiment with Firebase, build on Cloud
Storage/CDN (www.123test.de ), the speed results are great:
https://performance.sucuri.net/domain/www.123test.de
But, we think to go further with a cloud solution with dynamic content
delivery, instead of full static webserver [4] For better performance, we
not only want the assets in the CDN, but also to get the website in the
cloud. From my opinion I think Cloud CDN is too much configuration to get a
minimal cloud solution [4]. Most of these cloud solutions recommend this
unofficial DNS record above the A record [5]:
https://support.stackpath.com/hc/en-us/articles/230171888-What-is-an-ALIAS-or-ANAME-record
[4] Minimal feature: Automatic caching pull system to your own server, with
the switch if it should cache depending with the expire header.
https://www.stackpath.com/secure-cdn/
https://aws.amazon.com/cloudfront/dynamic-content/
[5] Please note that traditional A records are different from (ANAME and
ALIAS) records mentioned in this article. A Records are the most basic type
of DNS record and are used to point a domain or subdomain to an IP address.
We do not recommend the use of A records with your Secure CDN service as
they eliminate the option for load balancing on CDN Edge servers and could
result in unintended downtime for your visitors.
2017-05-10 21:27 GMT+02:00 <buganizer-system@google.com>:
[2] Also correct, if the Google Cloud DNS configuration is a 1 to 1
translation to your DNS server then this issue is a won't fixer. But if
there is a possibility to create a proxy from the hostname that will
translate to multiple A records for each edge DNS server then this will be
a great feature.
*Please provide me additional insight on how you would benefit from this. *
At this moment we have an experiment with Firebase, build on Cloud
Storage/CDN (
But, we think to go further with a cloud solution with dynamic content
delivery, instead of full static webserver [4] For better performance, we
not only want the assets in the CDN, but also to get the website in the
cloud. From my opinion I think Cloud CDN is too much configuration to get a
minimal cloud solution [4]. Most of these cloud solutions recommend this
unofficial DNS record above the A record [5]:
[4] Minimal feature: Automatic caching pull system to your own server, with
the switch if it should cache depending with the expire header.
[5] Please note that traditional A records are different from (ANAME and
ALIAS) records mentioned in this article. A Records are the most basic type
of DNS record and are used to point a domain or subdomain to an IP address.
We do not recommend the use of A records with your Secure CDN service as
they eliminate the option for load balancing on CDN Edge servers and could
result in unintended downtime for your visitors.
2017-05-10 21:27 GMT+02:00 <buganizer-system@google.com>:
cb...@google.com
Thank you for the additional feedback.
I have forwarded your request to our engineering team. I cannot provide an E.T.A. or guarantee that this feature will be deployed. Nevertheless rest assured that your feedback is always seriously taken.
Any future updates will be posted on this thread. Once again let me thank you for helping us to improve the functionality of our products.
I have forwarded your request to our engineering team. I cannot provide an E.T.A. or guarantee that this feature will be deployed. Nevertheless rest assured that your feedback is always seriously taken.
Any future updates will be posted on this thread. Once again let me thank you for helping us to improve the functionality of our products.
ab...@abevoelker.com
This feature is required in order to use Heroku and other PaaS providers without a "www" subdomain prefix. It's sad that I have to move from Cloud DNS to Cloudflare just because of this one limitation. It could be a nice differentiating feature for Cloud DNS compared to AWS, because Route 53 doesn't currently support this either.
Here's a relevant Stack Exchange post that shows other people are running into this limitation:https://serverfault.com/questions/617248/does-google-domains-support-cname-like-functionality-at-the-zone-apex
Here's a relevant Stack Exchange post that shows other people are running into this limitation:
pw...@gmail.com
Can anyone who works at Google explain why they don't support ALIAS?
gi...@google.com
oh...@gmail.com
This is a real vanity killer for the new .app domains. Can we get an ETA on this? Take a look at domains such as Cash.app and Shop.app -- no www required.
ju...@protonmail.ch
We need this feature, Please consider it to support.
lu...@webranking.it
+1 on this
ra...@ggfilmz.com
When will this ever get implemented ????
pa...@google.com
Joshua Fox joshua@doit-intl.com opened https://sfstory.googleplex.com/28854596#bottom
This is related to this FR. They are requesting a workaround for this issue for a customer of theirs. See below.
A customer needs to point a root domain to a load balancer. See ticket for links to these.
An ALIAS record would work for this, but Cloud DNS does not support ALIAS records. [1][2]
What is the recommended workaround?
[1]
https://issuetracker.google.com/issues/195055037
[2]
https://stackoverflow.com/questions/60345861/
This is related to this FR. They are requesting a workaround for this issue for a customer of theirs. See below.
A customer needs to point a root domain to a load balancer. See ticket for links to these.
An ALIAS record would work for this, but Cloud DNS does not support ALIAS records. [1][2]
What is the recommended workaround?
[1]
[2]
br...@gmail.com
+1
The web has changed a lot since the original DNS specification was published. We did not have cloud computing, PaaS, etc. The modern computing environment cries out for an "ALIAS" or "ANAME" record type. The "workarounds" and operational impacts of the myopic cry "But it violates the standards!!" are undeniable.
It is true that this may violate the spirit of the original DNS Specification. RFC 882 and RFC 883 were the first drafts that sought to regulate host naming and were published in 1983. That is 40 years ago. Before HTTP, the web, or the internet.
A scant ~2 years later in Jan 1986 RFC 973 was published updating RFC 882 and RFC 883. That was 38 years ago.
2 years later in late 1987 RFC 1034 and RFC 1035 superseded the previous DNS guidance. That was 37 years ago. RFCs that would extend the original standard have been proposed, but the DNS standard that we all know and love today is firmly rooted in the pre-internet, pre-web, pre-cloud days of ARPANET. Sorry, but sometimes the truth hurts.
So what we have here is Google taking the position that a standard that was defined almost 40 years ago, prior to the invention of the world wide web. 10 years prior to the publication of the HTTP specification that changed the way we approached distributed systems networking and design, and roughly 20 years before our initial forays into cloud computing; were so pure, perfect, and ideal that they cannot and should not be changed.
The addition of a "ALIAS" or "ANAME" record to the DNS spec would not redefine other record types. It would violate just TWO requirements in the DNS specification regarding Apex Zones and ultimately it would modernize the DNS specification.
Google has chosen to ignore the "dangling DNS record" issue that this outdated requirement creates for modern distributed networking. I must say that it would seem that Google is either too myopic and steeped in tradition or too lazy to do what MANY other DNS providers are doing: changing with the times and adapting to the ever evolving computing landscape in order to fix an artifact from a requirement defined in a bygone era.
With that said, there are other large providers that offer ALIAS records. Perhaps Google could be motivated if their customers started voting with their feet by moving their domains (along with their annual domain renewal budgets) to more forward thinking DNS providers.
The web has changed a lot since the original DNS specification was published. We did not have cloud computing, PaaS, etc. The modern computing environment cries out for an "ALIAS" or "ANAME" record type. The "workarounds" and operational impacts of the myopic cry "But it violates the standards!!" are undeniable.
It is true that this may violate the spirit of the original DNS Specification. RFC 882 and RFC 883 were the first drafts that sought to regulate host naming and were published in 1983. That is 40 years ago. Before HTTP, the web, or the internet.
A scant ~2 years later in Jan 1986 RFC 973 was published updating RFC 882 and RFC 883. That was 38 years ago.
2 years later in late 1987 RFC 1034 and RFC 1035 superseded the previous DNS guidance. That was 37 years ago. RFCs that would extend the original standard have been proposed, but the DNS standard that we all know and love today is firmly rooted in the pre-internet, pre-web, pre-cloud days of ARPANET. Sorry, but sometimes the truth hurts.
So what we have here is Google taking the position that a standard that was defined almost 40 years ago, prior to the invention of the world wide web. 10 years prior to the publication of the HTTP specification that changed the way we approached distributed systems networking and design, and roughly 20 years before our initial forays into cloud computing; were so pure, perfect, and ideal that they cannot and should not be changed.
The addition of a "ALIAS" or "ANAME" record to the DNS spec would not redefine other record types. It would violate just TWO requirements in the DNS specification regarding Apex Zones and ultimately it would modernize the DNS specification.
Google has chosen to ignore the "dangling DNS record" issue that this outdated requirement creates for modern distributed networking. I must say that it would seem that Google is either too myopic and steeped in tradition or too lazy to do what MANY other DNS providers are doing: changing with the times and adapting to the ever evolving computing landscape in order to fix an artifact from a requirement defined in a bygone era.
With that said, there are other large providers that offer ALIAS records. Perhaps Google could be motivated if their customers started voting with their feet by moving their domains (along with their annual domain renewal budgets) to more forward thinking DNS providers.
ar...@gmail.com
+1
I fully agree with the Dec 8th submission above.
I fully agree with the Dec 8th submission above.
cb...@gmail.com
If anyone is wondering, this has been solved here: https://cloud.google.com/dns/docs/records-overview#alias-records
Using the alpha cli it is possible to create an alias record like so.
gcloud alpha dns record-sets createexample.com . --rrdatas="yourcname.example.com ." --type=ALIAS --ttl=60 --zone=example
Using the alpha cli it is possible to create an alias record like so.
gcloud alpha dns record-sets create
zh...@gmail.com
Any plans on supporting DNSSEC on domains having alias record? Or this might be more appropriate for a new issue (or maybe wait until this reaches GA)?
Is there any ETAs on how long it'll take for this feature to be available in GA? I guess minimally ALIAS record need to be actionable in web ui before it can be available in GA?
In case anyone else is wondering, you can see release notes related to Cloud DNS here:https://cloud.google.com/dns/docs/release-notes
Is there any ETAs on how long it'll take for this feature to be available in GA? I guess minimally ALIAS record need to be actionable in web ui before it can be available in GA?
In case anyone else is wondering, you can see release notes related to Cloud DNS here:
Description
The server will do a redirect from
Reason:
Most cloud solutions will deliver the a hostname instead of a A-record. Also the server in the netherlands will get an unnecessary request to deliver a 301 redirect response.
Definition:
An ALIAS record is a virtual record type that we created to provide CNAME-like behavior on apex domains. For example, if your domain is