Configurar e testar DNS Host Entries na Sophos Firewall

Uma DNS Host Entry permite que a Sophos Firewall responda diretamente a um hostname específico com um endereço IP configurado. É adequada para alguns sistemas internos fixos, como uma appliance, um serviço de gestão ou um nome de servidor que a própria firewall tem de resolver.

Uma resposta local correspondente evita uma consulta adicional ao DNS autoritativo para esse pedido e pode acelerar a resolução. Não garante um tempo de resposta específico nem ajuda um cliente cuja consulta não passa pelo resolver da firewall.

Os campos Host Entry estão documentados para o SFOS 22.0 e 23.0; isto não comprova testes num build específico. O SFOS 23 distingue DNS não cifrado, DNS over HTTPS (DoH) e DNS Protection para a resolução externa. O artigo sobre DNS Request Routes explica a seleção global do resolvedor, a obtenção de DNS por DHCP/PPPoE e a distinção entre DNS Protection tradicional e o caminho integrado do SFOS 23. Não é necessário reconstruir a configuração global para um único nome local.

A entrada só produz efeito se o pedido DNS chegar realmente à firewall. Se um cliente utilizar um controlador de domínio, um resolvedor público ou DNS over HTTPS, a firewall não vê esse pedido como resolvedor DNS. Uma DNS Host Entry também não substitui um objeto de regra, o routing, o NAT ou uma regra de firewall.

⚠️ Publish on WAN permanece desativado para entradas internas. Uma publicação pública exige um design DNS autoritativo deliberado, registos NS adequados, Device Access estritamente limitado e um teste negativo de recursão. Uma autorização DNS ACL a partir da WAN, por si só, não justifica a exposição pública do serviço DNS.

DNS Host Entry em oito passos

1. Confirmar que o nome é estático e que não é necessário encaminhar uma zona DNS interna completa.
2. Verificar se os clientes afetados utilizam realmente a Sophos Firewall como servidor DNS.
3. Documentar o FQDN, o endereço de destino, a versão IP, o TTL e um registo PTR opcional.
4. Introduzir o nome e o endereço em Network > DNS > DNS host entry > Add.
5. Manter Publish on WAN desativado para uma entrada interna.
6. Verificar a perspetiva da firewall em Network > DNS > Test name lookup (SFOS 22) / Test name resolution (SFOS 23).
7. A partir do cliente, consultar explicitamente o IP da firewall e testar a resolução direta e, se necessário, a resolução inversa.
8. Só depois testar a aplicação real e documentar a entrada juntamente com as suas dependências.

Quando uma DNS Host Entry é adequada

Uma DNS Host Entry é adequada para um único nome estável cuja resposta deve ser mantida diretamente na firewall. Exemplos típicos:

• uma appliance interna sem um registo DNS próprio;
• um FQDN de gestão fixo para LDAP, RADIUS ou outro serviço;
• um único hostname para uma migração controlada;
• um serviço público com inbound DNS load balancing deliberadamente planeado em vários endereços WAN.

Para um domínio completo, Active Directory ou zonas internas mantidas dinamicamente, uma DNS Request Route é mais adequada. Encaminha a zona para o servidor DNS responsável em vez de manter cada nome individualmente na firewall.

Um IP Host ou FQDN Host também tem uma função diferente. Estes objetos são utilizados em regras de firewall e NAT; não respondem ao pedido DNS de um cliente. Utilizar corretamente IP Hosts, Services e Groups explica os tipos de objetos.

Uma configuração de Dynamic DNS, por outro lado, atualiza um nome num fornecedor externo quando um endereço WAN muda. O procedimento completo encontra-se em Configurar Dynamic DNS na Sophos Firewall.

O SFOS suporta os tipos de registo A, AAAA e PTR para DNS Host Entries. Por isso, a função não é um servidor DNS autoritativo completo para CNAME, MX, TXT ou SRV. O inbound load balancing de um nome suporta até oito endereços; a firewall suporta, no total, um máximo de 1024 DNS Host Entries.

Caminhos e âmbito da resolução DNS

Nos pedidos tratados pela própria firewall, aplicam-se as seguintes configurações:

• Se o nome pedido corresponder a uma DNS host entry, a firewall responde com o endereço aí guardado.
• Se corresponder uma DNS request route, após uma pesquisa sem êxito na cache, a firewall consulta os respetivos Target servers pela ordem configurada. Para esse nome, não recorre aos forwarders nem aos servidores raiz.
• Sem uma entrada local ou Request Route correspondente, utiliza os servidores especificados em DNS configuration. Os servidores estáticos são consultados pela ordem definida até chegar uma resposta. NXDOMAIN já é uma resposta válida, pelo que o servidor seguinte não é consultado.

A ajuda do SFOS 22 descreve separadamente a correspondência de Host Entries e Request Routes, mas não especifica o resultado quando o mesmo nome corresponde a ambas. Deve evitar-se esta sobreposição: manter a Host Entry fora de uma zona encaminhada ou remover a entrada local duplicada. Em seguida, deve consultar-se explicitamente o IP da firewall para confirmar a resposta pretendida.

Estes caminhos de resolução só se aplicam quando a firewall é o resolvedor do pedido. Um cliente que utilize diretamente um controlador de domínio, um resolvedor público ou DNS over HTTPS ignora estas entradas. Em Administration > Device access, o DNS também tem de ser permitido para a zona de origem ou através de uma Local Service ACL Exception adequada; uma regra de firewall normal não controla o acesso a este serviço local.

Os servidores DNS configurados têm prioridade sobre os servidores raiz na resolução DNS geral através do IP de uma interface da firewall. Isto não garante que todos os pedidos sem êxito sejam resolvidos através dos servidores raiz. Os pedidos que correspondem a uma Request Route continuam a ser dirigidos aos Target Servers definidos.

Exemplo e valores a substituir

O exemplo representa um único servidor de aplicações interno:

• Hostname: app01.corp.example
• Endereço IPv4: 192.0.2.20
• Rede de clientes: 10.20.30.0/24
• IP da firewall como servidor DNS: 10.20.30.1
• Cliente de teste: 10.20.30.50
• TTL: 300 segundos
• Publish on WAN: desativado
• Reverse DNS: opcionalmente ativado

A zona .example e a rede 192.0.2.0/24 estão reservadas para documentação. Num ambiente de produção, o FQDN, o endereço, a rede de clientes e o IP do resolvedor são substituídos pelos valores reais. O nome deve corresponder à estratégia interna de nomes e não pode substituir involuntariamente uma zona autoritativa existente.

O TTL de 300 segundos é um valor de exemplo controlado para testes e migrações, não uma recomendação universal. Um TTL curto acelera alterações planeadas, mas gera mais pedidos DNS. Um TTL longo reduz os pedidos, mas mantém respostas antigas durante mais tempo nas caches depois de uma alteração.

Criar a DNS Host Entry

Em Network > DNS, deslocar-se até DNS host entry e selecionar Add:

1. Introduzir app01.corp.example em Host/Domain name.
2. Utilizar um endereço IP como Entry type.
3. Introduzir 192.0.2.20 em IP address.
4. Introduzir 300 em Time-to-live.
5. Não tratar Weight como uma ferramenta de balanceamento de carga quando só existe um endereço.
6. Manter Publish on WAN desativado.
7. Ativar Add reverse DNS lookup for this host entry apenas se a firewall também tiver de devolver uma resposta PTR para este endereço.
8. Guardar com Save.

Para um endereço IPv4, a firewall devolve uma resposta A; para um endereço IPv6, devolve uma resposta AAAA. A pesquisa inversa opcional volta a associar o endereço ao nome como PTR. No entanto, não cria um registo PTR num controlador de domínio ou num servidor DNS externo.

Se vários hostnames apontarem para o mesmo endereço IP, apenas um deles pode servir como destino inverso. Antes de ativar a opção, deve ficar claro qual é o nome esperado como resposta PTR canónica.

Utilizar uma interface em vez de um endereço fixo

Como Entry Type, é possível selecionar uma interface em vez de um IP fixo. Esta opção é adequada quando a resposta deve seguir deliberadamente o endereço atual dessa interface, por exemplo num design Multi-WAN público planeado.

A seleção de uma interface não substitui a verificação do caminho WAN real. Após uma mudança de endereço, uma troca de link ou um failover HA, é necessário voltar a testar a resposta DNS, o serviço acessível e o caminho de retorno com uma nova ligação.

Testar a resolução na firewall e no cliente

Primeiro, em Network > DNS, utiliza-se Test name lookup (SFOS 22) / Test name resolution (SFOS 23) para verificar se a firewall devolve o endereço esperado para app01.corp.example. Diagnostics > Tools > Name lookup (SFOS 22) consulta, em vez disso, um DNS server IP selecionado; Lookup using all configured servers compara os servidores DNS configurados e os respetivos tempos de resposta. Esta ferramenta serve apenas para comparar servidores upstream, não para provar que uma Host Entry local ou uma Request Route encontrou correspondência. Se Reverse DNS estiver ativado, consulta-se também 192.0.2.20.

Este teste confirma apenas a perspetiva do resolvedor da firewall. Em seguida, o cliente afetado tem de consultar explicitamente o IP da firewall 10.20.30.1.

No SFOS 23, a secção de diagnóstico é DNS lookup, com Hostname or IP address, DNS server IP address e All configured servers. Custom DNS server e Custom DoH server consultam o IP do servidor indicado; DNS Protection só está disponível se estiver ativado em Network > DNS. Para um nome de teste interno, selecionar apenas um resolvedor interno autorizado para não expor o nome a um serviço DNS ou DoH público. Estas opções de diagnóstico não comprovam que uma entrada local tenha encontrado correspondência; continua a ser necessária a consulta explícita do cliente descrita abaixo.

Para o teste do SFOS 23 em Network > DNS > Test name resolution, introduzir o FQDN ou o endereço em Hostname or IP address e selecionar Test connection. O resultado mostra o servidor DNS utilizado, o protocolo, o estado da resolução e os tempos de resposta; comparar estes dados com o caminho de resolução previsto. O teste do cliente continua a ser um passo separado:

Windows:

nslookup app01.corp.example 10.20.30.1
nslookup 192.0.2.20 10.20.30.1

Linux ou macOS:

dig @10.20.30.1 app01.corp.example A
dig @10.20.30.1 -x 192.0.2.20

A resposta tem de conter o registo esperado, o endereço correto e, na pesquisa inversa, o nome previsto. Em seguida, testa-se a aplicação através do FQDN. Uma resposta DNS correta ainda não prova que o routing, a regra de firewall, o NAT, o certificado TLS e o serviço funcionam.

Se não for claro se o pedido chega à firewall, pode utilizar-se um filtro restrito em Diagnostics > Packet capture, como:

host 10.20.30.50 and port 53

O pedido e a resposta têm de estar visíveis na interface esperada. Packet Capture na Sophos Firewall explica em detalhe a captura e análise seguras.

Para entregar dados ao suporte ou comparar o estado antes e depois da alteração, também se pode descarregar dnsd.log em Diagnostics > Tools > Troubleshooting logs. Um Consolidated troubleshooting report (CTR) contém ainda dados de estado e de logs. Como estes ficheiros podem incluir detalhes da configuração e do ambiente, só devem ser partilhados através de um canal de suporte seguro.

Utilizar vários endereços e pesos deliberadamente

Uma DNS Host Entry pode conter até oito endereços. Esta função destina-se a inbound DNS load balancing ou failover através de vários links WAN, não a uma coleção aleatória de servidores internos.

⚠️ Não combinar pesos e DNAT sem esclarecer o design: A ajuda Host Entry descreve Weight em relação ao WAN link manager, enquanto o fluxo Multi-WAN associa a resposta à interface WAN de entrada. A ajuda DNAT também proíbe uma regra DNAT juntamente com weighted load balancing para a mesma DNS Host Entry. Estas indicações não comprovam uma proporção específica de respostas DNS nem o funcionamento de um design DNAT combinado. Se o serviço público depender desta combinação, parar antes da publicação na WAN e esclarecer o design concreto para a versão instalada; não presumir que outros pesos constituem uma solução alternativa.

Para dois endereços WAN, mantém-se o mesmo nome numa única Host Entry: introduzir, por exemplo, www.example.com em Host/Domain name e 192.0.2.10 como primeira IP address; depois, utilizar Add no formulário para acrescentar um segundo endereço e introduzir 198.51.100.10. São endereços de documentação que devem ser substituídos pelos endereços WAN reais. Ativar Publish on WAN para ambos os endereços previstos apenas quando estiverem cumpridos os requisitos da secção seguinte e guardar com Save. Dois hostnames diferentes não proporcionariam balanceamento de carga para o mesmo serviço.

No fluxo Multi-WAN documentado, o resolvedor externo segue a delegação NS e consulta a firewall através de um link WAN ativo. A firewall devolve o endereço WAN da interface pela qual chegou esse pedido, e o resolvedor transmite esse endereço ao cliente. O acesso posterior à aplicação constitui um fluxo de dados separado. Durante a validação, consultar por isso ambos os caminhos WAN separadamente e comparar os endereços devolvidos; após uma falha de link, efetuar um novo pedido DNS. Isto não elimina as respostas já em cache antes de expirar o respetivo TTL.

Weight é o peso relativo do link em comparação com os restantes links no WAN link manager. Não é um Health Check da aplicação. Durante a validação, os novos pedidos DNS externos só devem devolver endereços WAN ativos; em seguida, deve testar-se uma nova ligação à aplicação para cada endereço devolvido. Uma resposta DNS, por si só, não confirma a disponibilidade do serviço publicado nem um caminho DNAT e de retorno correto.

Vários endereços não se tornam automaticamente num Health Check geral para aplicações internas. Num design público, a Sophos documenta failover para uma interface inacessível ou avariada. Isto não garante que uma interface WAN acessível também forneça corretamente o serviço de aplicação atrás dela.

Segundo a Sophos, uma regra DNAT e o weighted load balancing não podem ser configurados simultaneamente para a mesma DNS Host Entry. A publicação requer, por isso, um design coerente de resposta DNS, endereço WAN, DNAT, regra de firewall, TLS e caminho de retorno. Publicar um servidor através de DNAT explica separadamente o caminho dos dados.

Utilizar Publish on WAN apenas em designs autoritativos

Publish on WAN por si só não é suficiente para uma resposta pública. Para que a Sophos Firewall responda como Name Server de um serviço publicado, a zona autoritativa tem de ser delegada para nomes de servidores DNS cujos registos A/AAAA ou glue apontem para os endereços WAN previstos.

São também necessários os seguintes elementos:

1. O domínio público e a zona DNS responsável estão inequivocamente documentados.
2. A delegação NS e os registos de endereço ou glue associados conduzem aos endereços WAN previstos.
3. Em Administration > Device access, o DNS só é permitido através da zona WAN necessária ou de uma Local Service ACL Exception restrita.
4. Publish on WAN está ativado apenas nos endereços previstos.
5. O nome publicado é testado com êxito a partir de um resolvedor externo.
6. Os nomes não autoritativos e os pedidos recursivos são testados negativamente a partir do exterior.
7. O DNAT, a regra de firewall, o certificado e o caminho de retorno do serviço real são validados em separado.

Uma exceção DNS ACL adicional não restringe uma autorização ampla de zona WAN já ativa. O DNS permanece desativado para WAN na matriz e é permitido através de uma exceção específica, ou a autorização mais ampla é documentada como uma exposição consciente. Device Access e Local Service ACL explica como gerir esta camada sem provocar um bloqueio administrativo.

Se a delegação, o âmbito das respostas ou a proteção contra utilização recursiva não puderem ser claramente verificados, Publish on WAN não é ativado. Para zonas DNS públicas comuns, um serviço DNS autoritativo dedicado é normalmente a solução mais clara.

Delimitar erros por sintoma

A firewall resolve, mas o cliente não

• Verificar qual o servidor DNS realmente configurado no cliente. O DHCP pode distribuir o IP da firewall; o procedimento encontra-se em Configurar DHCP Server na Sophos Firewall.
• Verificar DNS over HTTPS, definições do cliente VPN e resolvedores estáticos no cliente como caminhos alternativos.
• Em Administration > Device access, verificar se o DNS é permitido a partir da zona do cliente.
• Utilizar Packet Capture para confirmar se o pedido e a resposta passam pela firewall.
• Não alterar o routing ou o NAT enquanto o cliente nem sequer estiver a consultar a firewall.

O cliente continua a receber o endereço antigo

• Verificar a entrada atual quanto a erros de escrita, hostnames duplicados e vários endereços.
• Ter em conta o antigo TTL ainda válido e as caches locais, do browser ou da aplicação.
• Enviar um novo pedido explícito para o IP da firewall em vez de apenas recarregar a aplicação.
• Antes de uma migração planeada, reduzir o TTL com antecedência e deixar o TTL anterior expirar completamente.

Esvaziar uma cache pode corrigir um único cliente de teste, mas não altera as respostas noutros resolvedores ou caches de aplicações. Por isso, não substitui uma espera controlada nem um teste através da cadeia DNS realmente utilizada.

Um nome permanece demasiado tempo em cache como localhost

Para domínios que resolvem para localhost, a Sophos Firewall não utiliza simplesmente o TTL do registo DNS. A firewall volta a consultar estes nomes de acordo com o intervalo localhost-ttl. O valor predefinido é 655360 segundos e o intervalo permitido vai de 60 a 655360 segundos. Quando um registo muda de localhost para outro host, a firewall pode, por isso, manter a resposta antiga durante mais tempo do que um cliente normal.

Primeiro, confirma-se com uma consulta direta ao resolver autoritativo ou previsto que o registo já não aponta para localhost. Em seguida, lê-se o valor atual do SFOS na Device Console:

show dns

⚠️ Antes de alterar o intervalo, guardar o valor inicial lido com show dns e manter disponível um acesso de gestão independente. A alteração é global, não se limita a esta Host Entry. Um valor menor gera consultas DNS mais frequentes e não esvazia imediatamente a cache.

Só quando este caso exato estiver confirmado se deve reduzir temporariamente o intervalo global. Os 300 segundos são aqui um exemplo para um teste de migração controlado, não uma recomendação geral:

set dns localhost-ttl 300

Após a alteração, verificar show dns e voltar a testar a resolução a partir da firewall e de um cliente real. Repor o valor predefinido do produto desta forma apenas se já era utilizado antes:

set dns localhost-ttl default

Se o intervalo anterior era personalizado, utilizar antes set dns localhost-ttl <previous-seconds> e substituir <previous-seconds> pelo número guardado; não introduzir o marcador literalmente. Depois, verificar o valor reposto com show dns e a resolução com uma nova consulta. Se o valor inicial for desconhecido, default não é uma reversão verificada.

Falta a pesquisa inversa ou aparece o nome errado

• Verificar se Add reverse DNS lookup for this host entry está ativado.
• Garantir que vários nomes não reclamam o mesmo endereço como destino PTR.
• Enviar explicitamente o pedido inverso para o IP da firewall.
• Para uma zona inversa interna num controlador de domínio, utilizar a DNS Request Route adequada em vez de uma entrada PTR local.

O pedido público não recebe resposta

• Verificar a partir do exterior a delegação NS e a acessibilidade dos endereços WAN.
• Verificar Publish on WAN em cada endereço previsto.
• Verificar Device Access, Local Service ACL, filtros upstream e a porta 53 UDP e TCP.
• Registar um Packet Capture durante um único pedido externo específico.
• Não ativar uma autorização DNS ampla como tentativa de resolução.

O DNS está correto, mas a aplicação continua inacessível

O DNS fornece apenas o endereço de destino. Seguem-se o routing, a regra de firewall, o NAT, o TLS e o serviço real. Por isso, o teste deve verificar sucessivamente o endereço IP, a porta e o protocolo da aplicação. Para problemas de regras e caminho, ajuda Testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture.

API XML: nome do objeto e nome DNS a partir do SFOS 23

Na automatização, Name e HostName são campos diferentes: Name designa o objeto configurado e HostName o nome DNS a resolver. A documentação do SFOS 23 exige ambos os campos ao criar e editar. Name é um único STRING com um máximo de 64 caracteres; permite UTF-8, mas não permite vírgulas. HostName continua a ser DOMAINNAMELOOKUP com um máximo de 253 caracteres. Por exemplo, Name = app01-intern e HostName = app01.corp.example podem ter valores diferentes; trata-se de uma correspondência entre campos e valores, não de XML executável.

Para a eliminação, o SFOS 22 documenta HostName como chave, enquanto o SFOS 23 documenta Name. Por isso, não repetir pedidos antigos do SFOS 22 sem alterações nem utilizar automaticamente o nome DNS como nome do objeto. Antes de uma chamada de eliminação, verificar a versão instalada, ler o objeto específico e comparar o nome do objeto, o nome DNS, os endereços e as dependências com o destino documentado. Se a identidade não for inequívoca, interromper. Depois, verificar a resposta da API e o respetivo estado e voltar a ler o destino exato: apenas o objeto pretendido pode estar ausente; as restantes entradas têm de permanecer inalteradas. O êxito do transporte, por si só, não comprova uma eliminação bem-sucedida. Não se fornece aqui um envelope de eliminação nem se afirma ter sido realizado um teste no produto.

Conflito de Reverse DNS por esclarecer: em ambas as versões, o exemplo da API para AddReverseDNSLookUp apresenta Enable/Disable, mas a tabela de parâmetros permite apenas Enable e indica simultaneamente Disable como valor predefinido. Isto não permite deduzir um pedido seguro com Disable nem com omissão do campo. Até ao esclarecimento pelo fabricante, não utilizar uma receita deste tipo para a API; em vez disso, configurar deliberadamente Reverse DNS através do procedimento WebAdmin descrito acima e verificar o PTR separadamente. As instruções da interface não confirmam a semântica dos valores enumerados da API.

Aplicam-se também os seguintes limites documentados à validação dos campos XML no SFOS 22 e 23; não garantem os valores predefinidos do WebAdmin:

• No máximo oito elementos Address por AddressList. IPFamily, EntryType, IPAddress, TTL, Weight e PublishOnWAN estão documentados como obrigatórios para Add/Edit; os seus valores na tabela são arrays e os duplicados não são ignorados.
• IPFamily: IPv4 ou IPv6; EntryType: Manual ou InterfaceIP. Para InterfaceIP, o exemplo XML espera o nome da interface em IPAddress, não um endereço IP fixo.
• IPAddress é STRING; a tabela exclui as classes MULTICAST, RESERVED, UNSPECIFIED, BROADCAST e LINKLOCAL. Por isso, não copiar os endereços de documentação deste artigo para uma chamada API de produção sem os validar.
• TTL é INTEGER de 1 a 604800 segundos, com um máximo de seis algarismos; a tabela indica 3600 como valor predefinido. Ainda assim, definir expressamente este campo obrigatório. Weight é INTEGER de 0 a 255, com um máximo de três algarismos; este limite não comprova um efeito específico para o peso 0.
• PublishOnWAN permite Enable ou Disable. Estes valores inequívocos não devem ser aplicados por analogia à definição contraditória de AddReverseDNSLookUp descrita acima.

As tabelas de estado distinguem Add, Edit e Delete, mas não explicam todos os códigos de erro enumerados. Em caso de erro, guardar a resposta API completa e o estado atual do objeto antes de repetir uma chamada que o modifique; não deduzir êxito nem uma causa apenas do transporte HTTP.

Alterações, HA e rollback

Antes de uma alteração, documentam-se o nome, a resposta atual, o TTL, a pesquisa inversa, os resolvedores utilizados pelos clientes e os serviços dependentes. Com vários endereços, o estado inicial inclui também pesos, associação WAN, delegação NS, DNAT e caminho de retorno.

Num cluster HA, efetua-se um novo pedido DNS após um failover planeado. Numa publicação pública, testam-se também ambos os caminhos WAN e um novo fluxo da aplicação. Este artigo não pressupõe caches DNS sincronizadas nem uma ligação ativa sem interrupções.

Para o rollback:

1. Antes de uma migração planeada, reduzir o TTL e aguardar que o TTL anterior expire.
2. Documentar as aplicações dependentes e o caminho DNS público.
3. Repor o endereço, a interface ou a Host Entry no estado inicial confirmado.
4. Remover uma exceção temporária de Device Access e a publicação WAN que já não seja necessária.
5. Voltar a consultar explicitamente a partir da firewall e do cliente.
6. Voltar a testar a resolução direta, o PTR opcional, a acessibilidade e a aplicação real.

Checklist

• A Sophos Firewall vê o pedido DNS do cliente afetado.
• Um único nome estático é mais adequado do que uma DNS Request Route.
• O FQDN, a versão IP, o endereço e o TTL estão documentados.
• Publish on WAN permanece desativado para entradas internas.
• Uma entrada PTR só está ativada para o nome canónico do endereço.
• A firewall e o cliente devolvem a mesma resposta esperada.
• O acesso DNS está limitado às origens necessárias em Device Access.
• Com vários endereços, foram testados os pesos, o estado do link e o caminho da aplicação.
• Na publicação WAN, estão documentados a delegação NS, os endereços dos servidores DNS e um teste negativo de recursão.
• O rollback e o tempo de espera das caches são conhecidos antes da alteração.

Perguntas frequentes