Eu tenho duas contas da AWS. A conta mestre com example.comuma zona hospedada, tem vários conjuntos de registros (ou seja, api.example.com e kibana.example.com).
Uma segunda conta será gerenciada testing.example.comcomo uma zona hospedada, com o mesmo conjunto de conjuntos de registros (ou seja, api.testing.example.com e kibana.testing.example.com).
Como dizer à conta principal para encaminhar as solicitações de .testing.example.combaixa para a conta secundária. Não quero alterar a conta mestra, pois quero usar os mesmos modelos do Cloud Formation tanto em 'Ao vivo' quanto em 'Teste'.
Configurei os dois conforme acima e não funciona ( api.testing.example.comnão resolve). Também tentei definir o registro ns testing.example.com na conta mestre para aquele especificado na conta filha (1). Infelizmente, isso não é algo que eu fiz antes e as pesquisas do Google não estão retornando nada.
1) Eu estraguei tudo, e esta é a resposta. Veja abaixo.
As solicitações são encaminhadas, não enviadas, mas você pode obter o resultado desejado delegando o subdomínio a um conjunto diferente de servidores Route 53 daqueles que hospedam a zona pai.
Veja a nova zona hospedada que você criou para testing.example.com. Isso pode estar na mesma conta da AWS, em uma conta da AWS diferente... em qualquer conta da AWS. Não há nada aqui relacionado a "conta". Isso usa a configuração de DNS padrão. Todo o DNS é uma hierarquia. A raiz global pode dizer onde encontrar
com, e oscomservidores podem dizer onde encontrarexample.com, e não é nada materialmente diferenteexample.comdizer onde encontrartesting.example.com, em vez de fornecer uma resposta direta.Observe os 4 servidores de nome que o Route 53 atribuiu à zona hospedada testing.example.com. Verifique se todos são diferentes daqueles atribuídos à zona hospedada example.com. (Para qualquer um deles ser o mesmo deve ser impossível, mas verifique isso.)
Agora, de volta à zona example.com, crie um novo registro de recurso, com hostname
testing, usando o tipo de registroNS, e insira os 4 servidores de nomes que o Route 53 atribuiu atesting.example.com, na caixa abaixo.Agora, quando uma solicitação para testing.example.com e qualquer coisa abaixo dela chegar a um dos servidores da Rota 53 que lidam com example.com, a resposta não será a resposta de testing.example.com -- a resposta fornecerá ao solicitante os 4 registros NS associados a testing.example.com e uma resposta equivalente a "Não sei, mas tente perguntar a um desses caras".
É assim que se faz.
Acho que você precisa criar um
testing.example.comregistro na conta principal (pai) noexample.comdomínio. E se você estiver usando o ELB, copie o endpoint ELB paratestinga conta filha ou pode ser um IP público atribuído aotestingdomínio em sua conta filha e atualize-o na rota 53 da conta pai. Acho que o endpoint ELB facilitaria a resolução do endereço em vez de usar dedicado IP elástico. Você também precisaria criar todos os subdomínios datestingconta principal. Sugiro usar endpoints ELB na conta filha para todos os subdomínios dotestingsite. Certifique-se de que todo o endpoint ELB deve ter esquema comointernet-facingno console aws.Aqui está o processo que foi mencionado na AWS para o mesmo:
Tráfego de roteamento para subdomínios - https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-routing-traffic-for-subdomains.html