Question

在我失去与网站的HTTP连接的过程中，我通过SSH进入服务器进行一些更新。

当我进行更新时，遇到yum问题之后，我在没有真正理解的情况下阅读并尝试了以下方法之一：

sudo dhclient

这几乎是与网络相关的唯一事物。

当我从PC尝试以下操作时：

curl -v http://sub.my-web-site.com/

结果：

* Hostname was NOT found in DNS cache
* Could not resolve host: sub.my-web-site.com
* Closing connection 0
curl: (6) Could not resolve host: sub.my-web-site.com

当我尝试通过IP地址连接时，其中一台虚拟主机似乎响应。

我多次重启实例无济于事。我似乎没有想起更改实例上的任何设置，而且似乎也不是VPC的一部分。

DNS位于路由53中，重新启动后，实例的公共IP发生了更改，因此我在路由53中进行了相应更新。

我尝试从其他几台服务器上进行挖掘，结果略有不同：

dig sub.my-web-site.com

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56905
;; QUESTION SECTION:
;sub.my-web-site.com. IN      A
;; AUTHORITY SECTION:
my-web-site.com.        300     IN      SOA     01.dnsv.jp. hostmaster.dnsv.jp. 1531475254 3600 900 604800 300
;; SERVER: 202.167.237.16#53(202.167.237.16)

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56905
;; QUESTION SECTION:
;sub.my-web-site.com. IN      A
;; AUTHORITY SECTION:
my-web-site.com.        60      IN      SOA     01.dnsv.jp. hostmaster.dnsv.jp. 1531475254 3600 900 604800 300
;; SERVER: 10.0.0.2#53(10.0.0.2)

那些NXDOMAIN看起来不好。

如何解决此问题？

编辑：

我推测可能还有其他原因，并且在开始更新之前这已经是一个问题。我可以控制子域，但不能控制主域，最近主域被重新指向了新站点。有效果吗？

其他编辑：

我注意到主站点的whois，我发现名称服务器有所不同，因此我将主站点的NS添加到路由53 NS。还是不行。

Answer 1

DNS解析与服务器本身无关。您从不同的服务器收到不同的响应的事实表明存在传播延迟。

几个小时后重试，看看所有服务器是否都以相同的方式解析。

避免这种延迟的一种方法是为EC2实例分配弹性IP地址。实例停止/启动时，该地址不会更改，也可以立即将其分配给其他实例（无传播延迟）。您可以将A记录从DNS名称指向弹性IP地址，然后以后就无需更改它。

Answer 2

1-这是您使用Route 53的DNS委派的问题

正如您在评论中所说，您的主域是rise-corp.tokyo，而您的子域之一是test.rise-corp.tokyo。

您似乎尚未在Route 53上注册域名rise-corp.tokyo：

% whois -h whois.nic.tokyo rise-corp.tokyo | grep Registrar | grep ID
Registrar IANA ID: 49

您的注册服务商ID为49，但Route 53使用的注册服务商ID只有两个：468和81，具体取决于TLD（请参阅IANA注册服务商ID公开列表：81是AWS分包商的注册商，而468是直接注册到AWS）。

因此，如Route 53文档中所述：

如果您想将域名保留在当前的注册商处， 通知注册服务商将您的域的名称服务器更新为与您的托管区域相关联的。如果您已注册域名称与Route 53一起使用，您的域名将自动关联使用正确的名称服务器。

因此，您的域尚未自动与正确的名称服务器关联，因为您的主域注册商不在Route 53所使用的两个注册商之列。

因此，在这种情况下，您应该遵循以下文档：如果要保留当前注册商的域名，请通知注册商将您的域的名称服务器更新为与托管服务器关联的名称服务器。区域。

但是您似乎还没有：

% whois -h whois.nic.tokyo rise-corp.tokyo | grep 'Name Server'
Name Server: 01.DNSV.JP
Name Server: 02.DNSV.JP
Name Server: 03.DNSV.JP
Name Server: 04.DNSV.JP

% dig rise-corp.tokyo NS +short
03.dnsv.jp.
04.dnsv.jp.
01.dnsv.jp.
02.dnsv.jp.

这些服务器都不是AWS Route 53名称服务器。

因此，在53号公路中将test添加为rise-corp.tokyo的子域不会使该子域得到解析。因为服务于东京TLD请求的服务器没有针对rise-corp.tokyo的正确的Route 53 NS资源记录。

2-这里是如何设置正确的委派

查看Route 53控制台，
为您的主域找到Route 53名称服务器，
替换* .dnsv.jp。

完成此操作后，将自动执行以下步骤：

该域名服务提供商会将信息推送到名为GMO Internet的注册商ID 49，
GMO Internet将把信息推送到东京注册表，该注册表管理服务于东京TLD请求的服务器。

请注意，这条链中有一条捷径：GMO Internet同时是您的主要域rise-corp.tokyo的注册商（ID 49）和tokyo TLD的注册商。因此，先前的两个操作将一次完成。

3-深入的解释

选择哪个主机是域的DNS服务器，并选择由所选DNS服务器提供服务的区域文件的内容是两件事。我的意思是，为域名rise-corp.tokyo选择的DNS服务器是* .dnsv.jp还是53号路由，这一事实不会更改www.rise-corp.tokyo的IP地址，www.test.rise -corp.tokyo，rise-corp.tokyo或test.rise-corp.tokyo。这仅表示主机名到地址的映射存储在* .dnsv.jp服务器或Route 53服务器中。唯一的区别在于哪个管理员可以更改这些主机名到地址的映射。

当发生这种情况时，有两组人需要管理一个主域的一部分，解决此问题的常用方法是委派一个子域。就您而言，我知道您只需要管理test.rise-corp.tokyo和诸如mywebserver.test.rise-corp.tokyo之类的子域名，因为相应的主机位于EC2上，并且您希望Route 53自动设置从其名称到其公共IP的映射。因此，您可以简单地要求负责rise-corp.tokyo的人员将test.rise-corp.tokyo委托给53号公路。

为此，请不要在53号公路上声明rise-corp.tokyo，而只需声明test.rise-corp.tokyo。查看控制台，找到运行该域的Route 53域名服务器，并要求管理* .dnsv.jp的人为test.rise-corp.tokyo添加一些NS记录，指向test.rise-corp的Route 53服务器东京。

最后，请注意，这种情况并不常见，但是两个不同的团队可以共享资源记录，例如名称到地址的映射（“ IN A”资源记录），即使这些映射位于同一级别，例如host1.rise-corp.tokyo和host2.rise-corp.tokyo。为此，rise-corp.tokyo的所有者使用host1.rise-corp.tokyo的一些“ IN NS”资源记录，将host1.rise-corp.tokyo委托给第一团队的一些名称服务器，第一小组为host1.rise-corp.tokyo创建一个区域文件，并向host1.rise-corp.tokyo的IP地址添加一个“ IN A”资源记录。第二队也做同样的事情。这样一来，第一团队可以自行更改host1.rise-corp.tokyo的IP地址，第二团队也可以自行更改host2.rise-corp.tokyo的IP地址： host1的IP地址仅存储在第一小组管理的名称服务器中，host2的IP地址仅存储在第二小组管理的名称服务器中。 host1或host2的IP地址没有存储在主域rise-corp.tokyo的区域文件中。主域的区域文件仅存储两个团队的DNS服务器的主机名（如果这些主机名在相应的子区域下，则将一些由“ IN A”资源记录组成的GLUE记录存储到名称服务器中，但这些IP地址与host1和host2的名称到地址的映射无关。使用CNAME代替host1.rise-corp.tokyo和其他较小更改的NS记录是另一种方法。

最后，我想说分布式DNS系统可以处理许多事情和情况。但是，要使所有这些正常工作，关键在于所有合作伙伴之间的适当协调。

无法解析EC2实例上的主机

2 个答案: