Делегирование зоны AWS Route53 внутренним серверам имен центров обработки данных


Я пытаюсь делегировать подзону публичного домена внутреннему dns-серверу, однако на обычный запрос ответа не возвращается, однако когда я делаю трассировку, я вижу, что dig действительно получает запись A, которую я ищу.

Вот что я нашел из раскопок:

ubuntu@i-047646595b6398229:~$ dig svr-01.dc01.int.example.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> svr-01.dc01.int.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49045
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;svr-01.dc01.int.example.com.   IN  A

;; Query time: 24 msec
;; SERVER: 10.170.160.130#53(10.170.160.130)
;; WHEN: Fri Nov 10 12:46:51 UTC 2017
;; MSG SIZE  rcvd: 56

Вот след:

ubuntu@i-047646595b6398229:~$ dig +trace svr-01.dc01.int.example.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +trace svr-01.dc01.int.example.com
;; global options: +cmd
.           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.
.           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.
;; Received 239 bytes from 10.170.160.130#53(10.170.160.130) in 0 ms

cc.         172800  IN  NS  ac1.nstld.com.
cc.         172800  IN  NS  ac2.nstld.com.
cc.         172800  IN  NS  ac3.nstld.com.
cc.         172800  IN  NS  ac4.nstld.com.
cc.         86400   IN  DS  519 8 1 7285EF05E1B4E679D4F072EEA9B00953E01F3AE2
cc.         86400   IN  DS  519 8 2 E1EC6495ABD34562E6F433DEE201E6C6A52CB10AF69C04D675DA692D 2D566897
cc.         86400   IN  RRSIG   DS 8 1 86400 20171123050000 20171110040000 46809 . kKdntWttTE8k6NOuX+WI2evpRSYwf96pIjsY+tQQkJQm8hrlYQ+uVc8k FJJFott3Ay5nEsDF4lgHD2IRhFwa4MeoFhwlcf7JsrGhZim6l4YMAMP9 FtxfGAJZH7tpzWAyjlL1zxoWoKlCaaAhrOins/zjrhM2vtlrc8LUGgTH Jvx1yQJlGxRShqeH+0CwGtIVeTiC9ZCT1FjW8OHKrzz9NmzrlN8HkB8n rx8zg+Ou7V5dxHwfJkAjxJtxNzIKqIBFoEjEHiG4FSjOmvpA0dsOwNCp yPhKlKM04dNtqDOLcO4b4Nk0Od1HSkLlSxpL66AG2Z0Wa8yW/ie+VC6e O24rvg==
;; Received 684 bytes from 198.41.0.4#53(A.ROOT-SERVERS.NET) in 5 ms

example.com.        172800  IN  NS  ns-1534.awsdns-63.org.
example.com.        172800  IN  NS  ns-1596.awsdns-07.co.uk.
example.com.        172800  IN  NS  ns-892.awsdns-47.net.
example.com.        172800  IN  NS  ns-128.awsdns-16.com.
RQGAP5UF6Q1NGVCKFNO8RANVDN5ILRIN.cc. 86400 IN NSEC3 1 1 0 - RRSUVU26OKK7UMMCD1PS20R9D7CKMGL2 NS SOA RRSIG DNSKEY NSEC3PARAM
RQGAP5UF6Q1NGVCKFNO8RANVDN5ILRIN.cc. 86400 IN RRSIG NSEC3 8 2 86400 20171117090422 20171110090422 17360 cc. VWYfVQ17+bTxzgoOvbbxNf9i182V7YGSdRQAtHQ8UW6lGzhZblakIIDt i+scqEtYIJ71zpBZLDBKKh4Um6FU+d4W6dzCK4k/MmG7i3wDd2p5IfRr +Jb2V37ZRIMRXywba5ncbAvzwkkYHwdAp9H2+8pjCnK4yRJiT5LLL7jD lUo=
FTN65A4J3744VIBAAS976RBJOD2EV3AV.cc. 86400 IN NSEC3 1 1 0 - G012ESBJCNN8FQ9BK2UCR2M7LD2LINS8 NS DS RRSIG
FTN65A4J3744VIBAAS976RBJOD2EV3AV.cc. 86400 IN RRSIG NSEC3 8 2 86400 20171116174512 20171109174512 17360 cc. bL8TB0XAWA1mShJQ6Ln8KRjkQL9+08h2WeFoNFYAUinu3jdKuDcoOXbr 1ouyeW6KaETy0VHJc6p5RMGPbc6UHDwDtt1daDCWTv2YksfdD8wXDdbG lFzwC7pAzZemL2NCucaiJclFiH7E93Pb6eDUp2YgHMygQrJo52ogNbm1 P70=
;; Received 679 bytes from 192.42.173.30#53(ac1.nstld.com) in 2 ms

dc01.int.example.com.   30  IN  NS  192.168.111.201.
dc01.int.example.com.   30  IN  NS  192.168.111.202.
;; Received 114 bytes from 205.251.192.128#53(ns-128.awsdns-16.com) in 8 ms

svr-01.dc01.int.example.com. 300 IN A   192.168.111.1
int.example.com.    300 IN  NS  dns-01.dc01.int.example.com.
int.example.com.    300 IN  NS  dns-02.dc01.int.example.com.
;; Received 146 bytes from 192.168.111.201#53(192.168.111.201) in 14 ms
Как вы можете видеть выше, запись А, которую я ищу, находится там: svr-01.dc01.int.example.com. 300 в 192.168.111.1

Просто чтобы показать, что я могу запросить эти внутренние серверы напрямую:

ubuntu@i-047646595b6398229:~$ dig any svr-01.dc01.int.example.com @192.168.111.202

; <<>> DiG 9.10.3-P4-Ubuntu <<>> any svr-01.dc01.int.example.com @192.168.111.202
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32446
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;svr-01.dc01.int.example.com.   IN  ANY

;; ANSWER SECTION:
svr-01.dc01.int.example.com. 300 IN A   192.168.111.1

;; AUTHORITY SECTION:
int.example.com.    300 IN  NS  dns-02.dc01.int.example.com.
int.example.com.    300 IN  NS  dns-01.dc01.int.example.com.

;; ADDITIONAL SECTION:
dns-01.dc01.int.example.com. 300 IN A   192.168.111.201
dns-02.dc01.int.example.com. 300 IN A   192.168.111.202

;; Query time: 14 msec
;; SERVER: 192.168.111.202#53(192.168.111.202)
;; WHEN: Fri Nov 10 12:48:50 UTC 2017
;; MSG SIZE  rcvd: 146

ubuntu@i-047646595b6398229:~$

Запрос aws напрямую:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> svr-01.dc01.int.example.com @10.170.160.130
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60483
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;svr-01.dc01.int.example.com.   IN  A

;; Query time: 1482 msec
;; SERVER: 10.170.160.130#53(10.170.160.130)
;; WHEN: Fri Nov 10 15:29:33 UTC 2017
;; MSG SIZE  rcvd: 56
1 2

1 ответ:

Для того чтобы AWS recursive resolver мог следовать за вашим делегированием, он должен иметь доступ к вашим полномочным DNS-серверам для поддомена, что он не может сделать... потому что они недоступны через общедоступный Интернет.

По той же причине 8.8.8.8 также не может разрешить запрос. Когда вы просите рекурсивный распознаватель выполнить поиск, он должен быть в состоянии пройти весь путь, иначе он не работает.

Использование dig +trace успешно, потому что машина с dig может доступ к частным серверам, на которых он работает.

Здесь нет решения, которое приходит на ум - VPC resolver предполагает, что все (кроме частных размещенных зон) доступно через Интернет.

Обратите внимание, что эта проблема не связана с тем, что родительская зона размещается в маршруте 53. Проблема будет одинаковой независимо от того, где размещена родительская зона.