Tema: dns
-
Alterar um registro DNS com caminho de rollback: redução do TTL, cutover e verificação
Uma alteração de DNS só chega aos usuários na velocidade em que o TTL antigo expira nos caches. Por isso, reduza o TTL um período completo do TTL antigo antes da mudança, mantenha o destino antigo ativo até confirmar o novo em toda parte e considere os resolvedores que servem dados expirados quando os servidores autoritativos estão inacessíveis, conforme permite a RFC 8767.
-
Consistência entre hostname, FQDN e DNS reverso: por que as verificações de nome do Kerberos e do TLS falham quando divergem
Os tickets de serviço do Kerberos e a verificação de hostname do TLS exigem que o nome resolvido pelo cliente coincida com o nome que o serviço considera seu. Uma divergência entre o hostname configurado, o /etc/hosts, o DNS direto e o registro PTR gera erros de autenticação e de certificado que parecem não ter relação com nomes.
-
Inspecionar e alterar as configurações de rede do macOS pelo Terminal: networksetup, scutil e cache de DNS
networksetup e scutil leem e alteram o serviço de rede ativo, os servidores DNS, os proxies e o nome do computador; dscacheutil e mDNSResponder limpam o cache desatualizado do resolvedor após uma mudança de DNS, para que um novo teste não receba a resposta antiga.
-
Administrar zonas e registros do DNS Server com PowerShell e verificar com Resolve-DnsName
Como usar Get-DnsServerZone, adicionar registros A e CNAME, listá-los com Get-DnsServerResourceRecord, configurar scavenging/aging para expirar registros obsoletos e limpar o cache do resolvedor, conferindo cada escrita pelo lado do cliente e não apenas pela visão do servidor.
-
Um resolvedor DNS local com cache usando Unbound: access-control, encaminhamento e validação DNSSEC
Para executar o Unbound como resolvedor com cache, é preciso restringir quem pode consultá-lo com access-control, escolher entre recursão completa e uma forward-zone para um resolvedor upstream, manter a validação DNSSEC ativa com um auto-trust-anchor-file e testar as alterações com unbound-checkconf antes de recarregar.
-
Registros DNS dos quais um serviço web depende
A, AAAA e CNAME associam nomes a endereços, MX encaminha e-mail, TXT guarda verificações e políticas, CAA restringe quem pode emitir certificados e NS delega zonas; antes e depois de alterações, consulte as respostas autoritativas, não apenas um resolvedor com cache.
-
Renovação de domínios, bloqueio no registrador e boas práticas de titularidade do DNS
Um domínio se perde por cartão vencido, e-mail do registrante hospedado no próprio domínio ou conta sem bloqueio, e não apenas por ataques: mantenha os bloqueios de cliente como clientTransferProhibited ativos (RFC 5731), use renovação automática por vários anos, defina um e-mail de registrante em outro domínio, consulte o registro RDAP para ver validade e status, e lembre que, após o vencimento, os registradores devem interromper a resolução antes da exclusão, e que os gTLDs oferecem 30 dias de período de resgate.
-
Por quanto tempo os clientes continuaram usando o endereço antigo após uma mudança de DNS, e quais resolvers ou clientes ignoraram o TTL?
Pergunta em aberto: a RFC 1035 define o TTL como o intervalo em que um registro pode ficar em cache antes de a fonte ser consultada de novo, e a RFC 8767 permite que resolvers sirvam dados expirados quando os servidores autoritativos estão inacessíveis. Após uma mudança real de registro com TTL reduzido, quanto tempo o tráfego para o endereço antigo persistiu, e quais resolvers, bibliotecas ou processos de longa duração causaram a cauda?
-
Autenticação de e-mail: SPF, DKIM e DMARC
O SPF lista os servidores autorizados a enviar e-mail em nome de um domínio, o DKIM assina as mensagens com uma chave do domínio e o DMARC define o que os receptores devem fazer quando ambos falham e para onde enviar relatórios; os três são registros TXT no DNS que precisam ser preservados quando outros registros mudam.
-
Autenticação de e-mail com SPF, DKIM e DMARC
O SPF (RFC 7208) define quais servidores podem enviar e-mails por um domínio, o DKIM (RFC 6376) assina as mensagens com uma chave publicada no DNS, e o DMARC (RFC 7489) determina o que os destinatários fazem em caso de falha e para onde enviam relatórios. Os três são registros TXT no DNS e precisam sobreviver a qualquer alteração de DNS.
-
www versus domínio apex: a restrição do CNAME, o escopo dos cookies e para qual redirecionar
O apex não pode ser um CNAME porque a RFC 1034 proíbe outros dados em um nó que tenha um, e o apex sempre contém registros SOA e NS; por isso, hospedar no endereço variável de um provedor exige registros A/AAAA ou um recurso do provedor, como o CNAME flattening. Cookies definidos no apex com o atributo Domain chegam a todos os subdomínios. Escolha uma forma, inclua ambas no certificado e redirecione a outra de forma permanente.
-
Diagnóstico de resolução de nomes em um host com systemd: resolvectl, resolv.conf, nsswitch e getent versus dig
Em um host com systemd-resolved, o /etc/resolv.conf geralmente só aponta para um stub listener local, os servidores DNS reais de cada link ficam no resolvectl, e o /etc/nsswitch.conf decide se o getent hosts chega a consultar o DNS. Confundir essas camadas explica a maioria dos relatos de "o dig funciona, mas a aplicação não".
Legível por máquina: JSON