Receber uma zona como secundária

O nome tem que ser idêntico ao do primário. Uma letra diferente e a transferência é recusada do outro lado.

Trocar o tipo reescreve o formulário: some o campo de quem pode transferir — que só faz sentido em primária — e aparecem o endereço do primário e a chave de transferência.

Uma zona secundária não se edita aqui. O conteúdo chega por transferência; editar é no primário.

O endereço do servidor que hospeda a zona como primária.

Duas coisas precisam ser verdade do outro lado, e nenhuma delas é configurada aqui: o primário precisa autorizar este endereço a transferir a zona, e a porta 53 precisa estar alcançável entre os dois. Se a zona nunca sincronizar, é quase sempre uma dessas duas.

Num cluster, o campo já vem preenchido com os servidores parceiros.

Opcional — e obrigatório quando o primário exige autenticação na transferência.

O segredo precisa ser exatamente o mesmo que o primário exibiu ao ativar a chave. É um segredo compartilhado: copiado errado, a transferência é recusada sem explicação útil.

A zona é criada, mas ainda vazia. Ela só ganha conteúdo na primeira transferência bem-sucedida.

Zona secundária recém-criada com zero registros é o estado esperado nos primeiros instantes — e também o sintoma de transferência bloqueada. A diferença aparece no próximo passo.

Sincronizar do Master puxa a zona na hora, em vez de esperar o ciclo normal. É o teste definitivo de que a autorização e a conectividade estão certas.

Depois de sincronizar, confira o número de série: ele tem que bater com o do primário. Série diferente significa que a réplica está atrasada em relação à origem.