如何通过不阅读RFC 1034来浪费半天时间

嘿使用了一个分支部署系统，这是我在SVN上写过的，在Twitter上经常被提及。许多其他公司已经实现了他们自己版本的分支部署(通常使用不同的名称)，但这是我自己的实现，所以我为此感到自豪。首先，介绍一下它的工作原理：

自动构建管道运行由GitHub网络挂钩启动。它构建一些Docker映像，并启动另一个处理部署本身的构建。

该部署版本通过包含所有YAML部署、服务、入口等规范的Helm图表，部署到Amazon的托管Kubernetes产品AWS EKS。

开发人员可以使用特定于分支机构的特殊URL从浏览器访问其分支机构。从推送到可访问(通常情况下)，这一过程需要5-10分钟才能访问一个全新的分支机构。

每个分支都需要自己的ALB(这是由Inress资源生成的)。

DNS是DNS，有时需要一段时间才能传播，需要我们管理大量记录(每个分支3-5个)。

这些错误是交织在一起的：如果我不必为每个分支提供自己的ALB，我可以使用通配符记录，并将我们的分支部署特定域上的每个子域指向单个ALB，然后让ALB通过主机标头将请求路由到它们所属的位置。这意味着我可以通过不需要所有的ALB来节省资金，并且我们可以将DNS成为DNS的时间减少到零(以及整个YAML中分布的外部DNS注释和条件的复杂性)。

(虽然等待DNS传播和解析几分钟听起来不是什么大不了的事，但我们通过在部署构建完成后立即访问新主机名上的内部路径来检查修订版本是否已实际部署，从而在创建记录之前尝试解析DNS，并在TTL到期之前缓存该NXDOMAIN响应，从而对部署流的工作方式进行抨击。)

在此之前，这是可行的，但需要一些额外的工作，这使得它不值得-它可能需要通过一个自定义控制器来完成，该控制器将负责通过自定义注释将您的服务添加到单个Inress对象。这条路径很好(我甚至做了一个概念验证控制器来实现这一点)，但这意味着我们现在必须管理一些额外的工具，以及需要创建和管理主™️对象。

输入一个新版本的alb-inress-Controller(它的新名称是：aws-load-balancer-Controller)，其中包含一个新的IngressGroup特性，该特性完全符合我的需要。它添加了一组新的注释，我可以将其添加到我的Ingresses中，这将导致我的所有Inress资源都是单个ALB上的路由规则，而不是单个ALB上的路由规则。

“太好了！”我想，早上我就开始测试新版本的项目，并弄清楚我想要如何实现这一点(利用它作为一个机会，也清理了一大堆技术债务)。

我把一切都准备好了-我已经在我的测试集群中更新了AWS-Load-Balizer-Controller，删除了旧ALB存在的所有特定于分支的别名记录，告诉外部DNS不要再管理Inress资源，并设置了一个通配符别名，指向所有这些分支都应该共享的新的单个ALB。

我完全不知道发生了什么事。我可以清楚地看到该记录存在于Route53中，但是我不能在本地解析它，一些dns测试服务(❤️MX工具箱)也不能解析它。

也许是通配符记录上的“评估目标健康”选项？把它弄坏了，又试了一次，还是没有结果。

我完全被难住了，开始浏览Route53文档，找到了这一行，并认为它是我问题的答案：

如果您创建了一个名为*.example.com的记录，但没有example.com记录，则路由53将使用NXDOMAIN ID(不存在的域)响应example.com的DNS查询。

因此，我开始为Branch-ployment.com创建一条记录，看看是否就是这样。但这仍然不能解决问题。这时我重新阅读了这一行，并意识到它无论如何都不适用于我-我第一次读错了，我不是在尝试解析Branch-ployment.com。(我最初的理解是，如果没有Branch-ployment.com的记录，*.Branch-ployment.com将无法解析)。

好了，是时候深入了解一下RFC了，这里肯定有什么我漏掉的难懂的东西。正确的假设是。

-当查询位于另一个区域时。也就是说，委派取消通配符默认值。

-当知道存在查询名称或通配符域和查询名称之间的名称时。例如，如果通配符RR的所有者名称为“*.X”，并且区域还包含附加到B.X的RR，则通配符将应用于名称Z.X的查询(假设没有关于Z.X的显式信息)，但不适用于B.X、A.B.X或X。

嗯，第二个要点听起来像是线索。让我回到我的Route53区域看看。

我们的分支机构部署系统的一个功能是，您还可以拥有特定于您的分支机构的正常运行的邮件管道。要使用该功能，您可以通过电子邮件发送电子邮件给您自己@your-brch.Branch-ployment.com。要做到这一点，每个分支都会在您的-Branch ch.Branch-deploy.com上获得一条MX记录。

这就是问题所在。虽然您可以拥有BRANCH-Deployment.com的通配符记录，但如果给定子域存在MX记录(或其他任何记录)，并且您尝试访问YOUR-BRANCH.BRANCH-DEPLOY.com，则A/AAAA/CNAME解析不会爬升到通配符。🙃。

这很可能是一个众所周知的怪癖(它甚至是一个怪癖还是常识？这对我来说肯定不是常识)，但我花了半天的时间用头撞桌子，试图弄清楚为什么这不管用，因为我做了一个糟糕的假设，我真的需要发泄一下。谢谢你纵容我。