Atualmente a AWS acabou virando foco do meu trabalho. Tanto aqui, nos meus projetos pessoais, quanto também no trabalho.
E um dos desafios era permitir que zonas públicas fossem atualizadas por contas diferentes. Ou seja, explicando. Tenho uma conta A e uma conta B. A conta A possui a zona meudominio.com e eu preciso que a conta B atualize esta zona também.
Em pesquisas notei que a solução mais indicada é delegar subzonas entre contas.
Bonito ? Não … mas é aquela. Funciona. Pode ser até aque exista um hack diferente ( comentários abertos aqui para quem conhecer algo mais bonito que isto ) mas este foi o que eu encontrei, e, no fim, resolveu.
O processso é o que qualquer SysAdmin já conhece. No caso do Bind teríamos o seguite modelo. Uma zona principal ( que o pessoal que mexe com Amazon gosta de chamar de HostZone ) e uma subzona com um subdomío. Ou seja, na zona principal teríamos o “meudominio.com” e a subzona test.meudominio.com.
No Bind o processo seria feito criando um outro registro SOA dentro da zona principal.
; zone fragment for 'zone name' example.com
; name servers in the same zone
$TTL 2d ; zone default TT = 2 days
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 ; serial number
2h ; refresh = 2 hours
15M ; update retry = 15 minutes
3W12h ; expiry = 3 weeks + 12 hours
2h20M ; minimum = 2 hours + 20 minutes
)
; main domain name servers
IN NS ns1.example.com.
IN NS ns2.example.com.
; mail servers for main domain
IN MX 10 mail.example.com.
; A records for name servers above
ns1 IN A 192.168.0.3
ns2 IN A 192.168.0.4
; A record for mail servers above
mail IN A 192.168.0.5
; other domain level hosts and services
bill IN A 192.168.0.6
....
; sub-domain definitions
$ORIGIN us.example.com.
IN MX 10 mail
; record above uses blank substitution
; and could have been written as
; us.example.com. IN MX 10 mail.us.example.com.
; OR (using @ substitution)
; @ IN MX 10 mail
; A record for subdomain mail server
mail IN A 10.10.0.28
; the record above could have been written as
; mail.us.example.com. A 10.10.0.28 if it's less confusing
ftp IN A 10.10.0.29
; the record above could have been written as
; ftp.us.example.com. A 10.10.0.29 if it's less confusing
....
; other subdomain definitions as required
; WARNING: $ORIGIN us.example.com. affects all subsequent RRs until
; either another $ORIGIN or EOF
; adding $ORIGIN example.com. resets the $ORIGIN to the base domain name
Infelizmente não sei por qual motivo o Route 53 apresenta um pequeno probleminha. Não é possível criar um novo registro SOA mas, ao mesmo tempo é possível criar um registro NS. E neste caso conseguimos fazer de um jeito bem fácil, conforme pode ser visto no post que eu até usei como referência.
Vamos pegar uma hostzone de nome zeruela.com e eu quero ter uma subzona de nome stage.zeruela.com .
Numa segunda conta criamos a subzona stage.zeruela.com.br .
E aqui iremos pegar os 4 nameservers que foram atribuidos a esta zona.
E na zona principal iremos criar um novo registro NS com o subdominio stage.zeruela.com .
E a partir daqui a segunda conta consegue atualizar este domínio já que ele está hospeaddo nela.
E isto pode ser repetido em quantas contas você quiser para o mesmo domínio.
Famosa dica simples que, no fim, custou um pouco de pesquisa pois sempre precisamos argumentar com documentos quando levamos algo a produção, né ?