Examinar o comportamento das consultas DNS e da resolução de nomes de domínio

Introdução

Este documento descreve como os sistemas operacionais clientes lidam com as consultas DNS e os efeitos na resolução de nomes de domínio usando o Cisco IOS® Secure Client.

---

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas. Os exemplos de laboratório usam as políticas de grupo do Secure Firewall ASA/FTD e o Cisco Secure Client em Windows, macOS, Linux e Apple iOS.

---

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

---

DNS dividido versus padrão

Este documento explica como os sistemas operacionais do cliente lidam com consultas DNS e os efeitos na resolução de nomes de domínio ao usar o Cisco Secure Client (anteriormente Cisco AnyConnect) com tunelamento dividido ou completo. Os headends de VPN discutidos incluem o Cisco Secure Firewall ASA e o FTD (antigo ASA); as configurações de política de grupo, como split-dns, dns-server e split-tunnel-all-dns, aplicam-se a ambos, a menos que observado de outra forma.

---

Se uma seção fizer referência explícita a versões anteriores do cliente, o comportamento descrito para o Secure Client 4.2 e posterior (incluindo as versões atuais do Secure Client 5.x) será aplicado. O Cisco AnyConnect 4.x chegou ao fim da vida útil; migre para o Cisco Secure Client para obter os recursos de DNS e tunelamento suportados.

O comportamento da resolução DNS depende de três fatores:

• Política de DNS da VPN: Configurado no headend (DNS dividido, tunnel-all-DNS ou DNS padrão)
• Modo de separação de túneis: Túnel-all, split-include ou split-exclude
• Sistema operacional do cliente: Arquitetura do resolvedor DNS (por interface versus global)

---

Quando você executa o comando split-include tunneling, estas são as três opções de DNS disponíveis na política de grupo:

---

Modo	Descrição
DNS dividido	As consultas DNS que correspondem aos nomes de domínio configurados no headend (split-dns) são enviadas pelo túnel para os servidores DNS da VPN (dns-server). Todas as outras consultas usam o resolvedor do sistema operacional do cliente e os servidores DNS do adaptador físico.
Tunnel-all-DNS	Somente o tráfego DNS para os servidores DNS definidos pelo headend é permitido. Configurado com split-tunnel-all-dns enable na política de grupo.
DNS padrão	Todas as consultas DNS são enviadas primeiro aos servidores DNS da VPN definidos pelo headend. Em uma resposta negativa (NXDOMAIN ou sem resposta), o resolvedor também pode tentar servidores DNS no adaptador físico.

---

---

Teste de DNS — Importante

---

---

DNS verdadeiro versus DNS dividido por melhor esforço

O AnyConnect versão 2.4 introduziu split DNS fallback (melhor-esforço split DNS), que não é um DNS dividido verdadeiro e também foi encontrado no cliente IPsec legado.

---

Comportamento de melhor esforço (fallback):

• Se a solicitação corresponder a um domínio DNS dividido, o Secure Client permitirá que a solicitação seja encapsulada no headend.
• Se o servidor DNS da VPN não puder resolver o nome do host, o resolvedor DNS do SO continuará e poderá enviar a mesma consulta a um servidor DNS na interface física.
• Se a solicitação não corresponder a nenhum domínio DNS dividido, o Secure Client não criará um túnel para ela. Ele pode sintetizar uma resposta, portanto, o resolvedor volta para os servidores DNS da interface física.

---

É por isso que o recurso herdado é chamado de fallback de DNS para tunelamento dividido, que não é um DNS dividido verdadeiro. O Secure Client garante que somente as consultas de domínio DNS dividido correspondentes entrem no túnel, mas ainda depende do comportamento do resolvedor do SO para a resolução final.

---

Preocupação com a segurança: Um nome de domínio privado pode vazar para um servidor DNS público quando o servidor DNS VPN retorna NXDOMAIN ou não consegue resolver; e o resolvedor tenta novamente no adaptador físico.

DNS dividido verdadeiro: ID de bug da Cisco CSCtn14578

---

Resolvido no Microsoft Windows no AnyConnect 3.0(4235) e retido no Secure Client 4.2+):

• As consultas para domínios DNS divididos configurados são permitidas apenas através do caminho VPN (servidores DNS de túnel/adaptador VPN, dependendo da plataforma e da versão.)
• Todas as outras consultas são permitidas somente através de servidores DNS não VPN (adaptador físico).

---

DNS de Túnel Total e Túnel Total

Quando o tunelamento dividido está desabilitado (configuração tunnel-all), o tráfego DNS é permitido estritamente através do túnel.

A configuração tunnel-all-DNS (split-tunnel-all-dns enable na política de grupo) envia todas as pesquisas de DNS pelo túnel, enquanto alguma forma de tunelamento dividido também é configurada, e o tráfego de DNS é permitido estritamente através da interface de túnel.

Isso é consistente nas plataformas com uma advertência no Microsoft Windows, quando tunnel-all ou tunnel-all-DNS é configurado, o Secure Client permite o tráfego DNS estritamente para os servidores DNS configurados no gateway seguro (aplicado ao adaptador VPN). Esse aprimoramento de segurança foi implementado com DNS dividido verdadeiro. Se isso for problemático (por exemplo, a atualização/registro de DNS deve alcançar servidores DNS não VPN), conclua estas etapas:

1. Se a configuração atual for tunnel-all, ative o encapsulamento split-exclude. Qualquer rede de host único com split-exclude é aceitável, como um endereço de link local.
2. Verifique se tunnel-all-DNS não está habilitado na política de grupo (split-tunnel-all-dns disable.)

---

Módulo Tunnel-all-DNS e Cisco Secure Client Umbrella

Quando split tunneling e tunnel-all-DNS estão habilitados, o DNS é interceptado no nível do kernel e bloqueado se não sair da interface VPN correta. O módulo Secure Client Umbrella (antigo AnyConnect Roaming Security) pode ser afetado em redes onde o DNS criptografado não está disponível. Isso ocorre porque o módulo pode tentar o DNS padrão por meio da interface da LAN, enquanto tunnel-all-DNS requer o DNS por meio da VPN.

---

Por padrão, o módulo Umbrella usa DNS criptografado (porta UDP 443), que geralmente não é bloqueado por tunnel-all-DNS. O problema aparece principalmente quando a criptografia não está disponível e o DNS simples é usado.

Recomendação: Adicione os endereços do resolvedor Cisco Umbrella à lista de divisão de inclusão se usar tunnel-all-DNS com o módulo Umbrella. Ou consulte o documento Enable Tunnel All DNS for Secure Client with Umbrella Module (ID do documento: 224809.)

---

Problema de desempenho de DNS resolvido no AnyConnect versão 3.0 (4235)

Esse problema do Microsoft Windows é predominante nestas condições:

• Configuração do roteador residencial onde os servidores DNS e DHCP compartilham o mesmo endereço IP (o cliente seguro cria uma rota necessária para o servidor DHCP).
• Um grande número de sufixos/domínios DNS na política de grupo.
• Uma configuração tunnel-all.
• A resolução de nomes usa um nome de host não qualificado, portanto, o resolvedor tenta vários sufixos DNS em todos os servidores DNS disponíveis.
• O cliente DNS nativo tenta enviar consultas DNS através do adaptador físico, que o Secure Client bloqueia em tunnel-all.

---

Isso pode causar atrasos significativos na resolução de nomes, especialmente quando o headend envia muitos sufixos DNS. O resolvedor deve percorrer sufixos e servidores até receber uma resposta positiva.

Esse problema é resolvido no AnyConnect 3.0(4235) e versões posteriores do Secure Client. Consulte o bug da Cisco ID CSCtq02141 e o bug da Cisco ID CSCtn14578 para obter detalhes.

---

---

Soluções alternativas (se uma atualização não for possível)

Habilite o tunelamento split-exclude para um endereço IP, de modo que o DNS local possa usar o adaptador físico. Um endereço da sub-rede local de link 169.254.0.0/16 é comumente usado como tráfego para esses endereços que provavelmente não atravessará a VPN.

---

Depois de habilitar o tunelamento split-exclude, habilite o acesso à LAN local no perfil ou no cliente do cliente e desabilite tunnel-all-DNS. Este é um exemplo de configuração de ASA/FTD:

access-list acl_linklocal_169.254.1.1 standard permit host 169.254.1.1
group-policy gp_access-14 attributes
split-tunnel-policy excludespecified
split-tunnel-network-list value acl_linklocal_169.254.1.1
split-tunnel-all-dns disable
exit

---

XML do perfil do cliente:

<LocalLanAccess UserControllable="true">true</LocalLanAccess>

---

Você também pode ativar isso na GUI do Secure Client: Preferências → Habilitar Permitir Acesso Local (LAN) ao usar VPN

1. Use nomes de domínio totalmente qualificados (FQDNs) em vez de nomes de host não qualificados.
2. Use um endereço IP diferente para o servidor DNS na interface física (separado do DHCP na mesma sub-rede).

---

DNS com tunelamento dividido em sistemas operacionais clientes diferentes

Diferentes sistemas operacionais clientes lidam com DNS de forma diferente com tunelamento dividido (sem DNS dividido) para Cliente Seguro; esta seção descreve essas diferenças.

---

Microsoft Windows (Windows 10 e Windows 11)

No Windows, as configurações DNS são definidas por interface de rede. Com o tunelamento dividido, as consultas de DNS podem retornar aos servidores DNS do adaptador físico depois que eles falharem no adaptador de túnel VPN. Se o tunelamento dividido for usado sem DNS dividido, a resolução interna e externa poderá funcionar, pois o resolvedor pode retornar para servidores DNS externos. Houve uma mudança significativa no Secure Client para Windows na versão 4.2 após a correção do bug da Cisco ID CSCuf07885. Esse comportamento não foi alterado no Secure Client 5.x.

---

---

Configuração de túnel completo (e separação de túneis com Tunnel-all-DNS ativado)

Cliente pré-seguro 4.2 (AnyConnect 4.1 e anterior):

• Somente solicitações DNS para servidores DNS configurados sob a política de grupo (servidores DNS de túnel) são permitidas.
• O driver do Secure Client responde a todas as outras solicitações sem esse nome.
• A resolução DNS só pode usar servidores DNS de túnel.

---

Secure Client 4.2 e posterior:

• As solicitações DNS para qualquer servidor DNS são permitidas se forem originadas do adaptador VPN e enviadas pelo túnel.
• Todos os outros pedidos não recebem esse nome; somente através do túnel VPN.
• Antes da ID de bug da Cisco CSCuf07885, os servidores DNS de destino restritos do Secure Client. Após essa correção, ela restringe quais adaptadores de rede podem iniciar solicitações DNS.

---

Configuração de Split-include (Tunnel-all-DNS desativado, No Split-DNS)

O driver do Secure Client não interfere no resolvedor de DNS nativo. A resolução adere à ordem do adaptador de rede; O Secure Client é o adaptador preferencial quando a VPN está conectada.

---

Uma consulta DNS é enviada primeiro através do túnel; se não for resolvido, o resolvedor pode tentar a interface pública. A lista de acesso com divisão de inclusão deve incluir a sub-rede que cobre o(s) servidor(es) DNS do túnel nas versões anteriores à 4.2. A partir do Secure Client 4.2, as rotas de host para o(s) servidor(es) DNS do túnel são automaticamente adicionadas como redes com divisão de inclusão (rotas seguras), de modo que a ACL com divisão de inclusão não exige mais sub-redes de servidor DNS de túnel explícito.

---

Configuração Split-exclude (Tunnel-all-DNS desabilitado, sem Split-DNS)

O mesmo comportamento do resolvedor como split-includes, túnel primeiro e depois fallback da interface pública. A lista de acesso split-exclude não deve incluir a sub-rede que cobre o(s) servidor(es) DNS do túnel. Começando com o Secure Client 4.2, as rotas de host automáticas para servidores DNS de túnel evitam a configuração incorreta de split-exclude comum.

---

Split-DNS (Tunnel-all-DNS Desabilitado, Split-include Configurado)

O DNS dividido no Windows requer o encapsulamento split-include (split-tunnel-policy tunnelspecified.) Ele não oferece suporte a políticas de túnel split-exclude-only para configuração de DNS dividido.

Cliente pré-seguro 4.2:

• Consultas de domínio DNS dividido: Autorizado a criar túneis somente para servidores DNS; esse nome não existe se for enviado para outros servidores.
• Consultas de domínio DNS não dividido: Permitido somente para outros servidores DNS; nenhum nome desse tipo se tentada via túnel.

---

Secure Client 4.2 e posterior (DNS dividido verdadeiro no Windows):

• Consultas de domínio DNS dividido: Permitido para qualquer servidor DNS somente se eles forem originários do adaptador VPN. As consultas da interface pública não recebem esse nome para forçar o uso do túnel.
• Consultas de domínio DNS não dividido: Permitido para qualquer servidor DNS somente se eles forem originários do adaptador físico. As consultas do adaptador VPN não recebem esse nome para forçar a resolução da interface pública.

---

Split-DNS com tunelamento Split-exclude (Secure Client 5.x)

A documentação do administrador do Secure Client 5.x adiciona DNS dividido para configurações split-exclude. Consulte o Guia do Administrador do Secure Client 5.x — Configurar o DNS Dividido para Split Exclude Tunneling para obter os requisitos de headend e política. As regras de imposição no nível do sistema operacional ainda se aplicam quando o DNS dividido está ativo.

---

DNS criptografado (DoH/DoT) no Windows

Aplicativos ou recursos do sistema operacional que usam DNS sobre HTTPS (DoH) ou DNS sobre TLS (DoT) podem ignorar o caminho do resolvedor de stub do Windows que o Secure Client filtra. Se o DNS dividido parecer falhar para aplicativos específicos, mas funcionar em um navegador, verifique se esses aplicativos usam DNS criptografado ou personalizado. O teste padrão de DNS dividido deve usar o resolvedor de sistema operacional (navegador, ping), não NSLookup/dig.

---

MacOS

No macOS, as configurações DNS são globais (não por interface). Se o tunelamento dividido for usado sem DNS dividido, as consultas DNS frequentemente não podem acessar servidores DNS fora do túnel como esperado, você pode resolver apenas nomes internos, não nomes externos através do caminho público. Isso está documentado na ID de bug da Cisco CSCtf20226 e na ID de bug da Cisco CSCtz86314.

---

Soluções:

• Especifique um IP de servidor DNS externo na política de grupo e use FQDNs para consultas internas.
• Se os nomes externos puderem ser resolvidos através do túnel, desabilite o DNS dividido em Avançado > Split Tunneling removendo nomes DNS da política de grupo e use FQDNs para consultas internas.

---

O DNS dividido no macOS é suportado a partir do AnyConnect 3.1, sujeito às seguintes condições:

• Dividir DNS ativado para ambos os protocolos IP (requer ASA 9.0+/FTD equivalente) ou;
• O DNS dividido habilitado para um protocolo IP e o Client Bypass Protocol habilitados para o outro sem nenhum pool de endereços para o protocolo ignorado (ou nenhum pool IPv6 nas versões do ASA anteriores à 9.0).

---

---

Configuração de túnel completo (e separação de túneis com Tunnel-all-DNS ativado)

Quando o Secure Client estiver conectado, somente os servidores DNS do túnel permanecerão na configuração DNS do sistema; as solicitações só prosseguem para o(s) servidor(es) DNS do túnel.

---

Split-include / Split-exclude (Tunnel-all-DNS desativado, sem Split-DNS)

O Secure Client não interfere no resolvedor nativo. Os servidores DNS de túnel têm preferência sobre os resolvedores públicos, portanto, a primeira tentativa de consulta ocorre sobre o túnel. Como o DNS é global no macOS, as consultas nem sempre usam de forma confiável o DNS público fora do túnel (ID do bug da Cisco: CSCtf2026).

A partir do Secure Client 4.2, as rotas de host para servidores DNS de túnel são adicionadas automaticamente como rotas seguras.

---

Split-DNS (Tunnel-all-DNS Desabilitado, Split-include Configurado)

O DNS dividido verdadeiro (semelhante ao Windows) se aplica quando:

• Split-DNS está habilitado para IPv4 e IPv6 ou;
• O DNS dividido está habilitado para um protocolo e não existe nenhum pool de endereços de cliente para o outro protocolo.

---

O DNS dividido verdadeiro significa que os domínios DNS divididos correspondentes resolvem apenas através do túnel e não vazam para resolvedores externos.

Se o DNS dividido estiver habilitado para apenas um protocolo e um endereço de cliente for atribuído para o outro protocolo, somente o fallback de DNS para tunelamento dividido será imposto: O Cliente Seguro permite consultas correspondentes através do túnel (outras consultas podem ser recusadas para forçar o failover), mas não pode impedir totalmente o vazamento de consultas de domínio DNS dividido enviadas na limpeza através do adaptador público.

Suporte à plataforma (guia de administração do Secure Client): DNS de divisão completa é suportado no Windows e no macOS. O Linux tem suporte limitado (consulte a seção Linux).

---

Linux

Configuração de túnel completo (e separação de túneis com Tunnel-all-DNS ativado)

Quando o Secure Client está conectado, somente os servidores DNS de túnel são mantidos na configuração DNS do sistema.

---

Split-include / Split-exclude (Tunnel-all-DNS desativado, sem Split-DNS)

O Secure Client não interfere no resolvedor nativo. Os servidores DNS de túnel são os preferidos; a tentativa de resolução inicial passa pelo túnel.

---

Split-DNS (Tunnel-all-DNS Desabilitado, Split-include Configurado)

Se o split-DNS estiver ativado, somente o fallback de DNS para o tunelamento dividido será aplicado no Linux:

• O Secure Client permite consultas de domínio DNS dividido através do túnel.
• Outras consultas podem receber recusa para incentivar o failover para DNS público.
• O Cliente Seguro não pode aplicar totalmente as consultas de domínio DNS dividido, pois elas nunca são enviadas sem formatação através do adaptador público.

O guia de administração do Secure Client observa que o DNS dividido no Linux é limitado: somente as solicitações de DNS encapsulado estão totalmente sujeitas à política de DNS dividido; algumas consultas fora do túnel não podem estar em conformidade com a política DNS dividida.

---

VMs e contêineres Linux

O Secure Client oferece suporte a um atributo personalizado tunnel-from-any-source, para que os pacotes com qualquer endereço de origem possam ser roteados no modo split-include ou split-exclude dentro de instâncias da VM ou contêineres Docker. Consulte o Guia do Administrador do Secure Client 5.x para obter detalhes da configuração.

---

Apple iOS (iPhone e iPad)

O comportamento do iOS difere do macOS e não é idêntico ao do Windows. Se o tunelamento dividido for configurado sem DNS dividido, as consultas DNS normalmente usam o servidor DNS global definido para o dispositivo, e não o mesmo padrão de fallback do Windows.

---

Impacto prático: As entradas de domínio DNS divididas são frequentemente necessárias para uma resolução de nome interno confiável quando se usa o tunelamento dividido sem DNS dividido.

Correção histórica: ID de bug da Cisco CSCtq09624 - (AnyConnect para iOS 2.5.4038 e posterior.) O Secure Client para iOS atual obedece ao mesmo requisito geral; configure o DNS dividido para domínios internos ao usar split-include/split e exclude sem depender de fallback no estilo Windows.

A Apple trata isso como um comportamento projetado; não espere a resolução .local através do DNS dividido padrão no iOS. No iOS, o comportamento split-DNS do Secure Client também difere de outras plataformas quando o tunelamento dividido é combinado com certas configurações de lista split-DNS. Consulte a seção do Guia do Administrador de Cliente Seguro Comportamento de Resolução DNS Dividido com Túnel Dividido para combinações de políticas específicas do iOS (split-dns none, default-domain e assim por diante.)

---

Dynamic Split Tunneling e DNS (Secure Client 4.5+)

O tunelamento dividido dinâmico resolve FQDNs no tempo de conexão ou sob demanda e ajusta o roteamento e os filtros para o tráfego em domínios especificados. Isso está incluído ou excluído do túnel sem listas de IP estáticos.

---

Recurso	Descrição
Exclusão de divisão dinâmica	Os domínios (example.com) são excluídos do túnel em tempo de execução quando os aplicativos resolvem esses nomes.
Divisão dinâmica inclui	Os domínios são incluídos dinamicamente no túnel.
Divisão dinâmica aprimorada	Listas de domínio de inclusão/exclusão combinadas com regras de precedência (como exclusão de example.com, mas incluindo mail.example.com).

---

O tunelamento dividido dinâmico usa a resolução DNS para direcionar alterações de roteamento. Ele é configurado por meio de atributos personalizados do Secure Client no headend (por exemplo, dynamic-split-exclude-domains, dynamic-split-include-domains.)

---

O tunelamento dividido dinâmico aplica-se às políticas tunnel-all e split-exclude (exclusão dinâmica) ou split-include (inclusão dinâmica). Ele não substitui a política DNS dividida, no entanto, a complementa: dividir os controles DNS que as consultas são encapsuladas; o tunelamento dividido dinâmico controla qual tráfego IP é encapsulado com base em nomes resolvidos. Consulte os detalhes de configuração: Configure Dynamic Split Tunneling e o Secure Client 5.x Administrator Guide.

---

Failover de exclusão de divisão (Secure Client 5.x): O atributo personalizado opcional SplitExcludeFailoverEnabled roteia o tráfego pela VPN quando o caminho público não tem conectividade com destinos de divisão-exclusão. Consulte o guia do administrador para obter informações sobre a configuração de atributos personalizados.

---

Versões Históricas do Cliente (Referência)

A tabela a seguir se aplica somente a implantações antigas que ainda executam clientes obsoletos:

---

Versão	Relevância
AnyConnect 2.4	Introduziu fallback de DNS dividido por melhor esforço
AnyConnect 2.5 (iOS)	ID de bug da Cisco: CSCtq09624 Alinhamento DNS do iOS
AnyConnect 3.0(4235)	DNS dividido verdadeiro no Windows; Correções de desempenho DNS
AnyConnect 3.1 (Mac OS)	Suporte a DNS dividido com condições IPv4/IPv6
AnyConnect 4.2	ID de bug da Cisco: CSCuf07885 aplicação baseada em adaptador; rotas de host DNS de túnel automático

---

Implante o Secure Client 5.x em todas as plataformas suportadas para correções e recursos atuais.

---

Informações de bug relacionadas

• ID de bug da Cisco: CSCtn14578 - DNS dividido verdadeiro (não fallback) - Windows, 3.0(4235)+
• ID de bug da Cisco: CSCtq02141 - Atraso de DNS quando o DNS do ISP está na mesma sub-rede do IP público
• ID de bug da Cisco: CSCuf07885 - DNS do Windows: restringir por adaptador, não por servidor de destino - 4.2+
• ID de bug da Cisco: CSCtf2026 - DNS de túnel dividido do macOS diferente do Windows
• ID de bug da Cisco: CSCtz86314 - consultas DNS divididas do macOS não enviadas via túnel
• ID de bug da Cisco: CSCtq09624 - Comportamento DNS do túnel dividido do iOS
• ID de bug da Cisco: CSCts89292 - o iOS ignora .domínios DNS locais
• ID de bug da Cisco: CSCsv34395 - Proxy FQDN para suporte ao servidor DHCP

---

Informações Relacionadas

• Examine o comportamento das consultas DNS e da resolução de nomes de domínio (Cisco.com) — ID do documento 116016
• Guia do Administrador do Cisco Secure Client 5.x — Configurar o Acesso VPN/Dividir o DNS
• Configurar o encapsulamento dividido dinâmico ASA/AnyConnect — ID do documento 215383
• Enable Tunnel All DNS for Secure Client with Umbrella Module — ID do documento 224809
• Interoperabilidade entre o AnyConnect e o cliente de roaming do OpenDNS — ID do documento 200395
• Suporte técnico e downloads da Cisco

---

Histórico das revisões

Revisão	Data	Comentários
4,0	28-jul-2026	Atualização substantiva completa: Marca do cliente seguro, atualização de plataforma, encapsulamento dividido dinâmico, Umbrella/tunnel-all-DNS, correções de erros de digitação e configuração, links relacionados corrigidos
3.0	23-maio-2024	Recertificação (Cisco.com)
1.0	12-jun-2014	Versão inicial

---

O documento se aplica a

• Cisco Secure Client (incluindo AnyConnect) — Windows, macOS, Linux, iOS
• Políticas de grupo de VPN de acesso remoto Cisco Secure Firewall ASA e FTD

Histórico de revisões

Revisão	Data de publicação	Comentários
4.0	10-Aug-2026	Introdução atualizada, ortografia, gramática, URLs fixas, linhas horizontais inseridas em seções separadas para facilitar a leitura e erros fixos do CCW.
3.0	23-May-2024	Recertificação
1.0	12-Jun-2014	Versão inicial