DNS e DHCP em redes OT: resolução de nomes, leases e dependências
Entenda quando usar DNS e DHCP em automação, registros, TTL, relay, reservas, opções, modos de falha e como impedir que uma dependência invisível derrube o serviço.
Dependências e falhas de DNS/DHCP
| Função | Falha típica | Teste objetivo |
|---|---|---|
| DNS A/AAAA | IP ausente ou incorreto | consulta autoritativa e do cliente |
| TTL/cache | mudança demora a aparecer | comparar TTL e caches |
| DHCP pool | exaustão ou sobreposição | leases, exclusões e Discover |
| Relay | uma VLAN sem oferta | captura antes e depois do relay |
| Opções | gateway/DNS incorreto | ACK e configuração aplicada |
| Redundância | cliente cai após horas | renovação durante perda controlada |
O aceite deve chegar ao serviço final que consome nome ou endereço.
Endereço estático não elimina dependências de nome
IEDs e controladores frequentemente usam IP fixo, mas estações, servidores, certificados, proxies e integrações podem depender de DNS. Um SCADA configurado por nome deixa de iniciar sessão se a resolução falha, mesmo que o endereço final esteja ativo. O inventário deve distinguir endereço configurado, hostname operacional, nomes alternativos e quem consulta cada registro.
DHCP também pode ser apropriado para notebooks controlados, telefones, sensores ou dispositivos gerenciados, enquanto funções críticas permanecem estáticas ou usam reserva. A decisão precisa considerar recuperação sem servidor, substituição, auditoria, segurança e capacidade do equipamento, não a regra simplista de que OT nunca usa DHCP.
DNS resolve nomes por registros e cache
Registros A e AAAA ligam nome a IPv4 ou IPv6; PTR oferece resolução reversa; CNAME cria alias; outros tipos servem funções específicas. O resolver pode usar cache até o TTL expirar. Alterar o registro não muda instantaneamente todos os clientes, e TTL muito longo prolonga erro enquanto TTL curto aumenta consultas e dependência do servidor.
Nomes em certificados HTTPS ou serviços distribuídos devem ser projetados em conjunto. Acessar por IP pode contornar DNS, mas causar mismatch de certificado e criar procedimento inseguro. Para contingência, defina se o cliente mantém cache, se há servidores redundantes e como validar ambos sem inserir arquivos hosts divergentes em dezenas de estações.
Diagnóstico DNS separa consulta, resposta e uso
Registre servidor consultado, nome exato, tipo, resposta, TTL e código de erro. NXDOMAIN significa que o nome foi declarado inexistente; timeout indica ausência de resposta; SERVFAIL aponta falha de processamento. Uma resposta correta ainda pode levar ao IP errado por registro desatualizado ou split DNS.
Capture a consulta e compare com configuração do cliente. Depois teste o serviço pelo nome, não apenas o DNS. Se o endereço resolve e TCP falha, avance para rota e firewall. Se TLS falha por hostname, a rede e o DNS podem estar corretos, mas o certificado ou URL não está.
DHCP entrega mais que um endereço
No fluxo DHCPv4 típico, o cliente descobre servidores, recebe oferta, solicita uma opção e recebe confirmação. Além do IP e máscara, opções podem informar gateway, DNS, domínio, NTP e outros parâmetros. Uma opção errada pode permitir ping local e quebrar comunicação remota ou sincronismo.
O lease define tempo de uso e renovação. Um cliente ativo tenta renovar antes de expirar; se o servidor falha, pode manter endereço por algum tempo e cair depois, criando ocorrência tardia. O projeto precisa documentar duração, redundância, comportamento de reboot e risco de exaustão do pool.
Relay atravessa sub-redes com política
DHCP usa broadcast inicial, que roteadores não encaminham normalmente. Um relay recebe a solicitação na VLAN do cliente e a envia ao servidor, incluindo informação que identifica a origem. Relay, helper address, ACL ou roteamento incorretos podem afetar apenas uma VLAN enquanto outras funcionam.
No troubleshooting, verifique Discover na porta do cliente, mensagem encaminhada pelo relay, resposta do servidor e retorno à VLAN. Não conclua que o servidor falhou porque o cliente não recebeu endereço. O ponto de perda pode ser snooping, trust da porta, ACL ou pool associado à sub-rede errada.
Reservas e proteção contra servidores indevidos
Reserva associa identificador ou MAC a um endereço previsível, mas troca de placa muda a identidade e pode impedir recuperação. Registre a associação e o processo de substituição. IP fixo dentro do pool sem exclusão pode causar conflito; mantenha faixas e reservas coerentes.
Um servidor DHCP indevido pode fornecer gateway ou DNS malicioso. DHCP snooping e portas trusted ajudam, desde que topologia e redundância sejam conhecidas. Teste failover e uplinks; um trust incorreto pode bloquear o servidor legítimo durante contingência.
Arquitetura resiliente e operação degradada
Defina servidores por zona, redundância, backup de configuração e monitoração. Clientes críticos devem ter comportamento conhecido durante perda prolongada. Para DNS, mantenha registros sob controle de mudança e sincronismo entre servidores; para DHCP, preserve banco de leases quando o mecanismo de redundância exigir.
O modo degradado deve ser ensaiado: desligue um servidor autorizado, renove clientes de teste, resolva nomes existentes e novos, e observe alarmes. Não faça o teste diretamente em IED de proteção sem avaliar impacto. A recuperação inclui reconciliação de leases e remoção de registros obsoletos.
Aceite integrado com a aplicação
Para cada cliente, prove endereço, máscara, gateway, DNS, nome e serviço final. Reinicie um ativo de teste, renove lease, confirme ausência de conflito e valide logs. Altere um registro de laboratório com TTL controlado e observe propagação. Teste certificado pelo hostname previsto.
A evidência precisa unir consulta DNS ou troca DHCP à sessão de automação. Assim fica claro se a falha nasceu na atribuição, resolução, rede, segurança ou aplicação. O reteste deve incluir expiração ou renovação, não apenas conectividade imediata.
Referências técnicas e normas
As explicações do Portal são autorais. Normas e fontes oficiais são priorizadas; materiais acadêmicos e documentação pública de fabricantes complementam a implementação e não substituem a edição normativa aplicável ao projeto.
- IEC 62443-3-3:2013 — System security requirements and security levels — IEC. Requisitos técnicos de segurança para sistemas de automação e controle industrial.
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security — NIST. Arquiteturas, ameaças e controles aplicáveis a ambientes OT.
- RFC 1122 — Requirements for Internet Hosts — Communication Layers — RFC Editor / IETF. Requisitos de IP, ICMP e camadas de comunicação em hosts.
- RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification — RFC Editor / IETF. Especificação vigente do IPv6.
- RFC 9110 — HTTP Semantics — RFC Editor / IETF. Semântica atual de métodos, campos e códigos HTTP.
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — RFC Editor / IETF. TLS 1.3, handshake, autenticação e proteção do transporte.
- RFC 9325 — Recommendations for Secure Use of TLS and DTLS — RFC Editor / IETF. Recomendações atuais para versões, algoritmos e configuração TLS.
- RFC 4251 — The Secure Shell (SSH) Protocol Architecture — RFC Editor / IETF. Arquitetura SSH e separação entre transporte, autenticação e conexão.
- RFC 5424 — The Syslog Protocol — RFC Editor / IETF. Formato, facility, severity, timestamp e dados estruturados de Syslog.
- RFC 3411 — Architecture for Describing SNMP Management Frameworks — RFC Editor / IETF. Arquitetura do framework SNMP.
- RFC 3414 — User-based Security Model (USM) for SNMPv3 — RFC Editor / IETF. Autenticação e privacidade do SNMPv3 USM.
- IEEE 802.1AB-2016 — Station and Media Access Control Connectivity Discovery — IEEE Standards Association. LLDP e descoberta de conectividade em camada 2.
- RFC 1034 — Domain Names — Concepts and Facilities — RFC Editor / IETF. Modelo distribuído, zonas, cache e resolução DNS.
- RFC 1035 — Domain Names — Implementation and Specification — RFC Editor / IETF. Formato e operação do protocolo DNS.
- RFC 2131 — Dynamic Host Configuration Protocol — RFC Editor / IETF. Processo DORA, leases e mensagens DHCPv4.
- RFC 2132 — DHCP Options and BOOTP Vendor Extensions — RFC Editor / IETF. Opções de gateway, DNS, tempo e outras configurações entregues ao cliente.
Continue estudando
Os próximos conteúdos foram escolhidos para formar uma sequência técnica, relacionando fundamento, configuração, diagnóstico e aplicação.