--- id: "name-server" kind: "glossary-term" title: "servidor de nomes" language: "pt-BR" category: "DNS e fundamentos técnicos" updated: "2026-10-10T23:13:06Z" canonical: "https://tldlog.com/pt/glossario/servidor-nomes/" translations: en: "https://tldlog.com/glossary/name-server/" es: "https://tldlog.com/es/glosario/servidor-nombres/" de: "https://tldlog.com/de/glossar/nameserver/" fr: "https://tldlog.com/fr/glossaire/serveur-noms/" it: "https://tldlog.com/it/glossario/name-server/" ru: "https://tldlog.com/ru/glossariy/dns-server/" zh-Hans: "https://tldlog.com/zh/cihui/yuming-fuwuqi/" --- # servidor de nomes Servidor que armazena registros DNS e responde a consultas sobre nomes de domínio. Para que um domínio funcione, o registrador informa ao registro quais servidores de nomes guardam seus registros. Mudar os servidores de nomes de um domínio muda o lugar onde seu site e seu e-mail são encontrados. Um servidor de nomes é o computador que responde quando alguém pergunta onde estão o site ou o e-mail de um domínio. Todo domínio precisa ter pelo menos dois, e o registrador os informa ao registro. Se estiverem ausentes, errados ou desligados, o domínio deixa de funcionar, mesmo continuando registrado. ## O que um servidor de nomes faz pelo seu domínio As expressões “servidor de nomes” e “servidor DNS” cobrem duas funções. Os servidores autoritativos guardam os registros DNS de um domínio e respondem por ele; os resolvedores fazem essas perguntas em nome dos usuários. A RFC 9499 (março de 2024), o documento de terminologia do DNS, observa que ambos costumam ser chamados de servidores de nomes. Aqui o termo designa os autoritativos. A zona acima do domínio, mantida pelo registro do seu TLD, contém registros NS que indicam os servidores do domínio. Essa delegação diz aos resolvedores onde perguntar. O registrador envia esses nomes ao registro pelo EPP. Um domínio sem servidores de nomes fica com o status inactive e não resolve. A RFC 1034 (novembro de 1987) exige que toda zona esteja em pelo menos dois servidores, para que sobreviva à falha de um deles. O relatório SAC125 do SSAC (9 de maio de 2024) observa que os registros normalmente exigem pelo menos dois no registro do domínio e em cada atualização. ## Registrador, provedor de DNS e hospedagem: quem opera seus servidores de nomes Há três papéis envolvidos, que podem ser exercidos por uma empresa ou por três: - O registrador informa ao registro quais servidores de nomes o domínio usa. - O provedor de DNS opera esses servidores e a zona com os registros do domínio. Pode ser o registrador, uma empresa de hospedagem ou um especialista. - Os serviços de hospedagem de site e de e-mail operam os serviços para os quais os registros apontam. Trocar de provedor de DNS não muda o registrador: só são substituídos os servidores de nomes indicados para o domínio. ## Como trocar os servidores de nomes, passo a passo 1. Configure primeiro a zona no novo provedor de DNS, com todos os registros que o domínio usa, incluindo site e e-mail, e registros NS que correspondam aos novos servidores de nomes. 2. Se o domínio estiver assinado com DNSSEC, um registro DS que continue apontando para as chaves antigas pode fazê-lo falhar nos resolvedores que verificam assinaturas. Quando o operador antigo não coopera, a RFC 6781 descreve esta ordem: pedir a remoção do registro DS, trocar os servidores de nomes, esperar até que a mudança tenha se propagado pelo DNS e então acrescentar um registro DS para a zona recém-assinada. Até lá, o domínio não está protegido por DNSSEC. 3. Verifique se o domínio não está bloqueado contra atualizações: enquanto clientUpdateProhibited ou serverUpdateProhibited estiver ativo, o registro rejeita alterações. O registrador remove clientUpdateProhibited; serverUpdateProhibited (registry lock) só pode ser removido pelo registro, por meio do registrador. 4. Informe os novos servidores de nomes ao registrador, que os repassa ao registro. Indique pelo menos dois, de preferência em redes separadas. 5. Mantenha o serviço antigo funcionando por algum tempo: os resolvedores guardam cópias das respostas, por isso alguns visitantes chegam aos servidores antigos durante horas ou mais. Não apague a zona antiga no mesmo dia. Regras, bloqueios e prazos dependem do registro e do registrador, por isso consulte-os antes de alterar um domínio importante. ## Registros glue e servidores de nomes dentro do próprio domínio Considere example.com, com os servidores de nomes ns1.example.com e ns2.example.com. Para encontrar ns1.example.com, um resolvedor teria primeiro de perguntar aos servidores de nomes de example.com: justamente os servidores que está procurando. A saída é o registro glue: o registro publica os endereços IP desses servidores junto com a delegação. A RFC 9471 (setembro de 2023) torna esse glue obrigatório nas respostas de referência e observava então que os endereços (registros A e AAAA) eram o único tipo de glue definido. No registro, cada servidor de nomes é um objeto host. Como ns1.example.com fica sob example.com, o domínio precisa existir primeiro; depois o registrador cria o objeto host com seus endereços IP e vincula o domínio a ele. Os endereços só são exigidos quando o glue é necessário: se example.com usasse ns1.example.net, o registro do .com não precisaria de glue para ele. ## Servidores primários e secundários, e por que a redundância importa O servidor primário guarda a cópia da zona onde as alterações são feitas. Os servidores secundários a copiam por transferência de zona: uma transferência completa (AXFR) copia a zona inteira, uma incremental (IXFR) apenas o que mudou. O protocolo DNS UPDATE (RFC 2136), a parte padronizada do DNS dinâmico, acrescenta ou apaga registros sem editar a zona manualmente. Dois servidores são o mínimo, não a recomendação: a RFC 2182 (julho de 1997) adverte que, quando um falha, uma zona com apenas dois na prática passa a funcionar com um só. Ela recomenda três para a maioria das organizações, com pelo menos um bem distante dos demais, e quatro ou cinco para uma confiabilidade maior. Os requisitos técnicos da IANA (revisados pela última vez em 14 de novembro de 2024, em outubro de 2026) se aplicam apenas à zona raiz, ao .INT e ao .ARPA, mas servem como uma lista de verificação útil: pelo menos dois registros NS em endereços IP diferentes, servidores em pelo menos duas redes topologicamente separadas, respostas autoritativas e nenhum serviço recursivo. ## O que dá errado: delegações quebradas e servidores esquecidos A expressão inglesa “lame delegation” é usada para várias falhas: um servidor indicado que não responde, não pode ser alcançado ou responde com erro ou sem autoridade. A RFC 9499 recomenda termos mais específicos. Em todo caso, as consultas ficam lentas ou falham. Uma causa comum é o servidor esquecido: um titular deixa um provedor de DNS sem alterar os registros NS, e o domínio continua delegado a servidores que já não respondem por ele, o que pode abrir caminho para uma tomada de controle. Um risco menos visível: segundo o SAC125, a maioria dos registros se recusa a apagar um domínio expirado enquanto outros domínios dependem dele, e a RFC 5731 diz que ele não deve ser apagado até que seus objetos host sejam apagados ou renomeados. Alguns registradores os renomearam para outro domínio. O SAC125 os chama de servidores de nomes de sacrifício (sacrificial name servers), inseguros quando esse outro domínio pode ser registrado: quem o registrar controla a resolução de todos os domínios que ainda os usam. Em setembro de 2020, segundo o relatório, isso tinha exposto mais de 500.000 domínios de gTLDs ao risco de sequestro, e a resolução de mais de 163.000 tinha passado a controle não autorizado; o SAC125 observa que a extensão do problema nos ccTLDs é desconhecida. O relatório recomenda um código de conduta para registros e registradores; em outubro de 2026 não havia confirmação de nenhum código adotado. Renovar os domínios que hospedam seus servidores de nomes reduz esse risco. ## Fontes - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt) - [RFC 2182: Selection and Operation of Secondary DNS Servers](https://www.rfc-editor.org/rfc/rfc2182.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [Technical requirements for authoritative name servers (IANA)](https://www.iana.org/help/nameserver-requirements) - [SAC125: SSAC Report on Registrar Nameserver Management](https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-125-09-05-2024-en.pdf) ## termos relacionados - [servidor autoritativo](https://tldlog.com/pt/glossario/servidor-autoritativo/) - [registro NS](https://tldlog.com/pt/glossario/registro-ns/) - [registro glue](https://tldlog.com/pt/glossario/registro-glue/) - [DNS](https://tldlog.com/pt/glossario/dns/)