如何克服根域CNAME限制?

发布于 2024-07-15 09:32:34 字数 757 浏览 11 评论 0 原文

我们为客户托管许多网络应用程序。 很明显,他们希望使用自己的域来引用这些应用程序,通常他们希望任何输入 http://www.customer1.examplehttp://customer1 的用户.example 转到他们的 Web 应用程序。

我们面临的情况是,我们需要在不久的将来能够灵活地更改IP地址。 我们不想依赖客户对其域进行 A 记录更改。 因此,我们认为使用 CNAME 记录可行,但我们发现 CNAME 记录不适用于根域。

基本上:

customer1.example IN CNAME customer1.mycompanydomain.example //this is invalid as the RFC
www.customer1.example IN CNAME customer1.mycompanydomain.example //this is valid and will work

我们希望能够更改 customer1.mycompanydomain.example 的 IP 地址或 A 记录,并且我们的客户将遵循我们可以控制的此记录。

在我们的 DNS 中,它看起来像:

customer1.mycompanydomain.example IN A 192.0.2.1

有什么想法吗?

We are hosting many web applications for our customers. As is obvious they want to use their own domains to refer to those applications, usually they want that any user that either type http://www.customer1.example or http://customer1.example goes to their web application.

The situation we are facing is that we need to have the flexibility to change IP addresses in the near future. And we don't want to rely on the customer doing the A record change on their domains. So we thought that using CNAME records will work, but as we find out CNAME records will not work for the root domain.

Basically:

customer1.example IN CNAME customer1.mycompanydomain.example //this is invalid as the RFC
www.customer1.example IN CNAME customer1.mycompanydomain.example //this is valid and will work

We want to be able to change the IP address of customer1.mycompanydomain.example or the A record and our customers will follow this record which we have control over.

in our DNS it will look like:

customer1.mycompanydomain.example IN A 192.0.2.1

Any ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(10

红衣飘飘貌似仙 2024-07-22 09:32:34

这个问题仍然经常出现的原因是,正如您所提到的,在某个地方,有人认为重要的人写道,RFC 声明前面没有子域的域名无效。 然而,如果您仔细阅读 RFC,您会发现这并不完全是它所说的。 事实上,RFC 1912 指出:

不要过度使用 CNAME。 重命名主机时使用它们,但计划删除它们(并通知您的用户)。

某些 DNS 主机提供了一种使用自定义记录类型在区域顶端(根域级别,对于裸域名)获取类似 CNAME 的功能的方法。 此类记录包括,例如:

  • DNSimple 的 ALIAS
  • DNS Made Easy 的 ANAME
  • easyDNS 的 ANAME
  • CloudFlare 的 CNAME

对于每个提供商,设置类似:将您的顶级域的 ALIAS 或 ANAME 条目指向 example.domain.com,就像您一样会带有 CNAME 记录。
根据 DNS 提供商的不同,空值或 @ 名称值可标识区域顶点。

ALIAS 或 ANAME 或 @ example.domain.com。

如果您的 DNS 提供商不支持此类记录类型,并且您无法切换到支持的记录类型,则您将需要使用子域重定向,这并不难,具体取决于需要执行此操作的协议或服务器软件。

我强烈不同意这种说法,即它只是由“业余管理员”或此类想法完成的。 这是一个简单的“名称及其服务需要做什么?” 处理,然后调整您的 DNS 配置以满足这些愿望; 如果您的主要服务是网络和电子邮件,我看不出有任何有效的理由说明为什么永久删除 CNAME 会出现问题。 毕竟,谁会更喜欢 @subdomain.domain.org 而不是 @domain.org 呢? 如果您已经设置了协议本身,谁还需要“www”? 假设使用根域名无效是不合逻辑的。

The reason this question still often arises is because, as you mentioned, somewhere somehow someone presumed as important wrote that the RFC states domain names without subdomain in front of them are not valid. If you read the RFC carefully, however, you'll find that this is not exactly what it says. In fact, RFC 1912 states:

Don't go overboard with CNAMEs. Use them when renaming hosts, but plan to get rid of them (and inform your users).

Some DNS hosts provide a way to get CNAME-like functionality at the zone apex (the root domain level, for the naked domain name) using a custom record type. Such records include, for example:

  • ALIAS at DNSimple
  • ANAME at DNS Made Easy
  • ANAME at easyDNS
  • CNAME at CloudFlare

For each provider, the setup is similar: point the ALIAS or ANAME entry for your apex domain to example.domain.com, just as you would with a CNAME record.
Depending on the DNS provider, an empty or @ Name value identifies the zone apex.

ALIAS or ANAME or @ example.domain.com.

If your DNS provider does not support such a record-type, and you are unable to switch to one that does, you will need to use subdomain redirection, which is not that hard, depending on the protocol or server software that needs to do it.

I strongly disagree with the statement that it's done only by "amateur admins" or such ideas. It's a simple "What does the name and its service need to do?" deal, and then to adapt your DNS config to serve those wishes; If your main services are web and e-mail, I don' t see any VALID reason why dropping the CNAMEs for-good would be problematic. After all, who would prefer @subdomain.domain.org over @domain.org ? Who needs "www" if you're already set with the protocol itself? It's illogical to assume that use of a root-domainname would be invalid.

鲜血染红嫁衣 2024-07-22 09:32:34

对根记录进行 CNAME 从技术上讲并不违反 RFC,但确实存在局限性,这意味着不建议这样做。

通常您的根记录会有多个条目。 假设,3 个代表您的名称服务器,然后 1 个代表 IP 地址。

根据 RFC:

如果节点上存在 CNAME RR,则不应显示其他数据
存在;

根据 IETF“常见 DNS 操作和配置错误”文档:

缺乏经验的管理员经常尝试这样做,因为这是显而易见的
让您的域名也成为主机的方法。 然而,DNS
像 BIND 这样的服务器将看到 CNAME 并拒绝添加任何其他
该名称的资源。 由于不允许有其他记录
与 CNAME 共存时,NS 条目将被忽略。 因此所有的
podunk.xx 域中的主机也会被忽略!

参考文献:

CNAME'ing a root record is technically not against RFC, but does have limitations meaning it is a practice that is not recommended.

Normally your root record will have multiple entries. Say, 3 for your name servers and then one for an IP address.

Per RFC:

If a CNAME RR is present at a node, no other data should be
present;

And Per IETF 'Common DNS Operational and Configuration Errors' Document:

This is often attempted by inexperienced administrators as an obvious
way to allow your domain name to also be a host. However, DNS
servers like BIND will see the CNAME and refuse to add any other
resources for that name. Since no other records are allowed to
coexist with a CNAME, the NS entries are ignored. Therefore all the
hosts in the podunk.xx domain are ignored as well!

References:

终弃我 2024-07-22 09:32:34

我不知道他们是如何逃脱惩罚的,也不知道他们可能会产生什么负面影响,但我正在使用 Hover.com 托管我的一些域名,并且最近将我的域名的顶点设置为 CNAME。 他们的 DNS 编辑工具根本没有抱怨,我的域很高兴通过分配的 CNAME 进行解析。

以下是 Dig 向我展示的该域名的内容(实际域名被混淆为 mydomain.com):

; <<>> DiG 9.8.3-P1 <<>> mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2056
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mydomain.com.          IN  A

;; ANSWER SECTION:
mydomain.com.       394 IN  CNAME   myapp.parseapp.com.
myapp.parseapp.com. 300 IN  CNAME   parseapp.com.
parseapp.com.       60  IN  A   54.243.93.102

I don't know how they are getting away with it, or what negative side effects their may be, but I'm using Hover.com to host some of my domains, and recently setup the apex of my domain as a CNAME there. Their DNS editing tool did not complain at all, and my domain happily resolves via the CNAME assigned.

Here is what Dig shows me for this domain (actual domain obfuscated as mydomain.com):

; <<>> DiG 9.8.3-P1 <<>> mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2056
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mydomain.com.          IN  A

;; ANSWER SECTION:
mydomain.com.       394 IN  CNAME   myapp.parseapp.com.
myapp.parseapp.com. 300 IN  CNAME   parseapp.com.
parseapp.com.       60  IN  A   54.243.93.102
猫弦 2024-07-22 09:32:34

我的公司为许多客户做了同样的事情,我们为他们托管一个网站,尽管在我们的例子中它是 xyz.company.com 而不是 www.company.com。 我们确实让他们在 xyz.company.com 上设置 A 记录,以指向我们分配给他们的 IP 地址。

至于如何应对IP地址的变化,我认为没有完美的解决方案。 一些想法是:

  • 使用 NAT 或 IP 负载平衡器,并为您的客户提供属于它的 IP 地址。 如果 Web 服务器的 IP 地址需要更改,您可以对 NAT 或负载均衡器进行更新,

  • 同时提供 DNS 托管服务,并让您的客户与您一起托管他们的域,以便您可以使用更新 A 记录的位置,

  • 让您的客户将其 A 记录设置为一台主 Web 服务器,并对每个客户的 Web 请求使用 HTTP 重定向。

My company does the same thing for a number of customers where we host a web site for them although in our case it's xyz.company.com rather than www.company.com. We do get them to set the A record on xyz.company.com to point to an IP address we allocate them.

As to how you could cope with a change in IP address I don't think there is a perfect solution. Some ideas are:

  • Use a NAT or IP load balancer and give your customers an IP address belonging to it. If the IP address of the web server needs to change you could make an update on the NAT or load balancer,

  • Offer a DNS hosting service as well and get your customers to host their domain with you so that you'd be in a position to update the A records,

  • Get your customers to set their A record up to one main web server and use a HTTP redirect for each customer's web requests.

孤芳又自赏 2024-07-22 09:32:34

Sipwiz 是正确的,正确执行此操作的唯一方法是 HTTP 和 DNS 混合方法。 我的注册商是 Tucows 的经销商,他们提供根域转发作为免费的增值服务。

如果您的域名是 blah.com,他们会询问您希望将域名转发到哪里,然后您输入 www.blah.com。 他们将 A 记录分配给他们的 apache 服务器并自动添加 blah.com 作为 DNS 虚拟主机。 虚拟主机响应 HTTP 302 错误,将它们重定向到正确的 URL。 它的脚本/设置很简单,并且可以由低端处理,否则硬件就会报废。

运行以下命令作为示例:
卷曲-v eclecticengineers.com

Sipwiz is correct the only way to do this properly is the HTTP and DNS hybrid approach. My registrar is a re-seller for Tucows and they offer root domain forwarding as a free value added service.

If your domain is blah.com they will ask you where you would like the domain forwarded to, and you type in www.blah.com. They assign the A record to their apache server and automaticly add blah.com as a DNS vhost. The vhost responds with an HTTP 302 error redirecting them to the proper URL. It's simple to script/setup and can be handled by low end would otherwise be scrapped hardware.

Run the following command for an example:
curl -v eclecticengineers.com

晨曦慕雪 2024-07-22 09:32:34

您必须在外部域末尾添加一个句点,这样它就不会认为您的意思是 customer1.mycompanydomain.com.localdomain;

所以只需更改

customer1.com IN CNAME customer1.mycompanydomain.com

customer1.com IN CNAME customer1.mycompanydomain.com.

You have to put a period at the end of the external domain so it doesn't think you mean customer1.mycompanydomain.com.localdomain;

So just change:

customer1.com IN CNAME customer1.mycompanydomain.com

To

customer1.com IN CNAME customer1.mycompanydomain.com.
水水月牙 2024-07-22 09:32:34

一种解决方案是为 www 子域创建 CNAME,然后将根域转发到您的 www 子域。 第一步是在 DNS 设置中完成,第二步是在转发域部分中完成。

参考:https://www.tachyonstemplates.com/2018/google-domains -forward-root/

One solution is to create CNAME for www subdomain, then forward the root domain to your www subdomain. First step is done in DNS setting, and the second step is done in Forward Domain section.

Reference: https://www.tachyonstemplates.com/2018/google-domains-forward-root/.

盗琴音 2024-07-22 09:32:34
  • 如果您的域名注册商支持 ANAME,那么您可以使用 ANAME 记录重定向您的根域。

  • 如果否,但支持转发 DNS,例如 Google Domain,那么您可以

  1. 添加 CNAME 记录来重定向 http://www .customer1.example 到您想要的域名。
  2. 在正向 DNS 设置中,将 http://customer1.example 设置为 url: http://www.customer1.example

然后就完成了。 通常您可能需要等待几分钟才能生效

  • If your domain register supports ANAME, then you can redirect your root domain using ANAME record.

  • if NO, but it supports forwarding DNS, such as Google Domain, then you can

  1. add a CNAME record to redirect http://www.customer1.example to the domain name you want.
  2. in forward DNS setting, set http://customer1.example to url: http://www.customer1.example,

Then it's done. Usually you may need to wait for a few minutes for it take effect

念三年u 2024-07-22 09:32:34

我看到readytocloud.com 托管在Apache 2.2 上。

在 Apache 中,有一种更简单、更有效的方法可以将非 www 站点重定向到 www 站点。

将以下重写规则添加到 Apache 配置(虚拟主机内部或外部。这并不重要):

RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule ^/$ http://www.readytocloud.com/ [R=301,L]

或者,如果您希望将非 www 站点的 URL 一对一映射到www 站点:

RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule (.*) http://www.readytocloud.com$1 [R=301,L]

注意,需要加载 mod_rewrite 模块才能使其工作。 幸运的是,readytocloud.com 在 CentOS 机器上运行,默认情况下加载 mod_rewrite。

我们有一个运行 Apache 2.2 的客户端服务器,有不到 3,000 个域和近 4,000 个重定向,但是服务器上的负载徘徊在 0.10 - 0.20 左右。

I see readytocloud.com is hosted on Apache 2.2.

There is a much simpler and more efficient way to redirect the non-www site to the www site in Apache.

Add the following rewrite rules to the Apache configs (either inside the virtual host or outside. It doesn't matter):

RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule ^/$ http://www.readytocloud.com/ [R=301,L]

Or, the following rewrite rules if you want a 1-to-1 mapping of URLs from the non-www site to the www site:

RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule (.*) http://www.readytocloud.com$1 [R=301,L]

Note, the mod_rewrite module needs to be loaded for this to work. Luckily readytocloud.com is runing on a CentOS box, which by default loads mod_rewrite.

We have a client server running Apache 2.2 with just under 3,000 domains and nearly 4,000 redirects, however, the load on the server hover around 0.10 - 0.20.

垂暮老矣 2024-07-22 09:32:34

感谢 sipwiz 和 MrEvil。 我们开发了一个 PHP 脚本,它将解析用户输入的 URL 并将 www 粘贴到其顶部。 (例如,如果客户输入 kiragiannis.com,那么它将重定向到 www.kiragiannis.com)。 因此,我们的客户将其根目录(例如 customer1.com 指向我们的 Web 重定向器所在的 A 记录),然后指向 www CNAME 到我们管理的真实 A 记录。

如果您对未来的我们感兴趣,请在代码下方。

<?php
$url = strtolower($_SERVER["HTTP_HOST"]);

if(strpos($url, "//") !== false) { // remove http://
  $url = substr($url, strpos($url, "//") + 2);
}

$urlPagePath = "";
if(strpos($url, "/") !== false) { // store post-domain page path to append later
  $urlPagePath = substr($url, strpos($url, "/"));
  $url = substr($url, 0, strpos($url,"/"));
}


$urlLast = substr($url, strrpos($url, "."));
$url = substr($url, 0, strrpos($url, "."));


if(strpos($url, ".") !== false) { // get rid of subdomain(s)
  $url = substr($url, strrpos($url, ".") + 1);
}


$url = "http://www." . $url . $urlLast . $urlPagePath;

header( "Location:{$url}");
?>

Thanks to both sipwiz and MrEvil. We developed a PHP script that will parse the URL that the user enters and paste www to the top of it. (e.g. if the customer enters kiragiannis.com, then it will redirect to www.kiragiannis.com). So our customer point their root (e.g. customer1.com to A record where our web redirector is) and then www CNAME to the real A record managed by us.

Below the code in case you are interested for future us.

<?php
$url = strtolower($_SERVER["HTTP_HOST"]);

if(strpos($url, "//") !== false) { // remove http://
  $url = substr($url, strpos($url, "//") + 2);
}

$urlPagePath = "";
if(strpos($url, "/") !== false) { // store post-domain page path to append later
  $urlPagePath = substr($url, strpos($url, "/"));
  $url = substr($url, 0, strpos($url,"/"));
}


$urlLast = substr($url, strrpos($url, "."));
$url = substr($url, 0, strrpos($url, "."));


if(strpos($url, ".") !== false) { // get rid of subdomain(s)
  $url = substr($url, strrpos($url, ".") + 1);
}


$url = "http://www." . $url . $urlLast . $urlPagePath;

header( "Location:{$url}");
?>
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文