☰

根域 ( @)

tag-icon • tag-icon domain-name-system routing load-balancing infrastructure
根域 ( @)

我有许多拥有自己的名称服务器的客户，我想为他们提供相同的 DNS 详细信息，就像 Squarespace 或 Shopify 所做的那样（例如，始终相同的@A 记录和www.CNAME），然后管理在我的终端将他们的流量路由到哪个服务器。

当我需要将大量网站迁移到新的基础设施上时，这将提供巨大的帮助，而且我不想花费数周时间与不同公司的不同 IT 部门沟通，要求他们更新其域名的 DNS 设置及其所有管理。

是否有可用于此目的的负载平衡器或代理？我想知道什么是最佳实践。您会推荐什么？

答案1

我猜你指的是这shopify DNS 设置。

将A记录指向 Shopify IP 地址23.227.38.65。将CNAME名称www为shops.myshopify.com

根域 ( @)

正如您所知，您不能在根（）域上拥有 CNAME @，因此根域需要使用指向固定 IP 地址的A和记录来处理。AAAA

大公司在全球范围内扩展这一业务的方式是使用“任播”，即通过 BGP 从多个不同的数据中心公布相同的 IP 地址。

您可以将任播视为由路由器处理的负载平衡，其中相同或不同数据中心中的多个服务器可以接收和处理单个 IP 地址的流量。

如果您还不是具有自己的 IP 空间的 AS，那么任播肯定超出了您的范围。

这里最简单的开始方式是不在根域上运行任何托管，而只是重定向到www。然后一个 nginx 重定向器框（或 level4/tcp 负载平衡器后面的多个）可以处理相当多的域重定向。

如果由于请求数量巨大而需要大量的盒子，请使用 tcp/layer4 负载平衡到您的重定向服务器，以便您可以在负载平衡器后面的盒子上执行应用程序（http）和 ssl 终止，从而获得更高的可扩展性（单个负载平衡器可以处理更多流量）。

使用永久重定向（301）无限期缓存减少来自同一客户的重复流量。

最佳实践在这里。设置 DNS 后，使用 letsencrypt/certbot 自动生成/更新重定向器域。 始终重定向到同一域上的 https（例如http://example.com --> https://example.com）然后重定向到另一个域（https://www.example.com）。

万维网

查看 shopify shops.myshopify.com（应该指向的位置），您可以看到它目前www CNAME有一条记录。A23.227.38.74

用一个全局 ping 工具您可以看到，这个 IP 在世界各地的延迟只有几毫秒。这意味着它肯定不是单个位置的单个服务器（跨大西洋延迟通常在最佳情况下为 60 毫秒……因此，当您看到来自美国和欧盟的同一 IP 的 ping 为 4 毫秒时……您就知道这些 ping 不是发往同一服务器的）。您还可以通过从不同地理位置的不同服务器对同一 IP 运行跟踪路由来验证这一点。

在响应该 IP 的每个端点上，他们可能都有一个负载均衡器将请求路由到不同的硬件。

因此，在 shopify CNAME 背后，它是单 IP 任播。向客户提供 CNAME 的好处是，您可以自由更改该名称背后的 IP，而无需客户在其端更新 DNS。关于这一点……当您向客户提供A其根 ( @) 域重定向器的记录时……您需要确保这是一个您可以控制的 IP 地址，如果您的服务器/负载均衡器出现问题（例如 AWS 弹性 IP 类型的东西或您自己的 IP 空间，如果您是 AS），则可以将其重新分配给不同的硬件。

据我所知，当您的计算机在解析名称时遵循 CNAME 链来告诉最终 DNS 服务器您请求的原始域是什么时，DNS 请求（以及 DNS 解析器缓存的一部分）中没有任何“提示”。如果有，那么您可以想象 DNS 服务器具有条件规则，可根据名称背后的名称返回相同名称的不同 IP 地址。

因此，如果您不打算采用 shopify 方式 (bgp/anycast)。最直接的做法是让您的客户唯一的 CNAME。这样，您可以在 DNS 级别进行负载平衡（为每个唯一的客户 CNAME 返回不同的 IP）。

您可以遵循一些约定customerdomain.tld.example.com，并根据客户资产数据库自动配置 DNS。

对于根域 ( @)，您仍然可以使用单个重定向器 IP（单个 IP/负载均衡器后面的一个或多个框）管理所有域的重定向www.customerdomain.tld哪些 CNAME 到customerdomain.tld.example.com。

更新...也许我没有理解你的问题的重点。

当我需要将大量网站迁移到新的基础设施时，这将有很大帮助

正如我上面提到的，至少对于根/@案例，您需要控制该 IP 并能够将其分配给其他基础设施……否则当该 IP 由于迁移而发生变化时，您的所有客户都必须更新他们的 DNS。

对于 www/CNAME情况，这不是问题，因为您只需在自己的 DNS 上更新 CNAME 后面的 IP 即可。

因此，我将重点介绍仅针对根域 ( @) 情况的选项，因为这是最成问题的（当客户的服务 IP 地址发生变化时，需要客户采取行动来更新 DNS）。选项...

@选项 0 - 不支持客户的根/域

无论您托管什么，都将其托管在子域（www或其他域）上。如果客户想要重定向，他们可以与 IT 人员一起管理。

这完全消除了客户 DNS 指向固定 IP 地址的问题。您可以在您的终端更新 CNAME(s) IP 地址，任何基础设施移动或 IP 更改都变得简单。

选项 1 - 可分配 IP 地址

您可以使用可分配 IP 地址之类的东西（AWS 弹性 IP 类型的东西，大多数严肃的 VPS 提供商都提供类似的东西）。

这使您可以部署一个新服务器（在该提供商处），然后将 IP 切换到新服务器。

问题在于，您有供应商/提供商锁定，因为 IP 地址属于供应商。因此，如果您想从 AWS 迁移到 Google-Cloud 或您自己的硬件，您就无法带走这些 IP……为您的客户更新 DNS。此外，IP 可能被区域锁定，因此您无法轻松地将 IP 分配给不同数据中心的提供商的另一台服务器。

选项 2 - 成为 AS 并获得自己的 IP 空间

如果你正在认真做托管，那么成为 AS 只是时间问题（自治系统） 通过艾林或者成熟如果您的公司位于北美和欧洲以外，则可能是其他组织。

然后，您需要获取（或租用）自己的 IP 地址块。通常您可以免费获得 ipv6。ipv4 已经用完了，但至少 RIPE 允许您在等待列表中获取/24（256 个地址），当他们随着时间的推移恢复这些地址时。否则，您必须从某人那里购买地址空间（您可以加入市场）。

当然，您需要与允许您自带 IP 地址的提供商合作。

以下是几个实用的链接，可帮助您完成任播设置。但对于初学者来说，请忽略任播部分，并专注于设置 AS、获取 IP 空间和找到合适的基础设施合作伙伴。（因为运行 BGP/任播并不是一件容易的事。）

缺点：

  • 投入时间进行设置和学习（例如，如果您的上游提供商没有为您处理 BGP）。
  • 金融投资（RIPE/ARIN 的会员费/IP 费用以及获取/租赁 IPv4 块的潜在巨额成本）。
  • 仅限于与允许你自带 IP 的 VPS 提供商合作
    • 或者您必须租赁机架空间并处理对等/路由/交换/BGP/等、硬件故障、SNMP 硬件监控等。
  • 新的干扰，例如需要开具罚单并处理与你的 IP 空间相关的滥用投诉

在一定规模下或者如果您已经拥有管理它的技能和工具，这肯定是有意义的。

选项 3 - 非标准 DNS

一些托管 DNS 提供商已添加CNAME对裸域/根域的支持。

如果您使用其中一个提供商，或者如果您运行自己的 DNS 则自行实现此功能……那么就可以解决问题。

请参阅此答案

如果您依赖此功能，那么您将被供应商锁定到支持此非标准功能的 DNS 提供商。或者您需要运行自己的 DNS 并自行实现此功能。

选项 4 - CDN

根据您的应用，您可以在其前面放置另一项服务。即类似 CDN 的服务（stackpath、cloudflare、aws-cloudfront 等）。这些服务将处理 DNS/anycast 和相关主题，您可以让您的客户指向 CDN 服务并在 CDN 后面运行您的服务。

更改后端服务成为 CDN（或类似服务）处的配置更改，以告诉 CDN 应从中请求内容的端点的名称/ IP。

缺点：

  • 如果您不需要，则需要额外付费。
  • 需要确保在 CDN 上配置了缓存与非缓存（例如应用程序）端点以匹配您的应用程序的工作方式。
  • 如果您的应用程序无法正常运行，则需要调试额外的层（是 CDN 破坏了请求还是您的应用程序破坏了？）。
  • 通常这意味着您客户的 CNAME 记录将指向 CDN 的域...而不是您的域。您的域在 CDN 应用程序的配置中作为上游服务器。因此，您有供应商锁定...如果您想切换 CDN，您的所有客户都需要更新他们的 DNS CNAME 以指向新的。您可以通过放置 2 层 CNAME（客户 -> 您 -> CDN）来缓解这种情况，但从绩效视角。

我会做什么

如果您没有关于客户群规模、技能（例如 BGP）、是否运行自己的硬件或租用廉价 VPS 的更多详细信息……

我喜欢简单，以后你总是可以让它变得更复杂。最简单的事情是什么，可以降低我的成本，不花费太多时间，为我的客户提供良好的用户体验，并最终让我重新回到创收活动（而不是花时间在需要时间/财务成本的技术后端，希望大规模降低总体成本）。我不是谷歌，所以我宁愿增加我的营业额，而不是微优化我的利润……特别是如果（目前）没有技术需求的话。

我会做以下事情......

  • 不支持客户的裸域/根域。需要重定向的客户可以让 IT 人员在他们那边进行设置。这样就省去了一个大麻烦。
    • 或者，如果您想支持这一点，那么您可以设置一个您知道不会丢失的单个重定向器 IP（例如 AWS 弹性 IP），并让客户设置A和AAAA记录。您的其余服务不必托管在同一位置（即，如果您需要扩展重定向，重定向器可以是带有 ELB 的 AWS，而客户机可以放在便宜的 VPS 上）。
  • 每个客户都会根据其托管域或客户 ID 获得一个可预测的（对他们来说唯一的） CNAME（CUS1234.example.com如果您让客户能够轻松更改他们托管的域，则更有意义）。
  • 我的 DNS 会根据我的客户数据库（客户域 -> 客户特定的 CNAME -> 托管客户应用程序的 IP 地址）自动更新。
  • 我可以轻松监控该客户的 DNS，并且我的 DNS 都指向正确的位置。
  • 我可以从客户端分别监控每个客户的 DNS 流量/滥用（因为它们具有唯一的名称）。

客户只需设置一次 DNS，除非他们想要更改托管域，否则无需更改它。

如果您拥有良好的备份/恢复/复制机制，并且这些机制与您的服务器/vps/应用程序配置层上的某种形式的服务发现协同工作，那么基础架构迁移就相对容易。

  • CUST1234.example.com A 10.0.0.1在迁移之前的某个时间在您的 DNS 记录上设置低 DNS TTL（即客户的 CNAME 指向的名称）。
  • 启动新的基础设施，包括从旧基础设施复制数据（数据库、用户上传的内容等）。
  • 切换客户 DNS 记录 ( A, AAAA) 以指向新 IP
  • DNS TTL + 余量到期后，删除旧的基础结构。

如果您的数据后端无法同时处理来自 2 个实时客户端点的写入，那么您可能需要暂停迁移......因为旧的 DNS 缓存过期时会出现一些重叠。

这种设置的优点是，我几乎可以在任何我想要的知名 VPS 提供商上运行（我的自动配置并不挑剔）。我不需要投资成为 AS，也不需要处理管理自己的 IP 空间的额外开销（在一定规模下这样做肯定是有意义的……但我不知道贵公司的情况）。

我可以做类似基于 DNS 的地理负载平衡的事情（根据请求服务器的区域返回相同名称的不同 IP）。这允许您向客户提供不同区域内同名的多个服务器（这样他们在加载应用程序时就不必处理跨美国或跨大西洋的延迟）。您可以按每个客户的需求提供这项服务作为增值/追加销售。

关于负载平衡的说明...

我多次提到 tcp/layer4 负载平衡，但并未详述。通常，负载平衡有两种常见类型：layer4/transport/tcp 和 layer7/application/http(s)。

layer7/application/http 负载均衡器“使用”http 并终止 SSL 连接，然后将请求（通常为未加密的 http）代理到均衡器/代理后面的多个服务器之一。这很简单，但可能会导致问题，即负载均衡器后面的服务器不知道在写入标头、安全 cookie、重定向等时应该假装使用 https。这还意味着您的负载均衡器必须为每个请求执行更多工作（解析 http 并处理 SSL 开销）。这项额外的工作限制了负载均衡器的可扩展性，负载均衡器通常是单个节点/机器/vps。

layer4/tcp 负载均衡器不需要解析 http 请求，也不需要承担 SSL 终止的开销。它对 http 一无所知。请求被路由到处理 SSL 终止和处理 http 请求的多个服务器之一。

如果您担心 TLS 会话重用（或缺乏）会影响性能，通常使用 redis 或 memcached 作为多个 Web 服务器之间的共享 TLS 会话缓存，这样您就不必担心负载均衡器会让用户“粘”在负载均衡器后面的特定框上。 nginx似乎不支持机外 TLS 会话缓存（缓存仅在同一台机器上的 nginx 工作器之间共享）。haproxy似乎有但是我还没有尝试过，也不知道它在发生 ssl 终止的 nginx 池前面的 haproxy/level4 中会如何工作。

您可以使用 nginx 或 haproxy 作为 layer4/tcp 负载均衡器，两者的设置都相当简单。对于更高级的用例（可能还有更好的性能），您还可以查看 Linux 虚拟服务器 (LVS)。

另一种分配负载的方法是让单个名称返回多个 A 或 AAAA 记录。理想情况下，DNS 客户端会从返回的地址中随机选择，这样您就可以在多个 IP 地址上分配一些负载。如果您开始遇到负载平衡器层的扩展问题，这是一种增加更多扩展的低技术方法（只需针对相同或不同的应用程序服务器池添加另一个负载平衡器）。但是，没有什么可以强制客户端轮询您的 IP 地址...因此这不会让您对哪些 IP 获得负载有太多控制权...但总比没有好。

答案2

@mattpr 给出的答案非常详细，非常周到。它包含许多非常准确的有用信息。我不想从这个答案中抹去任何痕迹，它真的很棒。

我的方法会简单得多。我会在[插入选择的云供应商]并使用类似 nginx 代理管理器（https://nginxproxymanager.com/)。它允许代理并重定向到其他 URL。它很容易在 Docker 容器中设置。它支持缓存、websockets 和 Let's Encrypt。

让您的客户将他们的 @ 指向您的主机 IP，然后为他们创建一个 A 记录，以将他们的 www CNAME 指向 (hosting.myawesomecompany.com)。然后为该客户设置代理配置，以将请求指向正确的服务器/基础设施。

确保 nginx 代理管理器保持更新，并确保 webui 对 IP ACL 或类似物的安全。

相关内容