Настройка частной зоны AWS
Я пытаюсь настроить пару одноранговых узлов VPC на Amazon. Один из VPC используется в течение некоторого времени, а другой - это новый VPC, который я только что настроил. В рамках этих усилий я связал существующую частную размещенную зону Route 53 с новым VPC. Но по какой-то причине экземпляры EC2 в новом VPC не могут выполнять поиск имен из частной размещенной зоны.
Я включил разрешение DNS и имена хостов DNS для нового VPC. Я не могу себе представить, что настройка пиринга вызывает проблемы, но я установил и принял пиринговое соединение и настроил маршруты между новым VPC и существующим. Пиринговое соединение, похоже, работает, так как я могу открыть соединение с экземпляром EC2 на старом VPC.
Я не совсем уверен, где отключение. Я просмотрел все варианты, которые смог найти для Privated Hosted Zone и VPC, но не нашел ничего многообещающего.
старый VPC
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.13.1 0.0.0.0 UG 0 0 0 eth0
10.0.13.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.169.254 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
$ dig sql04 +trace
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.45.amzn1 <<>> sql04 +trace
;; global options: +cmd
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
;; Received 496 bytes from 10.0.0.2#53(10.0.0.2) in 100 ms
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2016052600 1800 900 604800 86400
;; Received 98 bytes from 193.0.14.129#53(193.0.14.129) in 77 ms
$ nslookup sql04
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
Name: sql04.domain.local
Address: 10.1.3.28
новый VPC
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.1.255.1 0.0.0.0 UG 0 0 0 eth0
10.1.255.0 0.0.0.0 255.255.255.192 U 0 0 0 eth0
169.254.169.254 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
$ dig sql04 +trace
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.45.amzn1 <<>> sql04 +trace
;; global options: +cmd
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
;; Received 228 bytes from 10.1.0.2#53(10.1.0.2) in 161 ms
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2016052600 1800 900 604800 86400
;; Received 98 bytes from 192.33.4.12#53(192.33.4.12) in 38 ms
$ nslookup sql04
Server: 10.1.0.2
Address: 10.1.0.2#53
** server can't find sql04: NXDOMAIN
Чтобы повторить то, что написал @ Michael-sqlbot в своем комментарии, я столкнулся с очень похожей проблемой. Проблема заключалась в том, что связанный VPC с моей частной размещенной зоной был другим. У меня было пиринговое соединение VPC между двумя VPC (назовем их VPC1 и VPC2).
Экземпляр EC2, который я выполнял nslookup внутри был на VPC1, но моя связанная частная размещенная зона была с VPC2. Как и сообщение OP, nslookup показывает, что мой DNS-запрос обслуживается DNS-сервером VPC по умолчанию ( 10.1.0.2 адрес). Однако, если вы не связываете частную размещенную зону с этим VPC, то, как указывает ошибка, DNS-сервер не знает, как разрешить этот запрос. Вот экран консоли Route 53, с которым вы выполняете ассоциации (обратите внимание, что вы можете связать несколько VPC):
