Configuração do DNS da Hetzner para que o sítio Web, os subdomínios e o correio funcionem sem desvios e as alterações tenham efeito rapidamente. Neste guia, mostro-lhe as definições necessárias no DNS da Hetzner, uma configuração de exemplo experimentada e testada e métodos de teste práticos, para que possa evitar erros desde o início e manter a sua zona limpa.
Pontos centrais
Os seguintes pontos-chave dar-lhe-ão uma visão geral rápida do que é importante para uma zona DNS fiável.
- Servidor de nomes introduzir corretamente no registo
- A/AAAA para a Web, MX/TXT para correio
- TTL Selecionar adequadamente e aguardar a propagação
- SPF/DKIM contra spam e spoofing
- Monitorização e testes após alterações
O DNS em poucas palavras: o que é realmente necessário
Atribuo um domínio através de Registos destinos específicos para que os navegadores e os servidores de correio possam encontrar os meus serviços. A A-Record aponta para um endereço IPv4, um AAAA para IPv6 e um MX define a entrega de mensagens de correio eletrónico. Um CNAME forma um alias que aponta para um nome diferente, enquanto o TXT contém informações para SPF ou verificações. Uma linha de base limpa consiste em A/AAAA para o domínio principal, CNAME para www, MX para correio eletrónico e um SPF-TXT. Desta forma, mantenho a zona clara, de manutenção rápida e aberta a extensões posteriores.
Adicionar domínio à consola DNS da Hetzner
Na consola DNS, começo por criar um novo Zona e verifico se a ortografia do domínio está exatamente correta. Em seguida, ativo a manutenção manual do Registospara poder criar e alterar entradas específicas. Sugestão: tomo nota dos endereços IP e dos destinos de correio com antecedência para poder introduzir tudo sem interrupções. Desta forma, evito erros de digitação e coloco as entradas numa ordem calma. Assim que a zona está pronta, planeio a alteração dos servidores de nomes e as verificações subsequentes.
Introduzir corretamente o servidor de nomes no registo
Depois de criar a zona, introduzo o Servidor de nomes da Hetzner para que a administração seja centralizada na consola DNS. As entradas habituais são ns1.first-ns.de, robotns2.second-ns.de e robotns3.second-ns.com. Para domínios .de ou .at, configuro os meus próprios servidores de nomes com Registos de colapara que as referências e os IPs sejam armazenados. Se nunca tiver feito isto antes, pode encontrar os passos individuais no guia para Criar registos de cola. Depois, levo algum tempo a fazer a mudança, uma vez que a atualização pode chegar a velocidades diferentes em todo o mundo.
Exemplo de configuração: Tornar o sítio Web e o correio eletrónico executáveis
Para uma presença típica na Web, utilizo um A-Record para o domínio raiz, um CNAME para www e registos de correio adequados. Um SPF-TXT impede que servidores externos enviem mensagens de correio eletrónico em nome do domínio. Opcionalmente, adiciono um registo AAAA se o servidor Web IPv6 fornece. Para serviços de correio externos, como o ForwardMX, personalizo o MX e guardo as suas especificações. A tabela seguinte mostra um ponto de partida sólido para muitas configurações.
| Nome | Tipo | Valor | Nota |
|---|---|---|---|
| @ | A | 195.201.210.43 | Servidor Web IPv4 |
| @ | AAAA | Opcional: 2a01:4f8:xxxx:xxxx::1 | Servidor Web IPv6 |
| www | CNAME | @ | Alias na raiz |
| @ | MX | mx1.forwardmx.net | Prio 10 |
| @ | TXT | "v=spf1 include:_spf.forwardmx.net -all" | SPF contra falsificação |
Ativar o DNSSEC e definir o registo DS
Se a segurança da manipulação for importante para mim, ativo DNSSEC para a zona. Na consola da Hetzner, gero chaves de assinatura para este efeito e recebo as necessárias Dados DSque deposito no registo. Verifico se o algoritmo e o digest foram transferidos corretamente. Depois, espero até que a cadeia do agente de registo para a zona seja validada corretamente. Antes de grandes rotações de chaves, reduzo o TTL e planeio uma janela de tempo para que os resolvedores vejam as novas assinaturas atempadamente. Importante: se ocorrer um erro durante a alteração, as validações falham para os destinatários - por isso, tenho uma reversão pronta (não elimino as chaves antigas demasiado cedo) e testo com resolvedores de validação.
Definir corretamente o TTL e compreender a propagação
O TTL determina o tempo que os resolvedores colocam uma entrada em cache. Para conversões, escolho um curto TTL (por exemplo, 300 segundos) para que as alterações se tornem visíveis rapidamente. Após a configuração final, aumento novamente os valores para poupar pedidos e obter uma resolução consistente. Aqueles que implementam frequentemente gostam de se manter com 600-1200 segundos, enquanto aqueles que raramente fazem alterações utilizam 3600-14400. Uma visão geral prática da decisão é fornecida pelo meu olhar sobre o Seleção TTL óptima.
Domínio Apex, AAC e certificados sob controlo
Para objectivos SaaS em Zona Apex Lembro-me disso CNAME não é permitido em @. Por conseguinte, utilizo o A/AAAA do fornecedor ou defino um redireccionamento para www ao nível do servidor Web. Para a atribuição do certificado, controlo com Registos da CAAquais as AC que estão autorizadas a emitir certificados. Por exemplo, apenas mantenho a AC que efetivamente utilizo e, opcionalmente, adiciono um endereço de correio eletrónico para relatórios. Se eu mudar a CA, aumento brevemente o TTL e actualizo a CAA antes de emitir. Para wildcards através do ACME DNS-01, certifico-me de que os registos TXT sob _acme-challenge podem ser definidas rapidamente e limpas automaticamente para que não sejam deixados para trás desafios antigos.
Criar subdomínios e serviços de forma limpa
Para cada subdomínio, crio um A- ou CNAME-record, dependendo se o subdomínio aponta diretamente para um IP ou para um nome. Exemplo: blog.example.de como registo A para a VM do blogue, cdn.example.de como CNAME para um nome CDN. Para as APIs, faço uma distinção rigorosa entre nomes internos e públicos para evitar riscos. Nomes normalizados como api, app, img ajudam na manutenção e monitorização. Desta forma, mantenho a zona estruturada e posso atribuir claramente as alterações.
Curingas, SRV e tipos de registos especiais
Eu uso Registos de cartões selvagens (*.example.de), por exemplo, para configurações com capacidade para vários clientes. Certifico-me de que as entradas exactas têm sempre precedência sobre os wildcards. Para serviços como SIP, Matrix ou Autodiscover, crio Registos SRV e verificar o formato e as prioridades. Registos TXT com conteúdo longo (por exemplo, DKIM de 2048 bits) são divididos em vários segmentos de citação para que os analisadores possam fundi-los corretamente. Evito registos SPF múltiplos e combino entradas num SPF válido para não quebrar o limite de pesquisa.
Entrega fiável de correio eletrónico: SPF, DKIM e DMARC
Para uma mensagem de correio eletrónico fiável, utilizo o MX um SPF-TXT limpo que cobre os meus sistemas de envio. Também activei DKIM no serviço de correio utilizado e publicar o seletor DKIM como TXT em seletor._domainkey. Utilizo o DMARC para definir a forma como os destinatários tratam os e-mails que não passam no SPF/DKIM. Muitas vezes começo com "p=none", avalio os relatórios e depois mudo para "quarantine" ou "reject". Esta sequência reduz os riscos e aumenta gradualmente a qualidade da entrega.
Aprofundar o SPF/DKIM/DMARC na prática
Mantenho o FPS o mais reduzido possível: apenas o necessário incluir-e nunca mais do que um SPF por nome de anfitrião. Para respeitar o limite de 10 pesquisas no DNS, reduzo as cadeias ou utilizo mecanismos IP4/IP6 se forem estáveis. Para Rotação DKIM Utilizo dois selectores activos (antigo/novo), publico a nova chave, mudo o serviço de correio e só elimino a antiga após alguns dias. Com DMARC Inicialmente, defino os endereços de comunicação (rua/ruf) e verifico o alinhamento (aspf/adkim). Para subdomínios, posso utilizar sp= definir uma política separada se enviarem separadamente. Desta forma, reajo a dados de tráfego reais em vez de suposições.
DNS inverso (PTR) para uma entrega de correio limpa
Para além de MX, SPF e DKIM, configurei DNS inverso (PTR) para servidores de correio de saída. O PTR do IP aponta para um nome de anfitrião, que por sua vez resolve corretamente para o mesmo IP através de A/AAAA (Correspondência entre avanço e recuo). Defino o PTR por IP diretamente com o proprietário do IP (por exemplo, na interface do servidor) - não na gestão da zona do domínio. Utilizo o formato nibble para o IPv6. Um PTR adequado reduz as classificações de spam e ajuda na reputação. Se o correio for executado através de um serviço externo, deixo o seu PTR como está e evito fontes de remetente mistas sem a personalização do SPF.
Erros típicos e soluções rápidas
Se um domínio não for resolvido, verifico primeiro TTLentradas do servidor de nomes e a ortografia correta dos registos. O segundo olhar vai para o PropagaçãoAlguns resolvedores guardam mais tempo em cache, especialmente após o aumento do TTL. Comparo a resolução utilizando diferentes verificadores de DNS para reconhecer diferenças regionais. No caso de problemas locais, mudo temporariamente para resolvedores públicos, como 1.1.1.1 ou 8.8.8.8. Se o erro ocorrer apenas em redes internas, verifico os resolvedores internos e as regras nas configurações de contentores, Kubernetes ou CoreDNS.
Métodos de teste: dig, nslookup e end-to-end
Não testo apenas os registos, mas todo o percurso:
- escavação A/AAAA/CNAME/MX/TXT: Verificar respostas, TTL e autoridade
- dig +traceVer cadeia de delegação e comportamento do servidor de nomes
- Testes SMTPVerificar HELO/EHLO, TLS e banner
- HTTPS realCadeia de certificados, nome do anfitrião, redireccionamentos
Desta forma, também reconheço erros que não são visíveis em respostas DNS puras, como mapeamentos de VirtualHost incorrectos ou certificados expirados. Depois de efetuar alterações, espero pelo menos um TTL antes de tirar conclusões finais.
Trabalhar de forma eficiente com a consola Hetzner
Eu agrupo as actividades relacionadas Entradas tempo, defino um TTL curto antes de fazer grandes alterações e depois publico tudo de uma só vez. Antes de guardar, verifico novamente MX-prioridades, sintaxe SPF e o IP de destino do registo A. Para a administração e os processos do servidor, as instruções compactas em Dicas para robôs Hetzner. Após as implementações, testo http, https e mail com pedidos reais, não apenas através de ping. Isto permite-me reconhecer erros que as consultas DNS puras não mostram.
Automatização: API, modelos e ACME
Poupo tempo através da automatização. Para implantações regulares, eu uso o API da consola DNS para criar, alterar ou eliminar registos. Trabalho com modelos para padrões recorrentes (por exemplo, Web + Mail + DMARC) e apenas insiro valores específicos do projeto. Para o Let's Encrypt DNS-01, incluo um gravador de registos TXT automatizado e integro-o no fluxo de trabalho de renovação. Importante: Trato os tokens de API como senhas, atribuo-os a projetos específicos e revogo o acesso quando eles não são mais necessários.
Configurações avançadas: Split-Horizon, CDN e ACME
Separo utilizadores internos e externos, se necessário DNS-para que a aplicação interna aponte para IPs privados e os visitantes para destinos públicos. Devo usar um CDNRemeto os subdomínios para o nome da CDN através de CNAME e ativo o TLS aí. Para certificados automáticos via ACME/Let's Encrypt, opcionalmente defino desafios DNS-01 via TXT se HTTP-01 não corresponder. A automatização é importante aqui para que as renovações sejam efectuadas atempadamente. Os registos e as notificações ajudam a reconhecer as falhas em tempo útil.
Padrões de desempenho e disponibilidade
Aumento a disponibilidade com meios simples: Vários Registos A/AAAA (round robin) partilham a carga sem serviços adicionais, desde que os backends sejam stateless ou partilhem sessões. Durante a manutenção, removo temporariamente IPs individuais e, em seguida, aumento a entrada novamente. Uma execução TTL demasiado curta pode sobrecarregar os resolvedores; encontro um equilíbrio entre a velocidade de resposta e a taxa de acerto da cache. Defino processos claros para failovers sem controlos de saúde: No caso de uma falha, troco as entradas, monitorizo-as ativamente e reinicio-as novamente após a recuperação.
Segurança e higiene das zonas
Desativar desnecessários Transferências de zona (AXFR) e publicar apenas os NSque são verdadeiramente autoritários. Elimino regularmente subdomínios antigos ou órfãos para que não sejam criadas superfícies de sombra. Para IDNs, verifico o Código de pontuação-para evitar erros de digitação e de caracteres especiais. O acesso baseado em funções na consola garante que apenas as pessoas certas alteram as zonas. E, de forma bastante pragmática: documentei brevemente as alterações na ferramenta da equipa - isto reduz significativamente as consultas durante a operação.
Estratégia de migração e reversão
Antes de uma mudança, reduzo o TTL (24-48 horas antes), espelho todos os Registos na nova zona e testar a resolução diretamente através dos novos servidores de nomes. Só quando tudo estiver correto é que defino o parâmetro Servidor de nomes no registo. Após a delegação, monitorizo o tráfego e os erros. Se algo correr mal, reverto de forma controlada ou corrijo entradas individuais. Planeio as migrações DNSSEC de forma particularmente conservadora e deixo a cadeia de assinaturas antiga em vigor até que a nova esteja instalada de forma segura. Por fim, reponho o TTL para valores compatíveis com a produção.
Breve comparação entre fornecedores em termos de desempenho e flexibilidade
Desempenho, funções e Liberdade do DNS decidir a flexibilidade com que desenvolvo os projectos. Na prática, os grandes hosters fornecem sólidos Tempos de respostamas diferem em termos de funcionamento, funcionalidades e suporte. Avalio a seleção de acordo com o desempenho, a gama de funções, a qualidade da ajuda e as opções de DNS. A visão geral que se segue mostra uma imagem condensada que posso utilizar para tomar decisões. No final, o que conta é o que o meu projeto realmente precisa e não a maior lista de funcionalidades.
| Fornecedor | Desempenho | Âmbito das funções | Suporte | Flexibilidade do DNS | Classificação |
|---|---|---|---|---|---|
| webhoster.de | Elevado | Muito extensa | Topo | Máximo | 1 |
| Hetzner | Elevado | Extensivo | Bom | Elevado | 2 |
| Contabo | Médio | Padrão | O. K. | Médio | 3 |
Brevemente resumido
Estabeleci um Hetzner DNS-zona de uma forma estruturada: Criar zona, introduzir o servidor de nomes com o registador, definir os registos principais para a Web e o correio e, em seguida, testar. Com uma TTL Reduzo os tempos de mudança e aumento-os novamente após a conclusão para reduzir a carga. SPF, DKIM e DMARC reforçam a entrega e protegem o domínio contra utilização indevida. Mantenho os subdomínios consistentes e separo os destinos internos dos públicos. Com esta configuração de exemplo e as verificações diárias, a sua configuração de dns da hetzner permanece fiável, rápida e fácil de manter.
