Mam dwa konta AWS. Konto główne z example.com
Strefą hostowaną zawiera szereg zestawów rekordów (np. Api.example.com i kibana.example.com).
Drugie konto będzie zarządzane testing.example.com
jako Strefa hostowana z tym samym zestawem rekordów (tj. Api.testing.example.com i kibana.testing.example.com).
Jak mam powiedzieć, aby konto główne skierowało żądania dotyczące .testing.example.com
konta podrzędnego. Nie chcę zmieniać konta głównego, ponieważ chcę używać tych samych szablonów Cloud Formation zarówno w trybie „Na żywo”, jak i „Test”.
Ustawiłem oba jak wyżej i to nie działa ( api.testing.example.com
nie rozwiązuje). Próbowałem również ustawić rekord test.example.com ns na koncie głównym na rekord określony w koncie podrzędnym (1). Niestety nie zrobiłem tego wcześniej, a wyszukiwania w Google nic nie zwracają.
1) Zepsułem to i to jest odpowiedź. Patrz poniżej.
example.com
lub*.example.com
jako strefa? Nie sądzę, że możesz mieć*.example.com
nazwę strefy, prawda? Czy możesz podać nam rzeczywiste nazwy FQDN w grze?dig ns testing.example.com
i potwierdź, że zestaw serwerów nazw pochodzi ze strefy konta podrzędnego. Następniedig @one.of.those.nameservers api.testing.example.com
i oceń wynik.Odpowiedzi:
Żądania są przekazywane, a nie wypychane, ale można osiągnąć pożądany wynik, delegując poddomenę do innego zestawu serwerów Route 53 niż tych, które obsługują strefę nadrzędną.
Spójrz na nową strefę hostowaną utworzoną do testowania.example.com. Może to być na tym samym koncie AWS, innym koncie AWS ... dowolnym koncie AWS. Nie ma tu nic związanego z „kontem”. Używa standardowej konfiguracji DNS. Cały DNS jest hierarchią. Globalny katalog główny może powiedzieć ci, gdzie znaleźć
com
, acom
serwery mogą ci powiedzieć, gdzie znaleźćexample.com
, i nie jest niczym innym,example.com
jak powiedzieć ci, gdzie znaleźć,testing.example.com
zamiast dać ci bezpośrednią odpowiedź.Zwróć uwagę na 4 serwery nazw, które Route 53 przypisała do strefy hostowanej test.example.com. Sprawdź, czy wszystkie różnią się od przypisanych do strefy hostowanej w example.com. (Aby którykolwiek z nich był taki sam, powinno być niemożliwe, ale sprawdź to.)
Teraz z powrotem w strefie example.com utwórz nowy rekord zasobu z nazwą hosta
testing
, używając typu rekorduNS
, i wprowadź 4 serwery nazw, do których przypisano trasę 53testing.example.com
, w polu poniżej.Teraz, gdy żądanie dotyczące test.example.com i cokolwiek poniżej dotrze do jednego z serwerów Route 53 obsługujących example.com, odpowiedź nie będzie odpowiedzią z test.example.com - odpowiedź dostarczy wnioskodawcy 4 rekordy NS związane z testowaniem.example.com i odpowiedź równoważną z „Nie wiem, ale spróbuj zapytać jednego z tych facetów”.
Tak to się robi.
źródło
testing.example.com
rekord na koncie głównym o wartości NS na koncie podrzędnym), jednak to nie działa (tj.nslookup kibana.example.com
Działa zgodnie z oczekiwaniami, alenslookup kibana.testing.example.com Server: 8.8.8.8 Address: 8.8.8.8#53 ** server can't find kibana.testing.example.com: NXDOMAIN
)dig ns testing.example.com
wynik?Myślę, że musisz utworzyć
testing.example.com
rekord na głównym koncie (Parent) wexample.com
domenie. A jeśli używasz ELB, skopiuj punkt końcowy ELB dlatesting
konta podrzędnego lub może to być Publiczny adres IP przypisany dotesting
domeny na Twoim koncie podrzędnym i zaktualizuj go na trasie konta nadrzędnego 53. Myślę, że punkt końcowy ELB ułatwiłby rozpoznanie adresu zamiast używania dedykowanego Elastyczne IP. Musisz także utworzyć wszystkie subdomenytesting
na koncie nadrzędnym. Sugeruję użycie punktów końcowych ELB na koncie podrzędnym dla wszystkich poddomentesting
witryny. Upewnij się, że wszystkie punkty końcowe ELB muszą mieć schemat jakinternet-facing
w konsoli aws.źródło
testing
na koncie podrzędnym, jeśli jest poprawnie skonfigurowane.