DNS “visualizações” e controle de transferências de zona com TSIG

Question

Ligação em execução 9.8.2. Eu configurei com êxito as chaves TSIG para "visualizações" usando um par mestre / servidor de DNS. As transferências de zona estão funcionando conforme o esperado entre os dois servidores para cada exibição. Antes de irmos viver em produção com isso eu preciso de alguns esclarecimentos sobre algumas coisas. Nossos servidores prod também estão permitindo transferências de zona para alguns outros servidores além do servidor escravo. Temos uma configuração acl parecida com esta:

other_xfer_allowed {
x.x.x.x; // This is our Secondary DNS server
127.0.0.1; // localhost can make zone transfers
x.x.x.x/24; // Corporate server farm range is allowed to make zone-transfers
x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
}; // end of "other_xfer_allowed" ACL

E na declaração "permitir transferência", incluímos essa ACL. Minha pergunta é:

Agora que estamos usando o TSIG, precisaremos obter com os administradores de todos esses outros servidores e fornecer a eles minha chave TSIG para que eles possam solicitar transferências de zona? Eu acho que algo como isso precisa ser feito, uma vez que foi necessário para ser configurado no servidor slave, mas não tenho certeza.

Em seguida,

Eu configurei as visualizações de modo que os clientes na rede "interna", ao solicitar um registro, fossem apresentados com registros diferentes dos clientes externos. E no momento há apenas uma zona que é necessária para ter registros diferentes. No entanto, entendo que, como as visualizações são baseadas em IPs de origem, se eu incluísse APENAS aquela zona na minha visualização "interna", se um registro fosse solicitado para outra zona desse mesmo IP, eles provavelmente obteriam um nxdomain resposta desde que o IP está limitado a essa visão.

Então, minha pergunta é, será necessário incluir todas as zonas em ambas as visualizações para que todos os clientes possam obter resultados, mesmo que eu tenha apenas (no momento) uma zona que aponte para dois arquivos de zona diferentes? Todos os outros em ambos os pontos de vista apontariam para o mesmo arquivo de zona, a menos, é claro, que haja outra zona de que precisamos para apresentar uma visão diferente para os clientes internos.

Agora, última pergunta.

Eu tenho uma preocupação com a instrução allow-query. Em nosso servidor de produção, temos uma lista de ACLs que chamamos de "permitido". Temos uma instrução de consulta permitida nas opções globais para permitir apenas consultas de IPs na ACL permitida. No entanto, cada uma de nossas entradas de zona no arquivo conf também possui uma instrução "allow-query {any;}; Isso não prejudica a finalidade de ter uma ACL" permitida "para consultas? Esse design é ruim? a declaração de zona tem precedência sobre a declaração global?

    

Answer 1

Now that we are using TSIG, will I need to get with the admins of all these other servers and provide them my TSIG key so they can request zone transfers? I would think something like that needs to be done since it was required to be configured on slave server, but I am not sure.

Primeiro de tudo, sobre "fornecer a minha chave TSIG": Não, não faz muito sentido apenas gerar uma única chave e compartilhá-la com todos os envolvidos na sua configuração.
Eu diria que criar uma chave por festa, você pode ter quantas chaves quiser, afinal. Dessa forma, você pode conceder acesso diferente a diferentes partes e revogar o acesso de uma das partes sem revogar o acesso de todos.

Além disso, usar TSIG para algumas coisas não implica necessariamente o uso de TSIG para todas as coisas (embora geralmente seja preferível), é possível misturar controle de acesso baseado em IP e chave se isso funcionar para o seu cenário.

So, my question is, will I need to include all zones in both views so that all clients can get results, even though I would only have (at the moment) one zone that points to two different zone files? All others in both views would point to the same zone file, unless of course there is another zone we need to present a different view to for internal clients.

Toda consulta atingirá apenas uma visualização (a primeira exibição correspondente). A implicação é que, se os dados não estiverem disponíveis na exibição que um cliente atinge com suas consultas, seja em uma zona nessa exibição ou por recursão (se a recursão estiver disponível para o cliente e eles o solicitarem), eles não poderão obter isso dados.

É perfeitamente possível que você precise de mais zonas duplicadas entre as visualizações.

I have a concern about the allow-query statement. On our production server we have an ACL list we'll call it "allowed". We have an allow query statement in the global options to only allow queries from IP's in the allowed ACL. However every one of our zone entries in the conf file also has an "allow-query { any; }; statement. Doesn't that defeat the purpose of have an "allowed" ACL for queries? Is this bad design? Doesn't the zone statement take precedence over the global statement?

Sim, um allow-query especificado em zone substituirá o valor global allow-query . Para consultas que correspondem às suas zonas, isso significa que a configuração global não é usada, no entanto, se a recursão estiver ativada, você também estará lidando com consultas que não correspondem a nenhuma das suas zonas.

Consulte as allow-* configurações no manual como essas configurações interagem.