rio*_*urn 4 domain-name-system amazon-web-services
有没有办法更改 EC2 服务器的私有 DNS？
我希望能够使用诸如 myserver.example.com 而不是 ip-1.1.1.1-uswest-aws-internal 之类的东西在我的服务器之间进行通信。我是系统管理员角色和网络的新手。我尝试在 VPC 中使用 DHCP 选项集，但无法使其正常工作。
为了澄清我想要实现的目标……我正在设置 Jenkins，它将在众多服务器上运行从属设备。我希望能够使用我自己分配的地址而不是任意地址，因此它更有意义，它取决于作业在哪台机器上运行。
我也相信它会让其他服务器间的通信在未来更容易。就像我说的，我是系统管理员的新手，所以如果我缺少更简单的方法，请告诉我。
如果你想通过 my-dns-name 访问你的服务器，你需要设置你自己的 DNS 服务器。
默认情况下，AWS VPC 会为您处理 DHCP 并附带 Amazon 的 DNS 服务器。
您可以在此处阅读提供您自己的 DNS 服务器的选项：http : //docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html
DHCP 选项名称：域名服务器
最多四个域名服务器的 IP 地址，或 AmazonProvidedDNS。默认 DHCP 选项集指定 AmazonProvidedDNS。
DHCP 选项名称：域名
如果您在美国东部（弗吉尼亚北部）区域使用 AmazonProvidedDNS，请指定 compute-1.amazonaws.com。如果您在其他区域使用 AmazonProvidedDNS，请指定 region.compute.amazonaws.com。否则，指定一个域名（例如，MyCompany.com）。
如果您想使用 FQDN (myserver.example.com) 进行通信，您可以在没有自己的 DNS 服务器的情况下进行，您的域已经可以公开访问。
您可以与 IP Address'、Private 或 Public 通信，您可以在 OS 级别更改私有 IP，在 OS 级别更改主机名并利用 /etc/hosts 来拥有一种穷人 DNS。
您可能总是想研究 ElasticIP、弹性网络接口和弹性负载均衡器，它们都与您的问题在同一个空间中运行。
这一切都取决于您想要实现的目标，以及您想如何实现！
您无法更改它，除非您部署自己的名称服务器，但您可以通过创建记录轻松使用另一个名称引用它CNAME，这将产生所需的效果。
在您的“example.com”DNS 区域中，无论是在 Route 53 中，还是由其他 DNS 托管服务提供商托管，您都应该能够创建创建CNAME记录：
myserver IN CNAME ip-1.1.1.1-uswest-aws-internal.
当一台机器试图解析“myserver.example.com”时，它本质上会被“example.com”DNS服务器告知它应该查找“真实的”内部主机名（“ c anonical name ”）。如果机器在您的 EC2 部署中，它会要求 EC2 dns 解析器进行查找，然后 EC2 解析器将返回内部 IP 地址……导致您想要的行为——您可以访问您的内部您想要的主机名的机器。
如果 EC2 部署之外的系统查找此主机名，它将失败，这是正确的行为，因为无法从外部访问该机器（如果它只有私有 IP）。
相反，如果您有一台具有公共 IP 和相应公共主机名的机器，就像ec2-x-x-x-x.us-west-2.compute.amazonaws.com使用该主机名作为CNAME目标一样，也会做同样的事情。当从您的EC2 部署内部查询时，结果将是通过 EC2 透明执行的一些 DNS 魔法的内部 IP 地址……或者从外部查询，它将返回外部公共 IP 地址。
澄清：
有两种 DNS 服务器行为——“权威”服务器将响应来自任何主机的对它们具有权威性的任何资源记录的请求……以及递归“解析器”，代表其授权客户端查询全球 DNS . DNS 服务器也可以同时执行这两种功能。
您的 EC2 实例（默认情况下）使用 AWS 解析器服务器来查找您的实例尝试访问的任何主机名，内部 ir 外部，并返回 IP 地址......但 AWS 解析器也对“.internal”具有权威性伪域，因此当实例尝试查找“.internal”主机时，会返回正确的内部 IP。
现在，假设您将内部主机名配置为外部“example.com”DNS 服务器中的 CNAME 目标，然后尝试在内部查找“myserver.example.com”……AWS 解析器咨询全局 DNS 层次结构并最终询问“myserver.example.com”的权威名称服务器之一。响应基本上会说“我所知道的是，要找到 myserver.example.com，您应该查找 ip-1.1.1.1-uswest-aws-internal”……AWS 解析器意识到它不需要咨询外部实体来回答这个新问题，因为它对假内部域是权威的，只是用它已经知道的正确答案来回答。
外部“example.com”不需要或尝试验证 CNAME 目标，因为这不是它的工作。
现在，如果 CNAME 引用外部主机名，过程是相同的，结果是相同的，因为 AWS 解析器（处理您的内部机器发出的所有 DNS 查询）不会尝试实际查找真实和正确的来自对“compute.amazonaws.com”域具有权威性的 DNS 服务器的 IP 地址……相反，由于其设计，它再次相信它已经知道您的外部主机名的 IP 地址……但是答案将再次是您的内部私有 IP 地址。
我在上面所说的 AWS 解析器是一个虚拟实体，只能由您的实例访问。它包含的有关公共主机名到私有 IP 映射的信息只能在您的实例查询时访问。它不能从外部访问。
如果您将内部主机名配置为 CNAME 目标，则外部查询将获得“内部”答案，这对他们来说将是死胡同。如果您提供外部主机名作为 CNAME 目标，它们最终将使用公共 IP，因为查找 CNAME 会将它们定向到公共权威 DNS 服务器，而不是只有您的实例可以访问的私有内部解析器。
这实际上在实践中非常简单，虽然在这里解释起来并不那么简单，因为需要理解 DNS 的许多基础知识，首先......但这最终有效，因为“example.com”DNS 服务器根本不不在乎您是否使用他们理解的 CNAME 配置它们。理解它不是他们的问题——负担在于解析器，它正在寻找答案以最终理解 CNAME 中出现的中间答案。