Conceitos de DNS Parte 2
Tipo de Registros DNS
A maioria das entradas nos arquivos de dados da zona é chamada de registros de recursos ou RR (Resource Record). Os tipos de registro DNS são registros que fornecem informações importantes sobre um nome de host ou domínio. Esses registros incluem o endereço IP atual de um domínio. Além disso, os registros DNS são armazenados em arquivos de texto (arquivos de zona) no servidor DNS autoritativo. O conteúdo de um arquivo de registro DNS é uma string com comandos especiais que o servidor DNS entende. Todos ou quase todos os registros de recursos recebem alguns parâmetros em comum, alguns RR recebem mais e outros menos.
| Registro | Descrição |
|---|---|
| SOA | Start of Authority - Indica onde começa a autoridade da zona. |
| NS | Name Server - Indica um servidor de nome para a zona. |
| A | Endereço IPv4. |
| AAAA | Endereço IPv6. |
| MX | Servidor de E-mail. |
| CNAME | Canonical Name - Mapeia um nome alternativo. |
| PTR | Pointer Record - É o reverso (tradução de nome para IP). |
| TXT | Permite incluir uma entrada de texto curto, mais usado para SPF. |
| SRV | Abreviação de SeRVice, permite definir localização de serviços disponíveis em um domínio, inclusive seus protocolos e portas (não é muito usado). |
| TLSA | É um mecanismo de autenticação de certificados digitais que é utilizado em conjunto com o protocolo de segurança TLS/SSL. |
Para descrever os RR vamos usar como base a configuração abaixo:
$ORIGIN exemplo.com.br.
$TTL 86400 ; tempo de vida padrão para todas as entradas de zona
@ IN SOA ns1.exemplo.com.br. hostmaster.exemplo.com.br. (
2023051600 ; sn (serial number)
3h ; refresh time
30m ; retry
3w ; expiry
3h ; nx
)
IN NS ns1.exemplo.com.br.
IN NS ns2.exemplo.com.br.
ns1 IN A 192.168.0.1
ns2 IN A 192.168.0.2
IN A 192.168.0.10
www IN A 192.168.0.100
ftp IN CNAME www
IN MX 10 exemplo.com.br
Tipo de Classes para Registros DNS
As seguintes classes de registros de recursos são atualmente válidas no DNS:
IN
O IN significa Internet. A única classe amplamente usada hoje.CH
O CH significa Chaosnet, um protocolo LAN criado no MIT em meados da década de 1970. Raramente foi usado para seu propósito histórico, mas foi reutilizado para as zonas de informações do servidor interno do BIND, geralmente é usada apenas por administradores de sistema para obter informações sobre o próprio servidor DNS. Algumas informações que podem ser obtidas com consultas DNS CH incluem:hostname
Consulta para obter o nome do servidor DNS.id
Consulta para obter o ID do processo do servidor DNS.version.server
Consulta para obter a versão do servidor DNS.version.bind
Consulta para obter a versão do BIND.authors.bind
Consulta para obter informações sobre os autores do BIND.
Lembrando que nem todo servidor vai responder as consultas acima.
$ dig -t txt -c chaos VERSION.BIND @a.dns.br +short
"NSD 4.6.1"
$ dig -t txt -c chaos version.server @a.dns.br +short
"NSD 4.6.1"
- HS
O HS significa Hesiod, um serviço de informação desenvolvido pelo Projeto Athena do MIT. Foi usado para compartilhar informações sobre vários bancos de dados de sistemas, como usuários, grupos, impressoras, etc.
Registros DNS em mais detalhes
Vamos nos aprofundar nos RR mais comuns. Para isso vamos usar o exemplo de arquivo de zona definido aqui.
TTL
O tempo de vida (TTL) não é um RR, mas controla o comportamento de um, por isso estou colocando ele aqui já que seu entendimento é de grande importância. O campo TTL de um RR é usado principalmente por resolvedores quando armazenam os RRs. O TTL descreve quanto tempo um RR pode ser armazenado em cache antes de ser descartado. Os três tipos de TTLs a seguir são usados atualmente em um arquivo de zona.
SOA mínimo
O último campo no SOA é o TTL de cache negativo (ou Negative caching TTL). Isso controla por quanto tempo outros servidores armazenam em cache as respostas de nenhum domínio (NXDOMAIN) desse servidor. Mais detalhes podem ser encontrados na RFC 2308. O tempo máximo para cache negativo é de 3 horas (3h).$TTL
A diretiva$TTLna parte superior do arquivo de zona (antes do SOA) fornece um TTL padrão para cada RR sem um conjunto específico de TTL, ou seja, será o valor padrão de TTL para todos os RR que não tiverem um definido explicitamente.RR TTLs
Cada RR pode ter um TTL, que normalmente é o segundo campo no RR, ele controla por quanto tempo outros servidores podem armazenar o RR em cache.
Todos esses TTLs são padronizados para serem especificados em segundos, embora as aplicações forneçam métodos de especificar de outras formas como 1h30m.
Quanto menor o TTL, mais frequentemente o servidor de nomes autoritativo será acessado, portanto, mais rapidamente as alterações se propagarão por vários caches externos. Por outro lado, quanto maior o TTL, mais tempo os registros inválidos podem ser mantidos em caches externos.
Cada consulta de um resolvedor para o servidor de nomes autoritativo também oferece a possibilidade de envenenamento de DNS. Em termos simples, quanto maior o TTL, menos frequentemente um conjunto de registros é lido e menor é a possibilidade de o cache ser envenenado.
ORIGIN
A diretiva $ORIGIN também não é um RR, mas como controla o comportamento ou a forma como é configurado um arquivo de zona resolvi colocar aqui. Essa diretiva define o nome de domínio que será anexado a qualquer RR não seja FQDN. Quando uma zona é lida pela primeira vez, há uma diretiva $ORIGIN <zone_name>. implícita (observe o ponto final).
Como na configuração base não foi usado . após os RR será adicionado o domínio ao RR como podemos ver abaixo:
# A configuração abaixo é muito usada:
$ORIGIN exemplo.com.br.
www IN A 192.168.0.100
www2 IN CNAME www
ftp IN A 192.168.0.101
# Ela é equivalente a configuração abaixo:
www.exemplo.com.br IN A 192.168.0.100
www2.exemplo.com.br IN CNAME www.exemplo.com.br
ftp.exemplo.com.br IN A 192.168.0.101
Observe que para isso ocorrer não pode ser adicionado o
.após o RR, caso seja adicionado, não será adicionado essa diretiva.
Se $ORIGIN não for definido, o servidor DNS usará o próprio nome de domínio como ponto de partida e anexará o nome fornecido na entrada da zona, para formar o nome de domínio totalmente qualificado. Por exemplo, se o servidor DNS tiver o nome de domínio dns.local, e for definido a entrada de zona como www IN A 192.168.1.1, o servidor DNS interpretará o nome da entrada de zona como www.dns.local.
SOA
O registro SOA também é um Resource Record, ele define características chave e alguns atributos importantes para a zona ou domínio. Abaixo vemos a sintaxe do SOA, mas normalmente ele é escrito com certa indentação que ajuda a identificar cada ponto.
name ttl class rr name-server e-mail sn refresh retry expiry min
Vejamos um exemplo do registro SOA:
@ IN SOA ns1.exemplo.com.br. hostmaster.exemplo.com.br. (
2023051600 ; sn (serial number)
3h ; refresh time
30m; retry = refresh retry
3w; expiry
3h; nx (nxdomain ttl)
)
| sintaxe | Descrição |
|---|---|
| name | No nosso caso estamos usando o símbolo @. É uma abreviação que significa o nome da zona definido no arquivo de configuração do servidor DNS. |
| ttl | Como não foi definido um valor ttl para o SOA, então será usado o valor da diretiva $TTL. Caso a mesma não seja definida, um valor padrão será usado. |
| class | IN significa que a classe é Internet (valor padrão se for omitido). Existem outros valores, mas raramente são usados. |
| rr | É o registro, nesse caso informa ser SOA. |
| name-server | Define o servidor DNS master primário para a zona. O servidor de nomes mencionado aqui também precisa ser definido usando um NS RR. Nas especificações de DNS, isso é chamado de campo MNAME. |
| Define um endereço de email administrativo para a zona. A RFC 2142 recomenda que o hostmaster seja usado, mas qualquer e-mail pode ser usado. O hostmaster é o remetente, o . após o hostmaster é substituído por @ e o restante permanece como está, ou seja, o e-mail será enviado para hostmaster@exemplo.com.br. Nas especificações de DNS, isso é conhecido como campo RNAME. | |
| sn | Define o número de série (ou SOA version como também é conhecido) atualmente associado à zona. O número de série deve ser atualizado sempre que houver qualquer alteração no domínio. Observe que sn pode receber qualquer número no intervalo de 0 a 4294967295.Por convenção um formato de data é usado com o formato aaaammddss, onde aaaa é o número do ano de quatro dígitos, mm é o mês , dd é o dia e ss é o número de sequência caso o arquivo de zona seja atualizado mais de uma vez por dia. |
| refresh | Quando se passar o tempo configurado nessa opção, o servidor DNS Slave para esta zona tentará ler o SOA RR do Master da zona. Se o valor sn no SOA RR do Master for maior do que o atualmente armazenado pelo Slave, uma operação de transferência de zona é iniciada para atualizar ou renovar a cópia dos registros da zona do Slave. Os valores típicos são de 3 a 24 horas. |
| retry | Define o intervalo de repetição em segundos se o Slave não conseguir fazer contato com o Master da zona durante um ciclo de atualização (refresh). Os valores típicos são de 10 a 60 minutos. |
| expiry | Define o tempo em segundos após o qual os registros da zona são considerados não mais autorizados. Isso significa que o servidor Slave não conseguiu se comunicar com o Master após refresh e continuou tentando (retry) e não obteve sucesso, nesse caso o Slave para de fornecer respostas autoritativas para a zona em questão, tornando ela expirada. Para permitir grandes interrupções, a expiração é normalmente definida para um valor muito alto, como uma a três semanas. |
| min | Se a zona expirar, esse será o tempo pelo qual um servidor "cache" armazenará a informação "NXDOMAIN", antes de iniciar uma nova busca recursiva. O máximo são 3 horas (também pode ser conhecido como Negative caching TTL). |
As características chave e atributos do SOA são padronizados na RFC 1035.
Reset do SOA
O campo de número de série do registro SOA segue uma convenção de formato de data aaaammddss, onde aaaa representa o ano com quatro dígitos, mm é o mês com dois dígitos, dd é o dia com dois dígitos e ss é um número de sequência de dois dígitos dentro do dia. Embora essa seja apenas uma convenção, o BIND e a maioria dos outros softwares de DNS não validam o formato desse campo. Portanto, é fácil introduzir erros e sair da sequência correta. Durante a transferência de zona de Master para Slave, somente ocorrerá se o número de série do registro SOA for maior do que o anterior.
Mas o que acontece se um valor incorreto for introduzido no campo SOA? Se estiver fora da sequência do dia ou se você precisar voltar a um valor anterior sem interromper a replicação? Para abordar essas situações, vamos considerar a data de hoje como 12 de junho de 2023 (número de série 2023061200). Se um número de série incorreto for inserido e for menor que a data atual, por exemplo, 2023061100, a correção é simples: basta corrigir o número de série e reiniciar o BIND ou recarregar a zona usando rndc.
No caso de um número de série muito alto, a solução dependerá de quão alto o número está e com que frequência o arquivo de zona é modificado. Suponha que o número de série tenha sido definido incorretamente como 2023062000 (ou seja, você adicionou 8 dias a mais). Para lidar com isso, a solução simples é aguardar até a data correta e não fazer mais modificações no arquivo de zona. Embora possa parecer simples ou até mesmo trivial, essa abordagem pode ser útil.
Caso ainda seja necessário redefinir o número de série SOA para um valor qualquer, é possível fazer isso. O número de série SOA é um campo não assinado de 32 bits com um valor máximo de 2³²-1, o que resulta em um intervalo de 0 a 4294967295 (observação: o valor zero pode ter um significado especial no DNS e deve sempre ser evitado). Portanto, o valor máximo do número de série SOA é 4294967295.
A correção do número de série é um processo simples, porém em duas etapas. Primeiro, altere o campo SOA para o valor máximo, 4294967295. Em seguida, reinicie o BIND ou recarregue a zona e verifique se a zona foi transferida para todos os servidores Slaves. Em seguida, defina o número de série SOA da zona com o valor correto e reinicie o BIND ou recarregue a zona novamente. A zona será transferida para os servidores Slaves porque o número de série ultrapassou zero, uma vez que 4294967295 é o valor máximo e a contagem reinicia em zero após esse ponto.
NS - Name Server
O registro NS define um servidor DNS autoritativo para a zona ou domínio. Abaixo vemos a sintaxe do NS:
name ttl class rr name
| sintaxe | Descrição |
|---|---|
| name | Este campo está em branco (pode ser um espaço ou um caractere de tabulação) e nesse caso representa o nome do domínio. Você também pode escrever este registro como exemplo.com.br. IN NS ns1.example.com., que pode ser menos confuso. |
| ttl | É o valor de TTL configurado apenas para esse RR. |
| class | IN significa que a classe é Internet. |
| rr | É o RR em sí, nesse caso é NS. |
| name | Define o nome do servidor DNS autoritativo para o domínio. |
Sobre o compo name:
# O nosso exemplo está configurado assim:
IN NS ns1.exemplo.com.br.
IN NS ns2.exemplo.com.br.
# Sua equivalência pode ser:
@ IN NS ns1.exemplo.com.br.
@ IN NS ns2.exemplo.com.br.
# Ou até mesmo:
exemplo.com.br. IN NS ns1.exemplo.com.br.
exemplo.com.br. IN NS ns2.exemplo.com.br.
MX - Mail Exchangers
O registro MX define os servidores de e-mail para um domínio ou zona. Abaixo vemos a sintaxe do MX:
name ttl class rr preference name
| sintaxe | Descrição |
|---|---|
| name | Define o domínio no qual terá o RR MX atrelado. |
| ttl | É o valor de TTL configurado apenas para esse RR. |
| class | IN significa que a classe é Internet. |
| rr | É o RR em sí, nesse caso é MX. |
| preference | Define a prioridade do servidor de email, quanto menor um número mais priorizado será aquele servidor de email (significa que sempre será usado o com menor número), os outros caso tenha mais de um, só serão usados caso o mais prioritário não responda. |
| name | É o nome do host que será o servidor de email, se estive em branco significa que o domínio será o servidor de email. |
Vejamos uma leve diferença em duas configurações que podem ocorrer:
# A configuração abaixo é a padrão para a maioria dos casos.
IN MX 10 exemplo.com.br.
# A configuração abaixo é equivalente a de cima (como já foi visto no $ORIGIN).
exemplo.com.br IN MX 10 exemplo.com.br.
A configuração acima informa que:
exemplo.com.br - É o nome do domínio. Poderia estar em branco, só deixei explicito para facilitar.IN - É o ttl para o RR.
MX - É o RR em sí.
10 - É a prioridade.
exemplo.com.br - É o servidor de email.
Note que as configurações abaixo possuem diferenças:
$ORIGIN exemplo.com.br.
mail IN MX 10 exemplo.com.br.
IN MX 10 exemplo.com.br.
No primeiro exemplo, mail é o nome do subdomínio que estamos declarando, isso pode ser tornar um erro se não nos atentarmos aos detalhes, esse subdomínio terá registros MX associados a ele, ou seja, ele será traduzido para mail.exemplo.com.br IN MX 10 exemplo.com.br, nesse caso o servidor de email está sendo configurado para mail.exemplo.com.br e não para exemplo.com.br como no segundo exemplo.
Uma outra técnica muito usada para esse tipo de registro é o Fail-Over. O Failover ou Fail-Over é um conceito que se refere à capacidade de um sistema alternar automaticamente para uma instância ou recurso de backup quando ocorre uma falha em uma instância principal. É uma estratégia utilizada para garantir a disponibilidade e a continuidade dos serviços sem interrupções.
Nesse nosso caso é para garantir que mais de um servidor de email esteja disponível usando o DNS. Vale ressaltar que para funcionar de acordo ambos os servidores de email (principal e backup) devem ser configurados de forma correta. Um exemplo de configuração seria:
; Configurando servidores de email:
IN MX 10 mx.maddogs.com.br
IN MX 20 mx1.maddogs.com.br
mx IN A 192.168.0.4
mx1 IN A 192.168.0.5
Se o servidor de e-mail principal (aquele com o menor número no campo preference) não estiver disponível, o e-mail será enviado para o segundo servidor, no caso o de backup, aquele com o próximo número mais alto em preference, que no nosso caso é 20. Caso os número em preference sejam o mesmos não será criado um sistema de instância principal e secundária (backup), será criado um sistema de balanceamento, onde cada servidor de email vai receber o email por vez, primeiro um servidor recebe, no próximo email ele será enviado para o outro servidor e assim por diante (isso requer que os servidores de email sejam configurados de acordo).
A - IPv4
O registro A define um endereço IPv4 de um host em particular no domínio ou zona. Abaixo vemos a sintaxe do A:
name ttl class rr ipv4
| sintaxe | Descrição |
|---|---|
| name | É o nome do host. |
| ttl | É o valor de TTL configurado apenas para esse RR. |
| class | IN significa que a classe é Internet. |
| rr | É o RR em sí, nesse caso é A. |
| ipv4 | É o endereço IPv4 do host. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
ns1 IN A 192.168.0.1
ns2 IN A 192.168.0.2
IN A 192.168.0.10
www IN A 192.168.0.100
AAAA - IPv6
O registro AAAA define um endereço IPv6 de um host em particular no domínio ou zona. Abaixo vemos a sintaxe do AAAA:
name ttl class rr ipv6
| sintaxe | Descrição |
|---|---|
| name | É o nome do host. |
| ttl | É o valor de TTL configurado apenas para esse RR. |
| class | IN significa que a classe é Internet. |
| rr | É o RR em sí, nesse caso é AAAA. |
| ipv6 | É o endereço IPv6 do host. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
ns1 IN AAAA 2001:db8::1
ns2 IN AAAA 2001:db8::12
IN AAAA 2001:db8:1:1
www IN AAAA 2001:db8:2:1
CNAME - Canonical Name
O registro CNAME define um alias para um host definido por um registro A ou AAAA. Abaixo vemos a sintaxe do CNAME:
name ttl class rr canonical-name
| sintaxe | Descrição |
|---|---|
| name | É o nome canônico ou alias. |
| ttl | É o valor de TTL configurado apenas para esse RR. |
| class | IN significa que a classe é Internet. |
| rr | É o RR em sí, nesse caso é CNAME. |
| canonical-name | Indica quem é o host que receberá um alias. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
www IN A 192.168.0.100
ftp IN CNAME www
Nesse caso ftp.exemplo.com.br é um alias que aponta para www.exemplo.com.br e o endereço IPv4 de www é 192.168.0.100.
O CNAME faz com que o servidor DNS tenha mais trabalho porque tanto o CNAME quanto o endereço IP do RR que aponta o CNAME devem ser pesquisados pelo servidor DNS.
Ao lidar com respostas grandes, isso pode fazer com que a resposta exceda o limite de 512 bytes de uma transação DNS UDP, reduzindo assim o desempenho.
O registro CNAME é frequentemente e comumente usados para mapear serviços como FTP, web e outros em um único host. Em geral, o único momento em que um CNAME deve ser usado é quando o host está em um domínio estrangeiro ou externo, como podemos ver no exemplo abaixo:
$ORIGIN exemplo.com.br
www IN A 192.168.0.100
ftp IN CNAME ftp.exemplo.net
PTR
O registro Pointer (também conhecido apenas como PTR) é usado apenas para zonas de mapeamento reverso, ou seja, mapeia endereços IP para nome de domínio. Abaixo vemos a sintaxe do PTR:
name ttl class rr name
| sintaxe | Descrição |
|---|---|
| name | Embora seja o IP, na verdade é tratado como um nome. |
| ttl | É o valor de TTL configurado apenas para esse RR. |
| class | IN significa que a classe é Internet. |
| rr | É o RR em sí, nesse caso é PTR. |
| name | É o nome que será retornado na consulta. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
100 IN PTR www
101 IN PTR ftp.exemplo.com.br.
TXT
O registro TXT tem sido historicamente utilizado para definir um texto genérico a ser associado a um nome. O texto em questão pode ser qualquer coisa que o usuário deseje. Esse tipo de registro teve um papel importante no desenvolvimento de iniciativas antispam, como o Sender Policy Framework (SPF), DMARC e DKIM. Essas iniciativas utilizam o registro TXT para transportar informações que auxiliam na validação do remetente, ajudando a prevenir o envio de Spams.
Exemplo de uso:
IN TXT "ALGUMA COISA"
Quanto mais registros TXT forem adicionados ao apex da zona, maior será o tamanho da resposta TXT. Essa expansão pode levar a respostas que ultrapassam o limite de 512 bytes UDP, o que pode representar um desafio para os clientes que não suportam EDNS0. Como resultado, pode ser necessário recorrer à comunicação TCP, o que aumenta a carga na rede e pode potencialmente causar indisponibilidade para esses clientes.
Em resumo, os pacotes DNS têm um limite de tamanho, comumente 512 bytes, para garantir que possam ser reconstituídos caso sejam fragmentados durante a transmissão. Isso é especialmente relevante em redes onde a fragmentação de pacotes pode ocorrer.
Com o uso do TCP no DNS, o tamanho do payloads pode ficar muito maior. O TCP entra em cena para transferências de zona e uso do DNSSEC. Porém, há muito mais latência quando o TCP está em uso, ao contrário do UDP, há um handshake entre o cliente e o servidor antes que qualquer dado comece a fluir. Para mais detalhes reveja Conceitos de DNS Parte 1 - O protocolo dns e para ainda mais detalhes, veja a documentação oficial.
SRV
O registro SRV (Service) é usados para mapear serviços em hosts, o intuito desse mapeamento é fornece balanceamento de carga usando um campo de prioridade e um campo de peso para controle refinado, além de fornecer capacidade de failover. Esse registro ainda não é amplamente suportado, com duas exceções: Lightweight Directory Access Protocol (LDAP) e o Protocolo de Iniciação de Sessão (SIP) usado em VoIP.
Abaixo vemos a sintaxe do SRV:
srvce.prot.name ttl class rr pri weight port target
| sintaxe | Descrição |
|---|---|
| srvce | O nome do serviço que está sendo mapeado. |
| prot | O protocolo utilizado pelo serviço (por exemplo, TCP, UDP). |
| name | O nome de domínio onde o serviço está sendo fornecido. |
| ttl | É o valor de TTL configurado apenas para esse RR. |
| class | IN significa que a classe é Internet. |
| rr | É o RR em sí, nesse caso é SRV. |
| pri | A prioridade do registro SRV. Valores menores indicam maior prioridade. |
| weight | O peso do registro SRV para balanceamento de carga. Quanto maior o peso, maior a probabilidade de ser selecionado. |
| port | A porta na qual o serviço está sendo fornecido. |
| target | O nome de domínio do host que fornece o serviço. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
_http._tcp IN SRV 0 5 80 www.exemplo.com.br.
# A saída abaixo é equivalente a de cima:
_http._tcp.exemplo.com.br IN SRV 0 5 80 www.exemplo.com.br.
Uma configuração para LDAP se parece assim:
$ORIGIN exemplo.com.br.
ldap1 IN A 192.168.0.12
ldap2 IN A 192.168.0.13
_ldap._tcp IN SRV 0 100 636 ldap1.exemplo.com.br.
IN SRV 0 100 636 ldap2.exemplo.com.br.
Como as opções de peso e prioridade são as mesmas, essa configuração vai servidor para fazer balanceamento de carga.
TLSA
O registro TLSA (Transport Layer Security Authentication) é usado para fornecer informações de autenticação e validação de certificados TLS/SSL (Transport Layer Security/Secure Sockets Layer). Esse registro permite que os administradores de domínio especifiquem como os clientes devem validar os certificados de um servidor contendo TLS/SSL.
Abaixo vemos a sintaxe do TLSA:
port.prot.name ttl class rr usage selector matching-type certificate
| sintaxe | Descrição |
|---|---|
| port | A porta na qual o serviço está sendo fornecido. |
| prot | O protocolo utilizado pelo serviço (por exemplo, TCP, UDP). |
| name | O nome de domínio onde o serviço está sendo fornecido. |
| ttl | É o valor de TTL configurado apenas para esse RR. |
| class | IN significa que a classe é Internet. |
| rr | É o RR em sí, nesse caso é TLSA. |
| usage | Especifica como o certificado deve ser usado. |
| selector | Determina como o certificado é identificado no registro TLSA. |
| matching-type | Especifica como o certificado fornecido no registro TLSA deve corresponder ao certificado apresentado pelo servidor. |
| certificate | Contém os dados relevantes para autenticar o certificado do servidor. |
Abaixo podemos ver os valores possíveis de configuração para usage:
| Opções de Usage | Descrição |
|---|---|
| 0 | Especifica um certificado CA ou chave pública que deve ser encontrado nos caminhos de certificação PKIX para o certificado de entidade final do servidor. Propósito: Restringe quais CAs podem emitir certificados para um serviço em um host. Requisitos: O certificado apresentado deve passar pela validação do caminho de certificação PKIX e um certificado CA correspondente ao registro TLSA deve ser incluído no caminho de certificação válido. |
| 1 | Especifica um certificado de entidade final ou chave pública que deve corresponder ao certificado de entidade final fornecido pelo servidor. Propósito: Limita qual certificado de entidade final pode ser usado por um determinado serviço em um host. Requisitos: O certificado de destino deve passar pela validação do caminho de certificação PKIX e deve corresponder ao registro TLSA. |
| 2 | Especifica um certificado ou chave pública que deve ser usado como âncora de confiança ao validar o certificado de entidade final fornecido pelo servidor. Propósito: Permite que um administrador de domínio especifique uma nova âncora de confiança, independentemente das âncoras de confiança dos usuários. Requisitos: O certificado de destino deve passar pela validação do caminho de certificação PKIX, com qualquer certificado correspondente ao registro TLSA considerado uma âncora de confiança para essa validação do caminho de certificação. |
| 3 | Especifica um certificado ou chave pública que deve corresponder ao certificado de entidade final fornecido pelo servidor. É o mais comum atualmente. Propósito: Permite que um administrador de domínio emita certificados para um domínio sem envolver uma CA de terceiros. Requisitos: O certificado de destino deve corresponder ao registro TLSA. A validação PKIX não é testada para essa opção de uso. |
Os usos de certificados definidos neste documento se aplicam explicitamente apenas a certificados formatados em PKIX na codificação DER X.690.
Abaixo podemos ver os valores possíveis de configuração para selector:
| Opções de Selector | Descrição |
|---|---|
| 0 | O certificado é fornecido diretamente no registro TLSA. |
| 1 | Um hash da chave pública do certificado é fornecido no registro TLSA. |
Abaixo podemos ver os valores possíveis de configuração para matching-type:
| Opções de Matching Type | Descrição |
|---|---|
| 0 | Toda a informação selecionada está presente nos dados de associação do certificado. |
| 1 | Um hash SHA-256 do certificado será usado. |
| 2 | Um hash SHA-512 do certificado será usado. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
_25._tcp.mail IN TLSA (3 1 1 8acf61b0fc1430213ea4cce35fe135b1594bdcfb0c79e8135b7558d739bfd800)
_443._tcp.www IN TLSA (3 1 1 8acf61b0fc1430213ea4cce35fe135b1594bdcfb0c79e8135b7558d739bfd800)
Para obter o hash do certificado, o mais correto é usar o script chaingen, esse script foi criado por Viktor Dukhovni. Para mais detalhes veja aqui.
Quem é Viktor Dukhovni?
O TLSA é descrito na RFC 6698.
Podemos testar o TLSA com o seguinte comando:
# O TLSA para o servidor de email ou para o servidor Web deve corresponder ao FQDN do servidor e não do domínio:
$ dig +dnssec +multi _25._tcp.mail.hermodr.com.br. TLSA
$ dig +dnssec +multi _443._tcp.www.hermodr.com.br. TLSA
Aplicações do registro TXT para servidores de e-mail
As opções apresentadas abaixo são criadas usando o registro TXT do DNS, suas aplicações são voltadas para servidores de email, como é muito comum ter que cadastrar eles no servidor de email, vou comentar em detalhes e o que são e quais são os campos e melhores técnicas de configuração.
SPF - Sender Policy Framework
O SPF é uma tecnologia utilizada no âmbito de servidores de e-mail que usa o DNS para combater a falsificação de endereços de retorno dos emails (return-path), ou seja, evita que outros domínios enviem emails não autorizados em nome de um outro domínio, basicamente evita o spoofing de e-mails (em outras palavras, evita spam). O SPF permite que os servidores de e-mail verifiquem se um determinado servidor tem permissão para enviar e-mails em nome de um domínio específico.
Funcionamento básico do SPF:
Um administrador de domínio define uma política SPF em seus registros DNS. Essa política especifica quais servidores de e-mail têm permissão para enviar e-mails em nome desse domínio.
Quando um servidor de e-mail de destino recebe uma mensagem de e-mail, ele verifica o SPF do domínio do remetente consultando os registros DNS desse domínio.
O servidor de e-mail de destino verifica se o servidor que enviou o e-mail está incluído na lista de servidores autorizados definida pelo SPF.
Com base na resposta do SPF, o servidor de e-mail de destino pode tomar diferentes ações. Se o servidor estiver autorizado, o e-mail será entregue normalmente. Caso contrário, ele pode ser marcado como spam ou até mesmo rejeitado.
Como foi dito, um domínio pode ou não autorizar que outros IP fora dele enviem e-mails em seu nome. O administrador configura esta relação na entrada TXT da zona de DNS seguindo as regras da RFC 4408. A entrada SPF pode ter 4 atributos diferentes que alteram o modo como o servidor de destino tratará mensagens enviadas de servidores que não estejam presentes na mesma.
O registro SPF possui a seguinte sintaxe:
v=versao Mecanismo_emissor Modificador-e-Mecanismo_basico
# Exemplo:
v=spf1 mx -all
Definições de Mecanismo
Como descrito na RFC 7208 existem dois tipos de mecanismos: Mecanismos de estrutura de linguagem básica e Mecanismos de remetente designado. Os Mecanismos básicos contribuem para a estrutura da linguagem e não especificam um tipo específico de esquema de autorização. Os mecanismos básicos são: all e include.
| Mecanismo básico | Descrição |
|---|---|
| all | O mecanismo all é usado como uma declaração final sobre como tratar as regras de autenticação SPF. Ele é colocado no lado mais a direita de um registro SPF e significa que sempre corresponde. Qualquer mecanismo colocado após o all nunca será testado. Exemplo: v=spf1 a mx -all. |
| include | O mecanismo include é utilizado no registro SPF para incluir as regras de autenticação SPF de outro domínio. Ele permite que você faça referência às configurações de autenticação SPF de um domínio específico e as aplique ao seu próprio domínio. Exemplo: v=spf1 include:exemplo.com -all.Ao permanecer dentro de uma autoridade administrativa, include geralmente não é a melhor escolha. Por exemplo, se exemplo.com.br e exemplo.org fossem gerenciados pela mesma entidade e se o conjunto permitido de hosts para ambos os domínios fosse mx:exemplo.com.br, seria possível para exemplo.org especificar include:exemplo.com.br, mas seria preferível especificar redirect=exemplo.com.br ou mesmo mx:exemplo.com.br.O modificador redirect é mais adequado para consolidar autorizações e políticas em um conjunto comum a ser compartilhado em um ADMD. O redirecionamento é muito mais como um elemento de código comum a ser compartilhado entre registros em um único ADMD. É possível controlar os hosts autorizados e a política para um número arbitrário de domínios a partir de um único registro. |
Já os Mecanismos de remetentes designados são usados para identificar um conjunto de endereços IP como tendo ou não permissão para usar o domínio para enviar e-mail. Os mecanismos emissores designados são os seguintes: a, mx, ptr (do not use), ip4, ip6 e exists.
| Mecanismo emissor | Descrição |
|---|---|
| a | É utilizado para verificar se um determinado endereço IP está incluído nos registros de endereço IP do nome de destino. Isso significa que o mecanismo a também considera registros AAAA, que são registros de endereço IPv6. Nesse caso, é feita uma busca de endereço usando o nome de destino usando o tipo de busca apropriado (A para IPv4 ou AAAA para IPv6) com base no tipo de conexão. O endereço IP resultante é comparado com o endereço IP fornecido. Se houver qualquer correspondência de endereço, o mecanismo a é considerado uma correspondência. |
| mx | O mecanismo mx é utilizado para verificar se um determinado endereço IP é um dos servidores MX (Mail Exchanger) de um nome de domínio especificado. Para verificar se um endereço IP está entre os servidores MX de um domínio, é realizado um processo de verificação. Primeiro, é feita uma busca de MX (Mail Exchanger) no nome de destino. Em seguida, é feita uma busca de endereço (address lookup) para cada nome de servidor MX retornado. O endereço IP fornecido é comparado com cada endereço IP retornado. Se o limite de busca de MX for excedido, será retornado um resultado "permerror" e a avaliação será encerrada. Se houver qualquer correspondência de endereço IP, o mecanismo "mx" é considerado uma correspondência. É importante observar que, se o nome de destino não tiver um registro MX, a função check_host() não deve aplicar as regras implícitas de MX descritas no RFC 5321, que envolvem a busca de registros A ou AAAA para o mesmo nome. |
| ptr (do not use) | Esse mecanismo testa se o mapeamento reverso de DNS para IP existe e aponta corretamente para um nome de domínio dentro de um domínio específico. Este mecanismo NÃO DEVE ser publicado. |
| ip4 e ip6 | Os mecanismos ip4 e ip6 no SPF são utilizados para testar se um determinado endereço IP está contido em uma determinada rede IP.No mecanismo ip4, é especificada uma rede IPv4 juntamente com um comprimento de prefixo CIDR opcional. O comprimento de prefixo CIDR indica quantos bits do endereço IP devem corresponder para que o mecanismo seja considerado uma correspondência. Se o comprimento de prefixo CIDR não for especificado, ele será assumido como /32.No mecanismo ip6, é especificada uma rede IPv6 juntamente com um comprimento de prefixo CIDR opcional. O comprimento de prefixo CIDR indica quantos bits do endereço IP devem corresponder para que o mecanismo seja considerado uma correspondência. Se o comprimento de prefixo CIDR não for especificado, ele será assumido como /128.O endereço IP fornecido é comparado à rede especificada. Se os bits de alta ordem do comprimento de prefixo CIDR corresponderem, o mecanismo será considerado uma correspondência. |
| exists | O mecanismo exists é utilizado para construir um nome de domínio arbitrário que é consultado no DNS. Ele permite esquemas complexos para determinar a permissão com base em partes específicas do envelope do e-mail. É útil para tomar decisões detalhadas com base no usuário e no endereço IP do cliente. |
Modificadores
No contexto do SPF os Modificadores são elementos adicionais que podem ser usados para alterar o resultado da avaliação de uma política SPF. Eles são usados para adicionar funcionalidades específicas ou personalizar o comportamento da política SPF.
Existem vários modificadores disponíveis no SPF, incluindo:
| Modificador | Descrição |
|---|---|
| redirect | É usado para redirecionar a consulta SPF para outro domínio. Ele permite consolidar autorizações e políticas em um conjunto comum compartilhado dentro de um único domínio. |
| exp | O modificador "exp" fornece uma explicação em caso de falha de autenticação SPF. Quando ocorre uma falha de autenticação, o modificador "exp" permite que o domínio forneça uma mensagem personalizada explicando o motivo da falha. |
| + (Pass) | Significa que o IP está autorizado a enviar mensagens em nome do domínio, sendo que o domínio consultado pode então ser considerado responsável pelo envio da mensagem. É o valor padrão, pode ser omitido. |
| – (Fail) | Significa explicitamente que o IP não está autorizado a enviar mensagens em nome do domínio consultado. Este resultado pode ser utilizado para rejeitar a mensagem. |
| ~ (SoftFail) | Deve ser tratado como um resultado intermediário entre os níveis fail e neutral. Neste caso, o domínio consultado informa que acha que o IP não está autorizado, mas que não pode fazer uma afirmação exata. A mensagem não deve ser rejeitada apenas com base neste resultado, mas é recomendável submetê-la a outros testes. |
| ? (Neutral) | O dono do domínio não tem como ou não quer definir se um determinado endereço IP está ou não autorizado a enviar mensagens em nome do domínio. Este resultado deve ser tratado exatamente como se não existisse um registro SPF. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
IN TXT "v=spf1 a mx ip4:192.0.2.32/27 -all"
IN TXT "v=spf1 a mx -all"
IN TXT "v=spf1 mx -all"
Nos exemplos acima, estabelecemos quem pode enviar mensagens em nome do domínio exemplo.com.br:
v=spf1 a mx ip4:192.0.2.32/27 -all
O endereço IP deve ser um RR tipo A ou MX do domínio exemplo.com.br ou deve pertencer ao bloco de endereços IP 192.0.2.32/27.v=spf1 a mx -all
O endereço IP deve ser um RR tipo A ou MX do domínio exemplo.com.br. Usado quando temos apenas um ou dois servidores de e-mail.v=spf1 mx -all
O endereço IP deve ser um RR tipo MX do domínio exemplo.com.br. Usado quando temos apenas um servidor de e-mail.
Outros dois exemplos interessantes para se analisar são:
v=spf1 a:clone.registro.br a:fe.registro.br a:mailx.registro.br -all
Encontrado no domínio registro.br. Para enviar e-mails em nome do domínio registro.br o endereço IP deve ser um RR tipo A para o subdomínio clone.registro.br (a:clone.registro.br) ou um RR tipo A para o subdomínio fe.registro.br (a:fe.registro.br) ou um RR tipo A para o subdomínio mailx.registro.br (a:mailx.registro.br).v=spf1 include:_spf.google.com ~all
Encontrado no domínio google.com. O include indica que está sendo incluído um mecanismo de autenticação SPF de outro domínio. Nesse caso, o domínio incluído é_spf.google.com. Isso significa que as regras de autenticação SPF definidas pelo Google serão aplicadas.~allindica uma "soft fail" ou seja, se a autenticação SPF falhar (o servidor de e-mail não corresponder às regras definidas), o e-mail não será imediatamente rejeitado, em vez disso, ele será aceito, mas pode ser marcado como suspeito ou tratado de forma diferente pelo servidor de e-mail de destino.v=spf1 -all
Deve ser usado para qualquer domínio que não tenha intenção de enviar e-mails, essa configuração é feita para evitar que e-mails falsos usando este domínio circulem na Internet para os outros domínio de forma ilegítima.v=spf1 exists:%(d) -all ext=spfblock.exemplo.com.br
Essa configuração indica que o servidor de email deve verificar se o domínio atual possui registros DNS válidos (exists:%(d)). Se não houver registros válidos ou se o servidor de envio não estiver autorizado, o email será rejeitado (-all). A extensãospfblock.exemplo.com.bré aplicada (ext=spfblock.exemplo.com.br), mas sua função exata precisa ser definida pela implementação específica do domínio "exemplo.com.br", ou seja, precisa ser definida em outro registro, como podemos ver abaixo:
spfblock IN TXT "O email de %{s} usando o servidor SMTP em %{I} foi rejeitado por %{c} (%{r}) em %{t} \
porque falhou na verificacao de registros SPF para o dominio %{p}.
O contra-barra é usado para quebrar linhas na definição do TXT.
%{s}= Substituir pelo endereço de e-mail do remetente.
%{I}= O IP do remetente.
%{c}= O IP do MTA receptor.
%{r}= O nome do host, normalmente o mesmo que o MTA receptor.
%{t}= Define o timestamp atual.
%{p}= O nome de domínio validado.%{d}= É o domínio do remetente, conforme especificado no endereço de e-mail.%{h}= É o nome do host (domínio) no endereço do remetente.%{l}= É o nome local (a parte anterior ao "@" no endereço de e-mail) do remetente.%{o}= Substituído pela versão do protocolo SMTP usado para enviar o e-mail (por exemplo, "smtp" ou "esmtp").%{v}= Substituído pelo valor da versão SPF que está sendo usado (por exemplo, "spf1").
A cláusula -all informa que devem ser recusados (O - é prefixo de Fail) e-mails partindo de qualquer outro endereço IP (all).
Considerações
Usar a ao invés de ip4 ou ip6 permite que os hosts sejam renumerados facilmente ao custo de uma consulta de DNS por receptor, ou seja, o RR A pode apontar para qualquer endereço IP sem ter que alterar o registro SPF. Usar mx sobre a permite que o conjunto de hosts de e-mail seja alterado facilmente, ou seja, podemos modificar apenas o RR MX sem alterar o RR A. Mas só devemos criar registros SPF com A ou MX se tais alterações forem comuns, se não forem é melhor usar os mecanismos que consomem menos recursos, como ip4 e ip6 ao invés de a ou mx.
A publicação de registros SPF para domínios que não enviam e-mails é uma prática recomendada bem estabelecida. O registro de um domínio que não envia e-mail é:
$ORIGIN exemplo.com.br
www IN TXT "v=spf1 -all"
O registro SPF acima indica que nenhum servidor de e-mail está autorizado a enviar e-mails em nome do subdomínio
www.exemplo.com.br(indica isso porque não temAnemMX). O modificador-allindica que qualquer tentativa de envio de e-mail usando esse subdomínio deve ser considerada não autorizada.
O registro SPF padrão para um host individual envolvido no processamento de e-mails é:
$ORIGIN exemplo.com.br
relay IN TXT "v=spf1 a -all"
O registro SPF acima indica que apenas o endereço IP (RR A) do host
relay.exemplo.com.brestá autorizado a enviar e-mails em nome do domínio exemplo.com.br. Cuidado, se não for especificado o nome do host (relayno nosso exemplo) a diretivaano registro SPF especifica que o endereço IP do servidor atual do domínio (Similar aexemplo.com.br. IN A 192.168.0.10) está autorizado a enviar e-mails em nome do domínio.
$ORIGIN exemplo.com.br
IN TXT "v=spf1 a -all"
Como não há um nome de host específico no registro acima, o registro SPF se aplica diretamente ao domínio exemplo.com.br como um todo, sem restrição a um host específico. Nesse caso, qualquer endereço IP (RR A) associado ao domínio exemplo.com.br está autorizado a enviar e-mails em seu nome.
$ORIGIN exemplo.com.br
IN TXT "v=spf1 mx -all"
Isso indica que apenas os servidores de e-mail listados nos registros MX (RR mx) do domínio exemplo.com.br estão autorizados a enviar e-mails em nome desse domínio.
Além disso, podemos minimizar os recursos necessários para busca de SPF usando diretivas que requerem menos informação DNS colocando mecanismos de baixo custo no início do registro SPF. Por exemplo, considere um domínio configurado como abaixo:
exemplo.com.br. IN MX 10 mx.exemplo.com.br.
IN MX 20 mx2.exemplo.com.br.
mx.exemplo.com.br. IN A 192.0.2.1
mx2.exemplo.com.br. IN A 192.0.2.129
O Melhor registro SPF se da pela configuração abaixo:
exemplo.com.br. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"
Essa configuração é eficiente porque não requer consultas adicionais ao servidor DNS para determinar quais hosts são permitidos.
Um bom registro
$ORIGIN exemplo.com.br.
@ IN TXT "v=spf1 a:authorized-spf.exemplo.com.br -all"
authorized-spf IN A 192.0.2.1
IN A 192.0.2.129
Essa configuração permite um controle mais granular sobre quais hosts estão autorizados a enviar e-mails e associa explicitamente os endereços IP autorizados ao host
authorized-spf.exemplo.com.br. Essa verificação requer apenas uma consulta DNS adicional para obter o endereço IP. Uma vez que o endereço IP é obtido, não são necessárias consultas adicionais para verificar a autorização SPF.
Registro caro
exemplo.com.br. IN TXT "v=spf1 mx:exemplo.com.br -all"
Essa configuração especifica que apenas servidores
mxdo domínioexemplo.com.br(mx:exemplo.com.br) podem enviar emails em nome do domínioexemplo.com.br.
Podemos consultar o campo TXT com o seguinte comando:
$ dig txt hermodr.com.br +short
"v=spf1 mx -all"
DKIM - DomainKeys Identified Mail
O DKIM (DomainKeys Identified Mail) é um método de autenticação de e-mails que utiliza criptografia assimétrica (também conhecida como chave pública) para adicionar uma assinatura digital ao cabeçalho de cada e-mail enviado. Essa assinatura é gerada pelo servidor de envio com uma chave privada exclusiva para o domínio do remetente, enquanto a chave pública correspondente é publicada nos registros DNS do domínio.
Uma consulta DNS é usada para ler o registro DKIM TXT, que contém, entre outros campos, uma chave pública no domínio construído. A chave pública obtida é então usada para validar tanto a integridade da assinatura do DKIM quanto autenticar o remetente de e-mail. As chaves públicas usadas na verificação da assinatura (que são armazenadas em registros DKIM TXT) são geradas pelo administrador do servidor de email, as chaves podem ser geradas usando o OpenSSL. O OpenDKIM é outra ferramenta utilizada para gerar as chaves e configurações para o DKIM e funciona por meio da interface milter. Ainda é possível utilizar o DKIM diretamente do rspamd.
Além de um registro DKIM TXT, as especificações DKIM permitem que o proprietário do domínio defina um registro ADSP TXT (Author Domain Signing Policies), que fornece essencialmente orientações ao receptor de e-mail sobre o que fazer se um item de e-mail não estiver assinado.
Selectors
É um nome qualquer usado para identificar diferentes chaves públicas, já que várias chaves públicas podem ser usadas. Por exemplo, os selectors podem ser nomes (por exemplo, "saopaulo", "teste" e "producao"), mas o mais comum seria usar uma data (por exemplo, "20230217").
Subdomínio _domainkey
Em sistemas DKIM, as chaves DKIM são geralmente armazenadas em um subdomínio especial chamado _domainkey. Vamos usar o domínio de exemplo exemplo.com.br e o seletor 20230217 como exemplo. Quando um cabeçalho de email contém um campo DKIM-Signature, a tag d= indica o domínio do remetente, que, no nosso caso, é exemplo.com.br. A tag s= indica o seletor, que identifica a chave pública DKIM específica relacionada a esse domínio. No exemplo, o seletor é 20230217.
Para encontrar a chave pública DKIM correta, é necessário fazer uma consulta DNS específica. Essa consulta é feita concatenando o seletor (no nosso caso, 20230217) com o subdomínio especial _domainkey e o domínio do remetente (exemplo.com.br). Portanto, a consulta DNS correspondente será feita para o domínio 20230217._domainkey.exemplo.com.br. Nesse domínio específico, espera-se encontrar o registro DNS contendo a chave pública DKIM necessária para verificar a autenticidade do email.
DKIM Specific Text
O DKIM possui alguns tipos de dados específicos na formatação do TXT RR, vamos entender melhor como são e como funcionam.
| Opções | Descrição |
|---|---|
| v=(versão) | É opcional. Define o número da versão DKIM e só pode usar o valor padrão DKIM1. É uma boa prática incluí-lo. |
| g=(granularidade) | É opcional. Define a parte do usuário (local) do endereço de e-mail (tudo à esquerda do @) ao qual este DKIM TXT RR se aplica.O padrão é g=* (todos os endereços de usuários). Este valor, após qualquer processamento curinga, deve corresponder exatamente ao endereço na parte From: do usuário (local) do cabeçalho. |
| h=(hash do algoritmo) | É opcional. Define um ou mais algoritmos de hash separados por dois pontos (:) que serão usados com a finalidade de criar assinaturas digitais (em conjunto com k=) abrangendo um ou ambos os cabeçalhos de correio definidos ou o corpo do correio (incluindo, opcionalmente, anexos MIME).Os valores permitidos são do conjunto sha1 e sha256, sendo sha1 não recomendado para uso. O padrão é h=* (significa qualquer). Exemplo de uso: h=sha1:sha256;, h=sha256; ou h=*; |
| k=(algoritmo de chave) | É opcional. Define o algoritmo de chave pública que está sendo usado. O padrão é k=rsa. Como rsa é o único algoritmo atualmente suportado, ele pode ser omitido com segurança. |
| n=(anotações) | É opcional. Define o texto legível por humanos. |
| p=(chave pública) | É obrigatório. Define a chave pública (no formato base64) para o algoritmo definido pela tag k=. Os dados para a chave pública podem ser criados pelo OpenSSL. |
| s=(tipo de serviço) | É opcional. Define o tipo de serviço ao qual o DKIM é aplicado. Neste momento, o único valor válido é email. O padrão é s=*. |
| t=(flags) | É opcional. O padrão é nenhum sinalizador definido. Duas bandeiras estão definidas atualmente: y: Indica o modo de teste. Se definido, gera mensagens de diagnóstico adicionais do receptor de validação, mas ainda permite que o validador trate o e-mail normalmente. s: Se definido, esse sinalizador indica que essa chave não é válida para subdomínios do nome de domínio. Se os subdomínios nunca forem usados em endereços de e-mail de domínio, esse sinalizador deve ser definido como uma proteção adicional. |
O DKIM usa o TXT RR para passar as informações corretas ao servidores de e-mail. Essa parte de texto pode conter vários campos como tag=value separados por ponto e vírgula (;). Pode haver um ou mais DKIM TXT RRs para qualquer domínio. O formato do TXT e DKIM TXT RR, definido pela RFC 4817 e 5672, é:
selector._domainkey.domain-name. ttl class rr DKIM-specific-text
| sintaxe | Descrição |
|---|---|
| selector | Nome do selector. |
| _domainkey | Subdomínio especial chamado _domainkey. |
| domain-name | O nome de domínio onde o serviço está sendo fornecido. Deve ficar em branco ou receber um nome de domínio para configurar o DKIM para um subdomínio. |
| ttl | É o valor de TTL configurado apenas para esse RR. |
| class | IN significa que a classe é Internet. |
| rr | É o RR em sí, nesse caso é TXT. |
| DKIM-specific-text | É o texto fornecido no formado específico do DKIM. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
20230217._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAmzMcpQnEJkasvTPYXc3NEGwX9v1NNwPDE0VdRvv4CGsRdXBIBThr5eEcxGm7TwxNBXciIMGFIf0ZQK/3pnNZ6yKyssiNK7rIehxZD4zFoRljY37oFqvTG8T6ZvhT21gQqaFMatRlnCVATph9a2WF8/NhxHiZaF/jTOulzo0cjroDx+jyrBtmb5qBeTEaWT/aD+89bb3RXpWpCk"
"6/yNLbw6TGBz9gqtuL0RWHBJzDLuBHMFbRsRkQxxOoxZ6uEIvIeEEhdKZuu2zm+CY4bk5uoddTu+ikA7dCgksudvB4SEOcnqvYwsXbVf1bXGsGCdQIaBWd7a1KoihoUfdhLsLb6YfGA+O0bZo2msumS+u8hNrnirLEa+YZ2LUJ0/69wygm5Iixe6pN0uCe5XCaNIz248hSjZ7IN88Lw3S0VSHnEQvQAq1wjYMWqfXUuFrdKra29npY4Qdv"
"lcyv1IrDfX+yd6LrhmdPiEJvJu50NeSu6aXlCn1kRb6oVWic7hMmnjpTd05cT6CGAZGCGAEB9oOESP5x8Yu2zxxD1I7oRDNSfyQ0mASIWHOvln36dPRolw1xG3IX0X2DC/k4QCuCof6pDjrmX2kKUIuvYcVaea/HM9maP78xNesacxuEI5F6WyNGt3sgRsKBMDZfaz7kajDhBTThF14ErE3dFHIvSoiQ1JECAwEAAQ==" ) ; ----- DKIM key 20230217 for exemplo.com.br
Agora para colocar no servidor DNS, você deve colocar tudo numa única linha e não coloque aspas ", exemplo caso use o site registro.br:
20230217._domainkey IN TXT v=DKIM1; k=rsa; p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAmzMcpQnEJkasvTPYXc3NEGwX9v1NNwPDE0VdRvv4CGsRdXBIBThr5eEcxGm7TwxNBXciIMGFIf0ZQK/3pnNZ6yKyssiNK7rIehxZD4zFoRljY37oFqvTG8T6ZvhT21gQqaFMatRlnCVATph9a2WF8/NhxHiZaF/jTOulzo0cjroDx+jyrBtmb5qBeTEaWT/aD+89bb3RXpWpCk6/yNLbw6TGBz9gqtuL0RWHBJzDLuBHMFbRsRkQxxOoxZ6uEIvIeEEhdKZuu2zm+CY4bk5uoddTu+ikA7dCgksudvB4SEOcnqvYwsXbVf1bXGsGCdQIaBWd7a1KoihoUfdhLsLb6YfGA+O0bZo2msumS+u8hNrnirLEa+YZ2LUJ0/69wygm5Iixe6pN0uCe5XCaNIz248hSjZ7IN88Lw3S0VSHnEQvQAq1wjYMWqfXUuFrdKra29npY4Qdvlcyv1IrDfX+yd6LrhmdPiEJvJu50NeSu6aXlCn1kRb6oVWic7hMmnjpTd05cT6CGAZGCGAEB9oOESP5x8Yu2zxxD1I7oRDNSfyQ0mASIWHOvln36dPRolw1xG3IX0X2DC/k4QCuCof6pDjrmX2kKUIuvYcVaea/HM9maP78xNesacxuEI5F6WyNGt3sgRsKBMDZfaz7kajDhBTThF14ErE3dFHIvSoiQ1JECAwEAAQ==
Para criar a chave privada usando o comando openssl com tamanho de 1024 bits, use o comando abaixo:
openssl genrsa -out dkim.private 1024
Agora vamos extrair a chave pública no formato PEM:
openssl rsa -in dkim.private -out dkim.public -pubout -outform PEM
cat dkim.public
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY-----
Podemos configurar no DNS da seguinte forma:
# Formato de uma única linha:
selector._domainkey IN TXT "v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB"
# Formato de várias linhas:
selector._domainkey IN TXT ("v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM"
"oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R"
"tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI"
"MmPSPDdQPNUYckcQ2QIDAQAB")
ADSP - Author Domain Signing Practices
O ADSP usa o TXT RR para permitir que um domínio indique suas políticas de assinatura de e-mail. O ADSP TXT RR é opcional, mas as políticas de ADSP podem ser usadas para ajudar um MTA de recebimento de validação a determinar como lidar com correspondência que não está assinada.
Existem três políticas possíveis definidas pelo ADSP.
| Política | Descrição |
|---|---|
| none | Indica que o domínio não possui uma política de assinatura específica. |
| unknown | O endereço de email do domínio pode ou não assinar todos os emails. Usado para testes. |
| discardable | Indica que o domínio assina seus emails, mas considera as assinaturas como opcionalmente válidas. Isso significa que o domínio não rejeitará emails caso as assinaturas DKIM falhem, mas eles ainda podem ser aceitos se todas as outras verificações forem bem-sucedidas. |
| all | Indica que o domínio considera as assinaturas DKIM obrigatórias para todos os seus emails. Se um email do domínio não passar na verificação da assinatura DKIM, ele deve ser rejeitado pelo servidor de destino. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
_adsp._domainkey IN TXT "dkim=all;"
DMARC - Domain-based Message Authentication, Reporting, and Conformance
O DMARC (Domain-based Message Authentication, Reporting, and Conformance) é um protocolo de validação de emails que ajuda a combater fraudes por email e phishing. Ele funciona em conjunto com dois outros protocolos de segurança de email, SPF (Sender Policy Framework) e DKIM (DomainKeys Identified Mail).
Resumindo o que cada protocolo faz:
- SPF verifica se o email foi enviado de um servidor autorizado a enviar emails pelo domínio do remetente.
- DKIM adiciona uma assinatura digital criptografada ao email, garantindo que o conteúdo não foi alterado durante o envio.
O DMARC é um protocolo que reúne esses dois métodos e ainda define uma política para o receptor, incluindo a informação sobre falhas na autenticação por SPF ou DKIM, instruções sobre como lidar com e-mails não autenticados e a capacidade de fornecer relatórios aos administradores de e-mail sobre a atividade de envio de e-mail do domínio.
Resumindo:
- Informar se o email falhou na autenticação por SPF ou DKIM.
- Instruir o receptor sobre o que fazer com o email não autenticado (colocá-lo na spam, rejeitá-lo, etc.).
- Fornecer relatórios aos administradores de email sobre a atividade de envio de email do seu domínio, mesmo que venha de fontes não autorizadas.
Com o DMARC implementado, você tem mais controle sobre quem pode enviar emails usando o seu domínio e recebe relatórios sobre tentativas de fraude. Isso ajuda a proteger a reputação do seu domínio e dificulta que golpistas usem seu nome para enviar emails maliciosos.
Veja um exemplo de como configurar o DMARC:
_dmarc.hermodr.com.br IN TXT "v=DMARC1; p=reject; rua=mailto:postmaster@hermodr.com.br"
A política
pespecifica a ação a ser tomada com os emails que não passam na autenticação. A opçãononeé recomendada para começar, permitindo que os emails passem mesmo que não sejam autenticados.O campo
ruaespecifica um endereço de email para o qual relatórios de falhas DMARC serão enviados.
Podemos testar o DMARC com este site! ou usando o comando abaixo:
dig TXT _dmarc.hermodr.com.br
Recursos avançados de DNS
Neste tópico dos recursos avançados do DNS, mergulharemos em conceitos cruciais como TSIG, TKEY, DNSSEC entre outros. Essas tecnologias não apenas reforçam a segurança do DNS, mas também proporcionam autenticação e integridade aos dados. Vamos desvendar cada um desses aspectos em detalhes.
TSIG - Transaction Signature
O TSIG (Transaction SIGnatures) é um mecanismo para autenticar mensagens DNS, originalmente especificado no RFC 2845. Ele permite que as mensagens DNS sejam assinadas criptograficamente usando um segredo compartilhado. O TSIG pode ser utilizado em qualquer transação DNS como uma maneira de restringir o acesso a certas funções do servidor (por exemplo, consultas recursivas) para clientes autorizados quando o controle de acesso baseado em IP é insuficiente ou precisa ser anulado.
Além disso, pode ser usado para garantir a autenticidade das mensagens quando isso é crucial para a integridade do servidor, como em mensagens de atualização dinâmica ou transferências de zona de um servidor primário para um secundário. O TSIG foi desenvolvido para aprimorar a segurança durante a transferência de zona, criando uma autenticação no nível da transação. A garantia fornecida pelo TSIG pode ser usada para consultas, transferências e atualizações.
O TSIG utiliza uma combinação de segredos compartilhados e hash unidirecional para confirmar se o host que está fazendo a requisição está autorizado a acessar os dados. Somente quem possui essa chave estará autorizado. Permitir TSIG entre servidores primários e secundários já cria uma boa camada de proteção. Além disso, é crucial adicionar transferências baseadas em IP, ou seja, permitir transferências apenas para endereços conhecidos e utilizar ACL para facilitar.
Anteriormente, o utilitário dnssec-keygen era utilizado para gerar as chaves TSIG. Esse utilitário gerava dois pares de chaves, mas para o TSIG, apenas um era utilizado. Após a versão 9.15 do BIND, foi adicionado um utilitário exclusivo para gerar chaves TSIG.
Inicialmente, é necessário gerar uma chave secreta. Essa chave pode ser criada manualmente (precisando estar codificada em base 64) ou gerada de diversas formas, incluindo pelo servidor BIND.
TKEY
O TKEY (Transaction KEY) é um mecanismo usado para negociar automaticamente um segredo compartilhado entre dois hosts (usa uma única chave compartilhada entre os hosts), originalmente especificado no RFC 2930. Existem vários "modos" TKEY que especificam como uma chave deve ser gerada ou atribuída.
O BIND 9 implementa apenas um desses modos: a troca de chaves Diffie-Hellman. Ambos os hosts devem ter um registro KEY com o algoritmo DH (embora este registro não seja obrigatório estar presente em uma zona). O processo TKEY é iniciado por um cliente ou servidor enviando uma consulta do tipo TKEY para um servidor que suporta TKEY.
A consulta deve incluir um registro KEY apropriado na seção adicional e deve ser assinada usando TSIG ou SIG(0) com uma chave previamente estabelecida. A resposta do servidor, se bem-sucedida, contém um registro TKEY em sua seção de resposta. Após essa transação, ambos os participantes têm informações suficientes para calcular um segredo compartilhado usando a troca de chaves Diffie-Hellman.
O segredo compartilhado pode então ser usado para assinar transações subsequentes entre os dois servidores. As chaves TSIG conhecidas pelo servidor, incluindo as chaves negociadas pelo TKEY, podem ser listadas usando rndc tsig-list. As chaves negociadas pelo TKEY podem ser excluídas de um servidor usando rndc tsig-delete. Isso também pode ser feito via protocolo TKEY, enviando uma consulta TKEY autenticada especificando o modo de "exclusão de chave".
SIG(0)
O BIND oferece suporte parcial às assinaturas de transação DNSSEC SIG(0), conforme especificado no RFC 2535 e RFC 2931. SIG(0) utiliza chaves pública/privada para autenticar mensagens. O controle de acesso é realizado da mesma maneira que com as chaves TSIG; privilégios podem ser concedidos ou negados em diretivas ACL com base no nome da chave.
Quando uma mensagem assinada por SIG(0) é recebida, ela só é verificada se a chave é conhecida e confiável pelo servidor. O servidor não tenta buscar recursivamente ou validar a chave. A assinatura SIG(0) de fluxos TCP de várias mensagens não é suportada. A única ferramenta fornecida com o BIND 9 que gera mensagens assinadas por SIG(0) é o nsupdate.
Resumindo a sopa de letras
No TKEY, a geração da chave é um processo automático de negociação entre os dois hosts envolvidos. Aqui, a troca de chaves é facilitada por um processo de negociação, e a chave compartilhada é gerada automaticamente durante essa negociação.
Ao contrário do TSIG, onde precisamos gerar manualmente uma chave compartilhada e distribuir ela para os servidores envolvidos. Com o TKEY, eliminamos a necessidade de gerar manualmente a chave compartilhada. O processo Diffie-Hellman key exchange é usado para que os dois hosts concordem e gerem uma chave compartilhada de forma segura e automática.
DNSSEC
O DNSSEC (Domain Name System Security Extensions) é uma extensão do protocolo DNS que permite a verificação da autenticidade e integridade das respostas DNS. O DNSSEC fornece uma camada adicional de segurança para o DNS, ajudando a prevenir ataques de cache poisoning e outras formas de falsificação de DNS. Ao usar o DNSSEC, o servidor DNS pode assinar digitalmente as informações de zona usando uma chave criptográfica privada. Essa chave privada é mantida pelo servidor DNS autoritativo e é usada para criar uma assinatura digital para cada registro de recurso na zona. Essa assinatura digital é então armazenada na zona de DNS.
Para que outras pessoas possam verificar a autenticidade das informações de zona, o servidor DNS autoritativo também fornece uma chave pública correspondente à chave privada usada para assinar a zona. Essa chave pública é armazenada em um registro DNS especial chamado DNSKEY. O DNSKEY pode ser incluído na zona de DNS ou em uma zona delegada separada.
Os servidores DNS recursivos que desejam verificar a autenticidade das informações de zona podem usar a chave pública do DNSKEY para verificar as assinaturas digitais dos registros de recursos na zona. Se a assinatura for válida, o servidor DNS recursivo pode ter mais confiança na precisão das informações de DNS.
No DNSSEC, existem dois tipos de chaves usadas em operações de assinatura de zona:
Zone Signing Key (ZSK):
- Assina conjuntos de registros (RRsets) dentro da zona.
Key Signing Key (KSK):
- Assina os registros DNSKEY da zona (incluindo a ZSK).
- A assinatura gerada pela KSK é um RRSIG sobre o RRset de DNSKEYs,
- A KSK é validada indiretamente por uma assinatura feita pela KSK da zona pai, por meio de um registro DS (Delegation Signer).
- O DS é assinado pela KSK da zona pai, o que acaba criando uma cadeia de confiança (Chain of Trust).
- Pode ser usada fora da zona como uma âncora confiável (Trust Anchor) em um resolver.
- Assina os registros DNSKEY da zona (incluindo a ZSK).
A distinção entre ZSK e KSK é baseada no uso, não na definição. O campo de flags no registro DNSKEY é usado para identificar ZSK (flags 256) e KSK (flags 257). O uso da KSK (Key Signing Key) ou ZSK (Zone Signing Key) no DS (Delegation Signer) depende da política de assinatura de chaves implementada no sistema de segurança de domínio DNSSEC. Mas em geral, o DS deve ser gerado a partir da KSK.
É possível usar uma abordagem simplificada onde uma única chave desempenha os papéis de KSK (Key Signing Key) e ZSK (Zone Signing Key). Essa configuração é conhecida como "Combined Key", "Combined Signing Key" ou "Single Key" (embora este último não seja um termo amplamente reconhecido em especificações formais). Se você usar apenas uma chave para assinar tanto o DNSKEY quanto a zona inteira, essa chave desempenharia ambos os papéis. É importante notar que, ao fazer isso, se perde a melhoria da segurança no DNSSEC.
O RR (Resource Record) DNSKEY é um tipo de registro usado no DNSSEC para armazenar a chave pública associada a zona DNS. Quando você assina uma zona com DNSSEC, o processo de assinatura gera automaticamente os registros RRSIG, que são as assinaturas digitais, e inclui os registros DNSKEY correspondentes às chaves usadas na assinatura.
Esses registros DNSKEY são extraídos dos arquivos de chave .key gerados previamente com dnssec-keygen (ou automaticamente pelo BIND nas versões mais novas). Ou seja, você primeiro gera suas chaves KSK e ZSK (ou uma única chave se estiver usando o modelo Combined), e depois, ao assinar a zona, o conteúdo dessas chaves é inserido como registros DNSKEY dentro do arquivo de zona assinado.
Cada registro DNSKEY contém, essencialmente, quatro componentes: o campo de flags (que indica se a chave é uma KSK ou ZSK), o protocolo (que sempre tem valor 3), o algoritmo criptográfico (como RSA/SHA-256, ECDSA, etc.) e a própria chave pública. Por exemplo:
example.com. 3600 IN DNSKEY 257 3 8 AwEAAaxxxxxxxxxxxxxxxxxxxxxx...
Nesse exemplo, 257 indica que a chave é uma KSK. Se fosse 256, seria uma ZSK. O valor 3 é fixo e reservado para DNSSEC. O 8 indica o algoritmo usado (neste caso, RSA/SHA-256), e a sequência longa é a chave pública codificada em base64.
Esse registro é essencial porque permite que validadores reconstituam a assinatura digital da zona e verifiquem sua autenticidade e integridade. Ele também serve como base para gerar o hash usado no registro DS, que é publicado na zona pai para formar a cadeia de confiança.
CSK - Combined Signing Key
A CSK (Combined Signing Key) significa chave de assinatura combinada. É um tipo de chave que pode assinar ambos os registros DNS e as próprias chaves de assinatura DNS (chaves ZSK e KSK).
Existem dois modelos principais de chaves usados no DNSSEC:
- Modelo ZSK/KSK (Chave de assinatura de zona / Chave de assinatura de chave):
- Neste modelo, duas chaves separadas são usadas:
- ZSK (Zone Signing Key): Assina os registros DNS reais dentro de uma zona (como registros A, MX, etc.).
- KSK (Key Signing Key): Assina as chaves ZSK para fornecer uma camada adicional de segurança.
- Neste modelo, duas chaves separadas são usadas:
- Modelo CSK (Combined Signing Key):
- Neste modelo, uma única chave serve para ambos os propósitos:
- Assinar os registros DNS da zona.
- Assinar outras chaves DNS (incluindo chaves ZSK adicionais, se houver).
- Neste modelo, uma única chave serve para ambos os propósitos:
Aqui está uma tabela resumindo as diferenças:
| Modelo | Chaves | Descrição |
|---|---|---|
| ZSK/KSK | ZSK, KSK | Duas chaves separadas: ZSK assina registros DNS, KSK assina ZSK. |
| CSK | CSK | Chave única que assina registros DNS e outras chaves DNS. |
NSEC3
NSEC3, ou "Next Secure version 3", é uma extensão do protocolo DNS (Domain Name System) que visa aumentar a segurança contra ataques de enumeração de zona, um tipo de ataque no qual um invasor tenta obter informações sobre os registros de recursos em uma zona DNS. Especificamente, o NSEC3 é projetado para mitigar ataques de dicionário, nos quais um invasor tenta descobrir registros de recursos gerando nomes de domínio possíveis e consultando a zona DNS para verificar sua existência.
O NSEC3 introduz o conceito de "hashing salgado" (salted hashing) nos registros de NSEC (Next Secure) para tornar mais difícil a previsão dos nomes de domínio seguintes na sequência. O salt (sal) é um valor aleatório adicionado ao processo de hash, o que impede que os atacantes usem tabelas de precomputação (rainbow tables) para reverter os hashes e descobrir a estrutura da zona DNS.
NSEC vs NSEC3
Uma das diferenças importantes entre NSEC e NSEC3 é que o NSEC pode permitir a enumeração dos registros presentes na zona, enquanto o NSEC3 foi projetado especificamente para tornar a enumeração mais difícil.
A enumeração de registros presente na zona com o uso do NSEC acontece porque os nomes de domínio são listados diretamente nos registros NSEC, o que pode permitir que um atacante reconstrua a estrutura da zona e enumere os registros presentes. Por outro lado, o NSEC3 utiliza hashes criptográficos dos nomes de domínio, dificultando a enumeração direta dos registros, pois os nomes originais não são visíveis nos registros NSEC3.
Se deseja ocultar a listagem dos domínios em sua zona, a adoção do NSEC3 pode fornecer um certo grau de privacidade adicional. No entanto, ainda existe a possibilidade de alguém adivinhar nomes de domínio na sua zona, como consultando por ftp ou www, semelhante ao tradicional DNS inseguro.
Caso sua zona tenha muitas delegações e precise ter a opção de opt-out para conservar recursos, o NSEC3 é mais indicado. Em cenários diferentes, o NSEC é geralmente preferível para a maioria dos administradores de zona, uma vez que reduz a carga sobre os servidores autoritativos, pois não requer as operações criptográficas adicionais do NSEC3, sendo também mais fácil de diagnosticar em comparação com este último.
Para verificar qual deles uma zona está usando basta rodar o comando abaixo:
# Verificar se o domínio hermodr.com.br usa NSEC ou NSEC3:
dig @8.8.8.8 hermodr.com.br +do NSEC | grep -E 'IN NSEC|IN NSEC3'
;hermodr.com.br. IN NSEC
H3S228UKUJDLTGAOH81BDSD70R9MT34G.hermodr.com.br. 21600 IN NSEC3 1 0 0 - K650UHNT84REQ59EKCRV169HGCU19QIN A NS SOA TXT AAAA RRSIG DNSKEY NSEC3PARAM CDS CDNSKEY
# Verificar se o domínio wlf.eti.br usa NSEC ou NSEC3:
dig @8.8.8.8 wlf.eti.br +do NSEC | grep -E 'IN NSEC|IN NSEC3'
;wlf.eti.br. IN NSEC
wlf.eti.br. 60 IN NSEC ns1.wlf.eti.br. A NS SOA AAAA RRSIG NSEC DNSKEY CDS CDNSKEY
RRSIG - Resource Record Signature
É a assinatura de um RRset. RRset é um conjunto de registros na base de dados DNS com mesmo nome, classe e tipo. Esta assinatura é a garantia de que as informações enviadas sobre um domínio são verdadeiras. Isso é possível em função da utilização de criptografia assimétrica. No momento em que se gera um record RRSIG, é definido o intervalo de validade inicial e final.
DNSKEY
O registro DNSKEY é a chave criptográfica pública que é usada para verificar a autenticidade e a integridade das informações contidas em um domínio, seja para KSK ou ZSK. Na configuração padrão do DNSSEC, quando estamos usando as chaves ZSK (Zone Signing Key) e KSK (Key Signing Key), a DNSKEY refere-se à chave pública da KSK.
A ZSK não é usada no DS porque ela é uma chave de curto prazo. Pode ocorrer de acabar usando a ZSK se a assinatura da zona tiver apenas uma única chave (o que não é muito comun). Isso significa que a ZSK pode ser alterada com uma frequência maior, o que tornaria a troca do DS muito mais trabalhosa.
A ZSK é usada para assinar os dados dentro da zona.
DS - Delegation Signer
O registro DS é um registro DNS específico que faz parte do processo de delegação de chaves no DNSSEC. O DS é utilizado para estabelecer uma cadeia de confiança entre zonas DNS. Por exemplo, vejamos o caso do domínio hermodr.com.br. A zona com.br possui DNSSEC, para que possamos confiar na assinatura que é feito na zona hermodr, tem que ter um elo de confiança entre com.br e hermodr, para isso se usa o registro DS, que é chave pública da KSK (Key Signing Key), a chave usada para assinar a chave ZSK, que tem a tarefa de assinar a zona. O registro DS deve estar na zona pai e é usado para validar a autenticidade da assinatura quando fazemos uma consulta com DNSSEC ativo.
Rollover de chaves
Em termos geral, "rollover" pode ser entendido como a troca de algo por outra coisa de mesmo tipo ou equivalente. No quesito DNS e mais especificamente DNSSEC, o rollover de chaves refere-se ao processo de trocar ou atualizar as chaves criptográficas usadas para assinar zonas DNS. Embora as chaves KSK (Key Signing Key) e ZSK (Zone Signing Key) não expirem, o processo de rollover de chaves é uma prática recomendada por várias razões relacionadas à segurança.
Ou seja, deve ser criado uma política de troca dessas chaves por questões de segurança. O método de troca deve ser seqguido de forma a não comprometer a cadeia de confiança (Chain of Trust)
Troca de chaves - método Pré-Publicação
Este método permite a introdução simples de uma ou mais novas chaves no conjunto de registros DNSKEY na zona pai antes de serem utilizadas. Sua inclusão na zona antes do uso garante que as chaves apropriadas estarão eventualmente disponíveis no cache de todos os resolvers validadores quando a chave for finalmente rotacionada. Isso significa que a zona é reassinada com a nova ZSK e/ou KSK, mantendo as chaves antigas na zona pai, mesmo que aparentemente não desempenhem nenhuma função. Para ilustrar esse processo, assume-se que todos os TTLs para uma zona assinada são de 24 horas (86400 segundos).
Pelo menos dois dias (2 x TTL) antes do vencimento das assinaturas da zona (pode ser a qualquer momento anterior, se necessário), uma nova ZSK ou KSK seria adicionada ao conjunto de registros DNSKEY na zona pai. A zona é reassinada usando a chave(s) atual(is), não a nova. O novo registro DNSKEY não é utilizado para assinar a zona de nenhuma maneira.
Após 24 horas (1 x TTL), pode-se garantir que todos os caches em resolvers terão o novo conjunto de registros DNSKEY contendo tanto as chaves atuais quanto as novas. Os registros RRSIG para quaisquer tipos de registros (RR) nesses caches terão sido assinados com as chaves atuais, não as novas.
Neste ponto, a zona pode ser reassinada usando a nova chave ou chaves. A chave antiga é mantida no conjunto de registros DNSKEY.
A partir deste ponto e pelas próximas 24 horas, os registros RRSIG associados a qualquer RR solicitado, como o RR A para www.example.com, podem ser assinados com a chave antiga, se o RR já estiver no cache, ou a nova chave, se tiver expirado do cache ou não estiver disponível no cache e precisar ser obtido do servidor autoritário. Lembre-se de que os padrões exigem que todas as chaves disponíveis sejam tentadas antes de rejeitar qualquer dado como falso. Em ambos os casos, um registro DNSKEY que validará com sucesso os dados RR solicitados estará presente no cache, ou se o conjunto de registros DNSKEY tiver expirado ou não estiver presente, poderá ser solicitado ao servidor autoritário.
Para mais detalhes consulte aqui.
Troca de chaves - método Double-Signature
Nesse método, temos que adicionar uma nova KSK (Key Signing Key) no conjunto de registros DNSKEY (adicionar) e assinaremos o ZSK (Zone Signing Key) com ambos os KSKs atual ("antigo") e o novo KSK. Aguarde o tempo de TTL da DNSKEY, depois basta substituir o registro DS na zona superior com o novo DS. Os resolvers terão ambos os KSKs em cache (depois de esperar o TTL), e a cadeia de confiança pode ser validada usando o novo DS (âncora de confiança) no zone superior.
Trust Anchor
A Trust Anchors é uma chave criptográfica confiável que serve como ponto inicial seguro para a validação de assinaturas DNSSEC. Nos estágios iniciais da adoção do DNSSEC, não era incomum que um resolvedor de validação tivesse mais de uma âncora de confiança. Antes da assinatura da zona raiz do DNS (período antes de 2010), a zona raiz não tinha uma chave de trust anchor disponível publicamente para ser usada pelos resolvedores de validação DNSSEC. Como resultado, os administradores de sistemas precisavam configurar manualmente as chaves de confiança para as zonas específicas que desejavam validar.
Por exemplo, antes da zona raiz ser assinada, os resolvedores de validação que desejavam validar nomes de domínio na zona .gov precisavam obter e instalar a chave para .gov. Hoje em dia, apenas a chave da zona raiz precisa estar de fato configurada na Trust Anchor. A Trust Anchor (Âncora de Confiança) é principalmente usada em ambientes de resolução DNS recursiva e em implementações que fazem cache de respostas DNS, se você tem um servidor autoritativo, não precisa se preocupar com Trust Anchor mas sim com Chains of Trust.
A âncora de confiança é geralmente associada ao DS (Delegation Signer) da zona raiz, todo servidor DNS que deseja habilitar DNSSEC precisa ter essa DNSKEY. Essa chave serve como ponto de confiança para construir a cadeia de confiança DNSSEC. Podemos consultar a DNSKEY da raiz com o comando abaixo:
dig @8.8.8.8 . DNSKEY +dnssec +short
;; ANSWER SECTION:
. 7116 IN DNSKEY 256 3 8 AwEAAentCcIEndLh2QSK+pHFq/PkKCwioxt75d7qNOUuTPMo0Fcte/Nb wDPbocvbZ/eNb5RV/xQdapaJASQ/oDLsqzD0H1+JkHNuuKc2JLtpMxg4 glSE4CnRXT2CnFTW5IwOREL+zeqZHy68OXy5ngW5KALbevRYRg/q2qFe zRtCSQ0knmyPwgFsghVYLKwi116oxwEU5yZ6W7npWMxt5Z+Qs8diPNWr S5aXLgJtrWUGIIuFfuZwXYziGRP/z3o1EfMo9zZU19KLopkoLXX7Ls/d iCXdSEdJXTtFA8w0/OKQviuJebfKscoElCTswukVZ1VX5gbaFEo2xWhH J9Uo63wYaTk=
. 7116 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU=
. 7116 IN RRSIG DNSKEY 8 0 172800 20240322000000 20240301000000 20326 . R5YR1P8DCGZkCbuqP+lqjd8KwdHHgIZVu10OMX6+1CT11KrRkamJsGq+ 20/WiyiYT8Etcwe1GJZ+51DoCWy1vln+7RXAhsgLv+RV9HAkJSZ0bXqK 9yDmPvufS+VcZPvkoA1Ajmj6oHMo1TlDoWbKtifFuA0J3O9gEhDn/rD5 RuPNQIkcTMdFbVBsROZbBXeNz1vDp68oRxGS8kvzWo3FEyV/A9kbEli8 0IoIST+3D6opZvWSQw33bkwpo2icELYK+olUV1bxSrVWxqGl7PwLcJef JJZWo6XUmFsfh+4T88ETDbRWORpRMCb3nFxma3UQp45mNdJXit+k+cJd ounuLA==
Podemos ver as chaves ZSK (flags 256) e KSK (flags 257), e a assinatura da DNSKEY (RRSIG), essa assinatura tem o ID 20326 (ou keytag). O DNSKEY que queremos é da KSK (usada no registro de DS):
# Vou deixar separado por partes:
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=
# O comando abaixo no servidor DNS mostra a Trust Anchor que ele possui:
named -C
.
.
.
trust-anchors {
# This key (20326) was published in the root zone in 2017.
. initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
R1AkUTV74bU=";
};
.
.
.
Perceba que é o mesma keytag 20326 e o hash é o mesmo.
Chains of Trust
A confiabilidade de uma zona de DNS com DNSSEC depende da cadeia de confiança (Chains of Trust) que se inicia na zona raiz, passa pelas zonas pai e filhas e termina na zona final que está sendo consultada. As chaves ZSK e KSK são usadas em diferentes pontos da cadeia de confiança e têm funções distintas no processo de assinatura de uma zona.
No DNSSEC, cada resolver só precisa confiar em uma entidade (o servidor DNS raiz). O resolver já possui a chave do servidor raiz em seu arquivo. Portanto, após receber a resposta, o resolver a compara com a chave que já tem em seu arquivo. Se uma das chaves na resposta corresponder àquela em arquivo, podemos confiar na resposta do servidor raiz. Isso estabelece uma "cadeia de confiança" no DNSSEC, permitindo-nos confiar em .org e, por conseguinte, em isc.org.
Sempre que temos um domínio e desejamos ter DNSSEC, devemos garantir a Chains of Trust, colocando a chave pública (DNSKEY) no registro DS da zona pai, dessa forma mantemos a cadeia de confiança para validação de DNSSEC.
Para resumir, Trust anchor é a DS da KSK do servidor dns raiz e Chain of Trust é o DS da KSK que devemos colocamos na zona pai.
ECS
O ECS é uma extensão do DNS padrão. É um campo que, se habilitado pelo DNS, permite com que seja mais rápido responder às requisições, já que é possível fazer um balanceamento de carga, load balancing, para uma rede no próprio DNS. Então, você se conecta apenas ao servidor geograficamente mais próximo de você.
Porém, isso pode trazer algumas implicações de segurança, já que está revelando de qual local você está fazendo a requisição. Essa informação é aproximada a uma cidade ou bairro, então não contém seu endereço em si, mas revela algumas informações.
DNS sobre HTTPS e DNS sobre TLS
Quase todas as consultas DNS são enviadas sem criptografia, a menos que seja realizado algum esforço para que isso não ocorra, o que não é padrão da maiorias das empresas que operam um servidor DNS.
O fato de as respostas e consultas DNS trafegarem em texto simples torna o DNS vulnerável a interceptações por um atacante que tenha acesso ao canal de rede, o que diminui a privacidade do solicitante.
Tanto o SSL (Secure Sockets Layer) e TLS (Transport Layer Security) são protocolos de segurança que criptografam a comunicação entre um cliente (como um navegador da web) e um servidor (como um site).
O DNS sobre HTTPS e o DNS sobre TLS é uma forma de criptografar a informação para que trafegue de forma segura na Internet. Assim, independente de quem esteja analisando o tráfego de uma rede, podendo ser outros dispositivos ou até mesmo o provedor, não terão acesso às informações.
DoH - DNS over HTTPS
O DNS sobre HTTPS (ou mais conhecido como DoH) é descrito na RFC 8484 e define um mecanismo para permitir que mensagens DNS sejam transmitidas em mensagens HTTP protegidas com TLS. As mensagens DoH são enviadas na porta 443 (TCP) e normalmente usam um servidor web ou uma biblioteca específica para responder as requisições em formato HTTPS.
A implementação do DoH no BIND é baseada na biblioteca nghttp2. Com isso o servidor HTTP/2 é integrado ao BIND, projetado especificamente para atender consultas de DNS sobre HTTPS.
Detalhando um pouco
O DoH criptografa o tráfego DNS e requer autenticação do servidor; O servidor DNS com o qual você está se comunicando precisa provar sua identidade, ele faz isso antes de estabelecer a conexão, o seu dispositivo normalmente verifica se o servidor é quem diz ser utilizando certificados digitais.
O DoH fornece proteções semelhantes ao DoT (DNS sobre TLS), enquanto os métodos tradicionais baseados em UDP e TCP são vulneráveis a esses ataques, já que a menssagem não é criptografada.
O uso da porta HTTPS padrão (443) e a capacidade de misturar tráfego DoH com HTTPS comum dificultam a interferência não autorizada nos dados DNS e tornam a análise de tráfego mais difícil, já que são confundidas com requisições Web comuns.
Embora o formato de mensagem DNS não contenha identificadores de cliente, o DoH introduz novas considerações de privacidade, como cookies HTTP e impressões digitais de cabeçalhos de solicitação HTTP. No entanto, as implementações DoH compartilham as propriedades de privacidade das camadas subjacentes, como IP, TCP e TLS.
No nível IP, o endereço do cliente pode ser usado para correlacionar solicitações, mas medidas como NAT, proxy ou VPN podem mitigar isso. O DoH não introduz preocupações de privacidade significativamente novas além das associadas ao uso do HTTPS.
DoT - DNS over TLS
O DNS sobre TLS (ou mais conhecido como DoT) é descrito na RFC 7858 e também define um mecanismo para permitir que mensagens DNS sejam transmitidas criptografadas, mas não por meio de menssagens HTTPS, ou seja, não precisa executar um servidor Web assim como DoH é executado no BIND. O DoT usa por padrão a porta 8443.
Como a porta para o DoT é exclusiva para essa função, pode acabar chamando atenção para os pacotes que estejam trafegando nessa porta, mesmo que não seja possível acessar o conteúdo deles. Em contrapartida o protocolo HTTPS passa pela porta 443, fazendo com que as requisições DNS não sejam percebidas.
Resumindo
Apesar de DoH e DoT usarem TLS para criptografia, cada um foi proposto numa RFC diferente com portas diferentes e até métodos de implatação diferentes. Ambos têm o mesmo nível de segurança (já que ambos usam TLS, mesmo no caso do HTTPS). A única diferença entre eles é a porta utilizada, com o HTTPS na porta 443 e o TLS na porta 853.
Ambos são usados para responder a consultas DNS de forma segura e podem até efetuar transferência de zona, dependendo da compatibilidade do software usado tanto no servidor Primário quanto Secundário.
O DoH tem uma camuflagem por usar a porta 443 enquanto DoT não tem. Porém, o DoH precisa de um servidor Web para responder consultas usando cabeçalhos HTTP, já o DoT não precisa.
XoT - XFR over TLS
O XoT é usado para fazer transferência de zona usando TLS, ou seja, efetua a transferência de zona de forma segura, usando criptografia. O XoT se aplica tanto a AXFR quanto a IXFR. Como curiosidade, XoT é pronunciado como zot, pois X aqui significa 'zone transfer'.
Ainda podemos nos referir a AXoT para AXFR over TLS e IXoT para IXFR over TLS. A porta de conexão para XoT deve ser realizada preferencialmente na 853 (conforme especificado em RFC7858), a menos que exista a possibilidade de configurar outra porta tanto no servidor primário quanto no secundário (uma boa medida é a porta 8853). A versão do TLS deve ser pelo menos 1.3, nenhum versão inferior deve ser usada, mas versões mais novas podem ser usadas.
Ainda é possível usar portas diferentes para AXoT e IXoT ou para zonas diferentes.
Essa RFC foi proposta porque o conteúdo completo da zona é transferido em texto simples (sem criptografia) e pode ser analisado por alguém que consiga capturar o tráfego no momento da transferência. Isso expõe todos os endereços IP mantidos nos registros DNS, o que pode facilitar o reconhecimento e o direcionamento de ataques, especialmente para endereços IPv6 ou redes privadas.
Apesar disso, nenhuma das RFCs mencionadas em RFC 9076 contempla o risco de alguém obter os dados por meio de espionagem nas conexões de rede, apenas por meio de enumeração ou transferência não autorizada.
Abaixo podemos ver uma comunicação em AXoT retirada da RFC 9103.
# A figura abaixo fornece um esboço do mecanismo AXoT incluindo NOTIFYs.
Secondary Primary
| NOTIFY |
| <-------------------------------- | UDP
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session)
| SOA Response |
| |
| |
| |
| AXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| AXFR Response 1 | |
| (Zone data) | |
| | |
| <-------------------------------- | | TLS
| AXFR Response 2 | | Session
| (Zone data) | |
| | |
| <-------------------------------- | |
| AXFR Response 3 | |
| (Zone data) | ---
| |
Figure 3: AXoT Mechanism
Abaixo podemos ver uma comunicação em IXoT retirada da RFC 9103.
# A figura abaixo fornece um esboço do mecanismo IXoT incluindo NOTIFYs.
Secondary Primary
| NOTIFY |
| <-------------------------------- | UDP
| --------------------------------> |
| NOTIFY Response |
| |
| |
| SOA Request |
| --------------------------------> | UDP (or part of
| <-------------------------------- | a TCP/TLS session)
| SOA Response |
| |
| |
| |
| IXFR Request | ---
| --------------------------------> | |
| <-------------------------------- | |
| IXFR Response | |
| (Zone data) | |
| | | TLS
| | | session
| IXFR Request | |
| --------------------------------> | |
| <-------------------------------- | |
| IXFR Response | |
| (Zone data) | ---
Figure 4: IXoT Mechanism
O uso do XoT não exclui a necessidade de usar TSIG ou SIG(0) para realizar a transferência de zona, ainda é recomendado além de usar uma chave de assinatura, específicar quais endereços IP podem receber essa transferência completa.
DANE - DNS-based Authentication of Named Entities
O DANE é um protocolo de segurança do DNS que permite que os certificados X.509, utilizados na Segurança da Camada de Transporte (TLS), sejam vinculados a nomes de domínio por meio das Extensões de Segurança do DNS. Seu objetivo é aumentar a segurança do processo de emissão de certificados digitais e evitar ataques de falsificação de certificados.
A vulnerabilidade que o DANE tenta resolver é que atualmente não há nenhuma associação direta entre um Certificado de Autoridade (CA) e o nome de domínio, o que permite que qualquer CA possa emitir um certificado para qualquer domínio. O DANE possibilita a adição de registros DNS para informar quais CAs são autorizados a emitir certificados para um determinado domínio.
O registro DNS específico utilizado pelo DANE é chamado de TLSA (Transport Layer Security Authentication). Ele é adicionado à zona de DNS do domínio e contém informações sobre o certificado digital associado ao domínio, incluindo o algoritmo de hash utilizado e o tipo de certificado. Quando um cliente conecta a um servidor protegido pelo TLS, o servidor envia o certificado digital e o cliente pode verificar se ele está correto usando as informações contidas no registro TLSA correspondente na zona de DNS do domínio. A ideia seria, pode acontecer das entidades certificadoras serem comprometidas, nesse caso, as certificadoras invadidas seriam usadas para gerar certificados falsos, com a aplicação do DANE seria fácil saber em quem confiar apenas verificando se existe registro no DNS.
Esses registros, chamados de registros TLSA, contêm informações que permitem a validação do certificado digital correspondente ao nome de domínio. Os registros TLSA contêm os seguintes campos:
Uso de Certificado (Certificate Usage)
Indica o uso previsto do certificado, podendo ser para autenticação do servidor (valor 0), autenticação do cliente (valor 1) ou ambos (valor 2);Seleção de Chave (Selector)
Especifica o tipo de informações de certificado que são utilizadas para a validação, podendo ser o certificado completo (valor 0) ou apenas o valor de hash da chave pública (valor 1);Associação de Nome (Matching Type)
Indica como o nome do domínio é comparado com o nome do certificado, podendo ser comparado exatamente (valor 0), com um curinga à esquerda (valor 1) ou com um curinga à direita (valor 2);Dados de Certificado (Certificate Association Data)
Contém a informação de certificado ou hash da chave pública, dependendo do valor do campo Selector.
O DANE é atualmente implementado em servidores de E-email e Web, em conjunto com DNS, podemos ver um exemplo abaixo:
# Verificando do servidor de e-mail:
$ dig _25._tcp.internet.nl TLSA +short
proloprod.mail._dane.internet.nl.
2 1 1 E1AE9C3DE848ECE1BA72E0D991AE4D0D9EC547C6BAD1DDDAB9D6BEB0 A7E0E0D8
3 1 1 D6FEA64D4E68CAEAB7CBB2E0F905D7F3CA3308B12FD88C5B469F08AD 7E05C7C7
# Verificando do servidor Web:
$ dig _443._tcp.internet.nl TLSA +short
proloprod._dane.internet.nl.
2 1 1 E1AE9C3DE848ECE1BA72E0D991AE4D0D9EC547C6BAD1DDDAB9D6BEB0 A7E0E0D8
3 1 1 D6FEA64D4E68CAEAB7CBB2E0F905D7F3CA3308B12FD88C5B469F08AD 7E05C7C7
## Para um dos exemplos nós temos:
# Usage: 3 (usado para certificados de servidor)
# Selector: 1 (usado para identificar o certificado apenas pelo seu fingerprint)
# Matching Type: 1 (usado para identificar o certificado pelo seu SHA-512)
# Certificate Association Data: D6FEA64D4E68CAEAB7CBB2E0F905D7F3CA3308B12FD88C5B469F08AD 7E05C7C7 (o valor do fingerprint do certificado)
AS112 Project
O Projeto AS112, ou Serviço de Blackhole DNS, é uma iniciativa para lidar com o tráfego indesejado gerado por consultas DNS associadas a endereços IP reservados para uso privado, como definido na RFC 1918. Esse tráfego é capturado e processado por servidores DNS "blackhole" ou "sinkhole" para reduzir a carga nas consultas DNS.
Os servidores DNS blackhole são operados por uma comunidade de voluntários que estabelecem esses servidores na internet para absorver o tráfego DNS indesejado. Esses voluntários se organizam sob o guarda-chuva do projeto AS112, usando um número de sistema autônomo (AS) designado para rotear esse tráfego para os servidores blackhole.
Os servidores blackhole respondem a consultas de DNS reverso associadas a endereços IP privados reservados para uso em redes internas privadas, garantindo que não vazem para a internet pública. Eles são configurados para retornar respostas que os clientes de DNS podem armazenar em cache, reduzindo assim a quantidade total de tráfego na Internet.
Além disso, o projeto AS112 oferece informações sobre operadores e como se voluntariar através de seu site. O objetivo principal é fornecer um serviço público para reduzir o tráfego indesejado na internet e garantir a segurança das redes locais.
Ferramentas para diagnóstico de problemas
Diagnósticos de problema no DNS podem ser um pouco complexos e trabalhoso, mas felizmente temos uma variedade incrível de ferramentas ao nosso dispor para facilitar esse trabalho. Segue um resumo sobre algumas ferramentas comumente utilizadas para diagnóstico em servidores DNS:
| Ferramenta | Descrição |
|---|---|
| nslookup | É uma ferramenta de linha de comando amplamente disponível em sistemas operacionais para consultas DNS. Permite verificar registros de DNS, como registros A, MX, CNAME, entre outros, e também pode ser usado para realizar consultas reversas de IP para nome de domínio. |
| dig | O "Domain Information Groper" é uma ferramenta poderosa e flexível para diagnóstico de DNS. Ela oferece recursos avançados, como consultas em diferentes tipos de registros, obtenção de informações detalhadas sobre respostas DNS, consulta de servidores DNS específicos e até mesmo simulação de consultas recursivas. |
| host | O comando host também é uma ferramenta útil para diagnóstico de servidores DNS. Ele é usado para obter informações de DNS específicas sobre um determinado nome de domínio ou endereço IP. Embora seja uma ferramenta similar ao dig mas sem todo o grande poder dele. |
| ping | Embora o ping seja principalmente usado para verificar a conectividade de rede, também pode ser útil no diagnóstico de DNS. Ao pingar um domínio, você pode verificar se o nome de domínio está resolvendo corretamente para um endereço IP e se há perda de pacotes na comunicação com o servidor DNS. |
| traceroute | Essa ferramenta rastreia a rota que os pacotes de rede seguem de sua máquina até o servidor DNS. Pode ajudar a identificar problemas de latência, saltos intermediários lentos ou possíveis bloqueios na rota. |
| tcpdump | Essa ferramenta de captura de pacotes de rede permite analisar o tráfego DNS em tempo real. Pode ser útil para identificar problemas de comunicação entre os clientes e o servidor DNS, além de ajudar na depuração de problemas específicos. |
| dnstracer | É uma ferramenta que ajuda a identificar a hierarquia dos servidores DNS envolvidos na resolução de um nome de domínio. Ela rastreia a cadeia de autoridade dos servidores DNS e pode ser útil para detectar possíveis problemas na configuração de DNS. |
| DNSViz | É uma ferramenta online (também pode ser instalada) que analisa a configuração e a cadeia de confiança do DNS de um domínio específico. Ela pode verificar problemas de configuração de DNS, como falta de registros, configurações inadequadas de segurança, entre outros. |
# Consultando o servidor de e-mail do google usando 'host':
$ host -t ns google.com
google.com name server ns3.google.com.
google.com name server ns1.google.com.
google.com name server ns4.google.com.
google.com name server ns2.google.com.
# Consultando o servidor de e-mail do google usando 'dig':
$ dig ns google.com +short
ns2.google.com.
ns3.google.com.
ns1.google.com.
ns4.google.com.
NSLOOKUP
O nslookup é uma ferramenta de linha de comando que é utilizada para consultar e obter informações sobre registros DNS. Ele permite que os usuários realizem consultas a servidores DNS para obter informações relacionadas a nomes de domínio, como mapeamento de endereços IP (resolução de nome para endereço IP) e outros detalhes do sistema de nomes de domínio.
A principal vantagem do nslookup é a sua disponibilidade quase universal, especialmente em sistemas Windows, onde o dig ainda é relativamente pouco comum. O nslookup oferece formatos tanto de linha de comando quanto interativos.
nslookupnão tem conhecimento do DNSSEC, já odigconsegue fazer consultas usando DNSSEC.
# Consultar o alvo usando o servidor de nomes padrão:
nslookup nic.br
# Consultar o alvo usando um servidor de nomes específico:
nslookup nic.br 8.8.8.8
# Entrar no modo interativo usando o servidor de nomes padrão:
nslookup
# Entrar no modo interativo usando um servidor de nomes específico:
nslookup - 8.8.8.8
# Pesquisa o registro MX do domínio example.com:
nslookup -type=MX example.com
DNSViz
O DNSViz é uma ferramenta online e via linha de comando que oferece uma visualização interativa e detalhada do processo de resolução DNS. Ele permite que os usuários analisem e compreendam a cadeia de resolução DNS para um determinado domínio, identificando problemas, possíveis vulnerabilidades ou configurações inadequadas.
Ao inserir um domínio no DNSViz, a ferramenta exibe um gráfico que representa as consultas DNS, as respostas recebidas e as relações entre os diferentes servidores DNS envolvidos na resolução. Isso inclui informações sobre registros DNS, autoridade, servidores de nomes e a segurança da cadeia de confiança.
Para usar o DNSViz via linha de comando, comece instalando os pacotes abaixo:
# Instalando os pacotes em distro Debian/Ubuntu:
$ sudo apt install jq dnsviz -y
Agora vamos obter dados sobre um domínio.
$ dnsviz probe -A -a . hermodr.com.br | jq | tee hermodr.com.br.json | dnsviz grok -l info | jq -r '."hermodr.com.br.".status'
No global IPv6 connectivity detected
Analyzing .
Analyzing br
Analyzing com.br
Analyzing hermodr.com.br
NOERROR
Com isso foi gravado toda a informação obtida num arquivo chamado hermodr.com.br.json. A partir desse arquivo podemos obter outras informações.
# Verificar se a configuração de delegação é considerada segura e está em conformidade com as
# melhores práticas e políticas de segurança estabelecidas:
$ cat hermodr.com.br.json | dnsviz grok -l info | jq -r '."hermodr.com.br.".delegation.status'
SECURE
# Ver o resultado de uma forma melhorada:
$ cat hermodr.com.br.json | dnsviz grok -l info
__________________________________________________________________________________________________________________
# Vejamos informações sobre a delegação do domínio:
$ cat hermodr.com.br.json | dnsviz grok -l info | jq -r '."hermodr.com.br.".delegation'
{
"ds": [
{
"id": "13/30706/2",
"status": "VALID",
"servers": [
"200.189.41.10",
"200.192.233.10",
"200.219.148.10",
"200.219.154.10",
"200.219.159.10",
"200.229.248.10"
],
"query_options": [
"UDP_-_EDNS0_4096_D_K"
]
}
],
"status": "SECURE"
}
## Os endereços IP listados dentro do campo "servers" são os servidores autorizados a
## responder pelas consultas DNS para o domínio "hermodr.com.br".
_____________________________________________________________________________________________________________________
# Vejamos informações sobre os servidores de chaves DNSKEY autorizados para o domínio:
$ cat hermodr.com.br.json | dnsviz grok -l info | jq -r '."hermodr.com.br.".dnskey'
[
{
"id": "13/30706",
"servers": [
"200.160.0.14",
"200.189.40.14"
],
"query_options": [
"UDP_-_EDNS0_4096_D_K",
"UDP_-_EDNS0_512_D_K"
]
}
]
## Esses servidores são responsáveis por armazenar e fornecer as chaves DNSKEY associadas
## ao domínio para fins de autenticação e verificação de DNSSEC.
DIG - Domain Information Groper
O dig é a ferramenta de diagnóstico de DNS mais usada, mas nem sempre está amplamente disponível, principalmente em sistemas Windows. O dig tem uma linha de comando e um modo de lote. Em geral, a linha de comando do dig é mais poderosa do que muitos outros utilitários, permitindo até mesmo várias consultas em uma única linha; e o modo em lote torna a execução de arquivos de verificação muito fácil.
O comando dig pode ser controlado usando um arquivo chamado .digrc no diretório inicial do usuário para definir padrões que substituirão o arquivo /etc/resolv.conf. Abaixo seguem algumas tabelas com opções bem comuns do comando dig:
| Opções | Descrição |
|---|---|
| -4 | Usa o IPv4. |
| -6 | Usa o IPv6. |
| -k dir:key | Assina a mensagem com TSIG usando a chave no arquivo do diretório especificado. |
| -h | Exibe uma lista curta das opções disponíveis no dig e sai. |
| -q | Indica que o argumento do domínio segue (formato de argumento identificado). |
| -p port | Altera a porta usada para consultas para a porta especificada (o padrão é 53). |
| -v | Exibe o número da versão do dig e sai. |
| -x | Especifica que a notação inversa está sendo usada, ou seja, usado para achar o nome de domínio a partir de um IP. |
| -t type | Conhecido como q-type, é usado para especificar o tipo de registro DNS que você deseja consultar. Veja as opções aqui. |
| -c class | Especifica a classe do registro DNS, o padrão é IN. Veja as opções aqui. |
| q-opt | As "Query Options" são opções precedidas por um sinal de mais + que controlam o comportamento das consultas DNS realizadas pelo dig. Essas opções permitem ajustar diferentes aspectos do processo de consulta DNS. |
A tabela abaixo representa as query options mais comuns:
| Query Option | Descrição |
|---|---|
| +short | Reduz a saída para uma exibição compacta, mostrando apenas informações essenciais. |
| +dnssec | Solicita informações sobre registros DNSSEC (DNS Security Extensions), indicando suporte a assinaturas digitais para autenticidade. |
| +nodnssec | Desativa a verificação de registros DNSSEC na resposta, mesmo se o servidor consultado suportar DNSSEC. |
| +trace | Ativa o rastreamento da consulta, exibindo as etapas da consulta DNS desde a raiz até a resposta final. |
| +norec | Solicita uma resposta que não envolve a recursão do servidor DNS consultado, exibindo apenas registros presentes na zona de autoridade. |
| +multi | Habilita a consulta de vários endereços IP associados a um determinado nome de domínio (registros múltiplos). Isso é útil para consultas de balanceamento de carga, por exemplo. |
| +tcp | É usada para forçar a consulta DNS seja realizada utilizando o protocolo TCP em vez do UDP. |
| +do | Ativa o bit "DNSSEC OK" na consulta, indicando que o cliente suporta DNSSEC e solicita respostas DNSSEC. |
| +nodo | Desativa o uso do bit "DNSSEC OK" na consulta, indicando que o cliente não suporta ou não deseja resposta DNSSEC. |
| +crypto | Ativa a exibição de informações criptográficas na resposta DNS, se disponíveis. |
| +nocrypto | Desativa a exibição de informações criptográficas na resposta DNS. |
| +fail | Solicita que a consulta falhe se a resposta não contiver registros. |
| +nofail | Desativa a falha da consulta se a resposta não contiver registros. |
| +all | Ativa a exibição de todos os detalhes disponíveis na resposta DNS. |
| +noall | Desativa a exibição de detalhes adicionais, mostrando uma resposta mais básica. |
| +answer | Ativa a exibição apenas da seção de resposta na resposta DNS. |
| +noanswer | Desativa a exibição da seção de resposta na resposta DNS. |
| +authority | Ativa a exibição apenas da seção de autoridade na resposta DNS. |
| +noauthority | Desativa a exibição da seção de autoridade na resposta DNS. |
| +noednsneg | Esta opção desativa a negociação de versão do EDNS (Serviço de Nomes de Domínio Estendido). Por padrão, a negociação de versão do EDNS está ativada. |
| +edns[=#] | Esta opção especifica a versão do EDNS a ser consultada. Os valores válidos são de 0 a 255. Definir a versão do EDNS faz com que uma consulta EDNS seja enviada. A opção +noedns limpa a versão do EDNS lembrada. O EDNS é definido como 0 por padrão. |
DIG - Exemplos
Segue alguns exemplos do comando dig:
# O comando abaixo obtém a versão do servidor DNS que está rodando em a.dns.br:
dig -t txt -c chaos VERSION.BIND @a.dns.br +short
"NSD 4.6.1"
# O comando abaixo obtém a versão do servidor DNS que está rodando em a.dns.br:
dig -t txt -c chaos version.server @a.dns.br +short
"NSD 4.6.1"
_______________________________________________________________________________________________________________________________________________________________________
# Realiza uma consulta DNSSEC e obtém registros TLSA para o serviço _25._tcp.top.nic.br.
# A opção '+multi' ativa a exibição de respostas múltiplas ou registros múltiplos associados ao nome de domínio especificado.
# Muito útil quando um nome de domínio tem vários registros associados a ele, e você deseja ver todas essas respostas de uma vez.
dig @8.8.8.8 +multi +dnssec _25._tcp.top.nic.br TLSA
; <<>> DiG 9.18.18-0ubuntu0.23.04.1-Ubuntu <<>> @8.8.8.8 +multi +dnssec _25._tcp.top.nic.br TLSA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53155
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;_25._tcp.top.nic.br. IN TLSA
;; ANSWER SECTION:
_25._tcp.top.nic.br. 7200 IN TLSA 3 1 1 (
8B9ED4F92354E782109273D4E05470E14221D325BB9D
EA7EBD703C94DD9CDB52 )
_25._tcp.top.nic.br. 7200 IN RRSIG TLSA 13 5 7200 (
20240425001613 20240214232459 47828 nic.br.
CW1YBcYCxWk2c0PdZiBAN1/R3qBVWygZtF9b2WsH8HMY
j5EVEgkQ8D7DOs8jHV4Ofh4S4IoDJu6Wx5W8rXGLrw== )
;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Mar 08 20:05:40 -03 2024
;; MSG SIZE rcvd: 197
_______________________________________________________________________________________________________________________________________________________________________
# O comando abaixo faz uma consulta para o registro TXT do domínio hermodr.com.br, tendo a saída curta (+short):
dig txt hermodr.com.br +short
"testando"
"v=spf1 -all"
_______________________________________________________________________________________________________________________________________________________________________
# Obtém registros NS para o domínio google.com, tendo a saída curta (+short):
dig ns google.com +short
ns2.google.com.
ns3.google.com.
ns1.google.com.
ns4.google.com.
_______________________________________________________________________________________________________________________________________________________________________
# Realiza uma transferência de zona (AXFR). Só vai funcionar se a transferência de zona estiver aberta para qualquer host:
dig @ns1.hermodr.com.br AXFR hermodr.com.br
; <<>> DiG 9.18.18-0ubuntu0.23.04.1-Ubuntu <<>> @ns1.hermodr.com.br AXFR hermodr.com.br
; (2 servers found)
;; global options: +cmd
; Transfer failed.
_______________________________________________________________________________________________________________________________________________________________________
# Realiza uma consulta reversa com rastreamento completo para o endereço IP 8.8.8.8 usando IPv4.
dig +trace -4x 8.8.8.8
; <<>> DiG 9.18.18-0ubuntu0.23.04.1-Ubuntu <<>> +trace -4x 8.8.8.8
;; global options: +cmd
. 5771 IN NS k.root-servers.net.
. 5771 IN NS g.root-servers.net.
. 5771 IN NS c.root-servers.net.
. 5771 IN NS h.root-servers.net.
. 5771 IN NS e.root-servers.net.
. 5771 IN NS f.root-servers.net.
. 5771 IN NS d.root-servers.net.
. 5771 IN NS l.root-servers.net.
. 5771 IN NS i.root-servers.net.
. 5771 IN NS a.root-servers.net.
. 5771 IN NS b.root-servers.net.
. 5771 IN NS m.root-servers.net.
. 5771 IN NS j.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 86400 IN DS 63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa. 86400 IN DS 47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa. 86400 IN DS 53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa. 86400 IN DS 54956 8 2 E0E2BF5CFBD66572CA05EC18267D91509BA6A9405AF05C3FD4141DFA 45200C08
in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 20240321180000 20240308170000 586 arpa. C/mi2109lFt8JZQSQF0xoBA1glt6cBHtwY++P3W1x82irIa3qls8qPvS nN1Te4CqCNrS3anUIZwMZXSA46JeHd9rfeTNCVQxg9R4hyY8XBrdnxD8 PUcKHGdLwsTpLDBBBIQ+h0/UscrUQkZFoTjaEC+c/X1LMuqW1tVzXLpJ CMA/Oq373xxMCIRKeUAVaP4gjnyQtvZEVsQmv1GKt2HMfb1X2W28mGAB pDKLYx07+0biMrDXiKmlL3cmpxDxFnXOcJhedXTP7gG2Gxc0cD9k+8W2 /frkju70++GFvBLWYqp3TzBaP8ugMI11Ue90nO7DG1avYYgokwkherS2 sGpyGg==
;; Received 953 bytes from 192.112.36.4#53(g.root-servers.net) in 160 ms
8.in-addr.arpa. 86400 IN NS r.arin.net.
8.in-addr.arpa. 86400 IN NS u.arin.net.
8.in-addr.arpa. 86400 IN NS x.arin.net.
8.in-addr.arpa. 86400 IN NS y.arin.net.
8.in-addr.arpa. 86400 IN NS z.arin.net.
8.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net.
8.in-addr.arpa. 86400 IN DS 17011 8 2 A0F1603C78C9B91B7BC07A23C144621F84D28AF4A4393FC6B2D21C5F F3D65D6D
8.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20240316131342 20240224140400 49518 in-addr.arpa. xPUWU4YO2JpRfPzXCqG6fAw/1R2CdtmZcjCY3lWVa4qlYVis3sd7CHgL IJDThOvh9oBSofBe7V/4gcYAkoEQ1Q8aODzAUCVNZSCPZx1svj8pv3qB OlVlIKXvBPlzmxgErkFvrybh9TEc87qRqIHcJNFKEqFEReIsRa+xTYeV IrM=
;; Received 389 bytes from 193.0.9.1#53(f.in-addr-servers.arpa) in 200 ms
8.8.8.in-addr.arpa. 86400 IN NS ns1.google.com.
8.8.8.in-addr.arpa. 86400 IN NS ns4.google.com.
8.8.8.in-addr.arpa. 86400 IN NS ns3.google.com.
8.8.8.in-addr.arpa. 86400 IN NS ns2.google.com.
8.8.8.in-addr.arpa. 10800 IN NSEC 80.8.8.in-addr.arpa. NS RRSIG NSEC
8.8.8.in-addr.arpa. 10800 IN RRSIG NSEC 8 5 10800 20240322053258 20240308043258 27033 8.in-addr.arpa. BbqqLE1sU3pAs14GPgPLOUuXRP3DPOdyfyRfYkhCUWOhOQTnXKX5J6ej EbSAzXuq2Q3oXAiQJv9RmZcacEXsbPzKfYeXqiJ3LufQkGQGasqo0yZG eIdt9oLF3kfwIn74p8tDK0jmkRPfv3rZ5gfovbjceMv0VFUN3CKamJv9 bDA=
;; Received 374 bytes from 199.180.180.63#53(r.arin.net) in 156 ms
8.8.8.8.in-addr.arpa. 86400 IN PTR dns.google.
;; Received 73 bytes from 216.239.38.10#53(ns4.google.com) in 128 ms
_______________________________________________________________________________________________________________________________________________________________________
# Obtém o texto do registro id.server no contexto CH (Chaosnet).
dig CH TXT id.server @a.dns.br +short
"a8.a.dns.br"
dig CH TXT id.server @a.dns.br +short
"a7.a.dns.br"
_______________________________________________________________________________________________________________________________________________________________________
# Obtém registros DS (Delegation Signer) para o domínio sp.hermodr.com.br, usando o DNS do google como recursivo e validando DNSSEC.
# Possui a flag 'AD'.
dig @8.8.8.8 sp.hermodr.com.br DS +dnssec
; <<>> DiG 9.18.18-0ubuntu0.23.04.1-Ubuntu <<>> @8.8.8.8 sp.hermodr.com.br DS +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32509
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;sp.hermodr.com.br. IN DS
;; ANSWER SECTION:
sp.hermodr.com.br. 21600 IN DS 59600 13 2 EA640902279286DB81A1B46E7AE0B5AAA1BA2727718AC29D11D93F55 0B036602
sp.hermodr.com.br. 21600 IN RRSIG DS 13 4 86400 20240317202018 20240307233936 19348 hermodr.com.br. USyhbuXiMR485eWLrWU0LBuPRi28sU7DwK5cnUsaNmsAPmY8uvAhCtjp OOu40lg6F6MV2m9dRGC3yMP6FPGuNA==
;; Query time: 428 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Mar 08 20:54:28 -03 2024
;; MSG SIZE rcvd: 204
_______________________________________________________________________________________________________________________________________________________________________
# Obtém registros A para o domínio sp.hermodr.com.br, usando o DNS da quad9 como recursivo, sem validar DNSSEC.
# Não possui a flag 'AD'.
dig @9.9.9.9 sp.hermodr.com.br A +nodnssec
; <<>> DiG 9.18.18-0ubuntu0.23.04.1-Ubuntu <<>> @9.9.9.9 sp.hermodr.com.br A +nodnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32024
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;sp.hermodr.com.br. IN A
;; AUTHORITY SECTION:
sp.hermodr.com.br. 3600 IN SOA ns1.sp.hermodr.com.br. admin.sp.hermodr.com.br. 2024022907 3600 1800 604800 86400
;; Query time: 192 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Fri Mar 08 20:55:56 -03 2024
;; MSG SIZE rcvd: 92
_______________________________________________________________________________________________________________________________________________________________________
# Obtém registros NS para o domínio hermodr.com.br do servidor DNS especificado, sem envolver recursão (+norec):
dig -4 @a.dns.br hermodr.com.br ns +norec
; <<>> DiG 9.18.18-0ubuntu0.23.04.1-Ubuntu <<>> -4 @a.dns.br hermodr.com.br ns +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38125
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0da65fa732737d200100000065eb9bb546e0d5b8448d7505 (good)
;; QUESTION SECTION:
;hermodr.com.br. IN NS
;; AUTHORITY SECTION:
hermodr.com.br. 3600 IN NS ns2.hermodr.com.br.
hermodr.com.br. 3600 IN NS ns1.hermodr.com.br.
;; ADDITIONAL SECTION:
ns2.hermodr.com.br. 3600 IN A 94.72.123.149
ns1.hermodr.com.br. 3600 IN A 75.119.143.187
ns2.hermodr.com.br. 3600 IN AAAA 2605:a141:2167:7657::1
ns1.hermodr.com.br. 3600 IN AAAA 2a02:c206:2120:1140::1
;; Query time: 8 msec
;; SERVER: 200.219.148.10#53(a.dns.br) (UDP)
;; WHEN: Fri Mar 08 20:13:57 -03 2024
;; MSG SIZE rcvd: 195
_______________________________________________________________________________________________________________________________________________________________________
# Realiza uma consulta IPv6:
dig -6 d4.a.d.dns.br
_______________________________________________________________________________________________________________________________________________________________________
# Realiza uma consulta para o domínio google.com no servidor DNS 10.2.15.3 usando TCP.
dig @10.2.15.3 google.com +short +tcp
_______________________________________________________________________________________________________________________________________________________________________
# Obtém registros DNSKEY (DNS Key) para o domínio hermodr.com.br do servidor DNS local, exibindo informações DNSSEC.
dig @localhost +dnssec +multiline +noall +answer hermodr.com.br DNSKEY
hermodr.com.br. 3600 IN DNSKEY 257 3 13 (
ytTiXqvAsCx9eH3mLNnkl+2EHcA9Yg/UALznDOQ/o7tG
js5aZu7fEcSfiH0kUa6Pq2YLwqnptdX4dgGRffdfhg==
) ; KSK; alg = ECDSAP256SHA256 ; key id = 19348
hermodr.com.br. 3600 IN RRSIG DNSKEY 13 3 3600 (
20240321204441 20240307203415 19348 hermodr.com.br.
Q9CT/4nTtYNufybKzz84nhLcSnKWwtYSwRc3Zq9A4en/
vr7dRhGXvh4JHpupxSOUOcmH0pLUyx65V/I6fXpgFA== )
## A função principal do DNSKEY é fornecer uma chave pública que pode ser usada para verificar a assinatura digital dos registros DNS.
## Nesse caso a chave é: ytTiXqvAsCx9eH3mLNnkl+2EHcA9Yg/UALznDOQ/o7tGjs5aZu7fEcSfiH0kUa6Pq2YLwqnptdX4dgGRffdfhg==
## A keytag é: 19348.
_______________________________________________________________________________________________________________________________________________________________________
# Realiza uma consulta inversa para o endereço IP 192.168.23.23.
dig -x 8.8.8.8 +short
dns.google.
_______________________________________________________________________________________________________________________________________________________________________
# Fazendo uma consulta sem ser recursiva (precisa perguntar diretamente para o servidor autoritativo):
dig @ns1.hermodr.com.br hermodr.com.br A +norec +short
75.119.143.187
_______________________________________________________________________________________________________________________________________________________________________
# Fazendo uma consulta sem ser recursiva, mas usando um servidor recursivo, não vai responder, já que o recursion está desativado.
# Some a flag 'rd'.
dig @8.8.8.8 hermodr.com.br A +norec
; <<>> DiG 9.18.18-0ubuntu0.23.04.1-Ubuntu <<>> @8.8.8.8 hermodr.com.br A +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48969
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;hermodr.com.br. IN A
;; Query time: 68 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Mar 08 20:51:20 -03 2024
;; MSG SIZE rcvd: 43
_______________________________________________________________________________________________________________________________________________________________________
# Fazendo várias requisições:
dig registro.br nic.br A
; <<>> DiG 9.18.18-0ubuntu0.23.04.1-Ubuntu <<>> registro.br nic.br A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10841
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;registro.br. IN A
;; ANSWER SECTION:
registro.br. 370 IN A 200.160.2.3
;; Query time: 96 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Mar 08 20:21:42 -03 2024
;; MSG SIZE rcvd: 56
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52638
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;nic.br. IN A
;; ANSWER SECTION:
nic.br. 1685 IN A 200.160.4.6
;; Query time: 148 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Mar 08 20:21:42 -03 2024
;; MSG SIZE rcvd: 51
_______________________________________________________________________________________________________________________________________________________________________
# Fazendo várias requisições mas usando RR diferentes:
dig registro.br AAAA nic.br A
; <<>> DiG 9.18.18-0ubuntu0.23.04.1-Ubuntu <<>> registro.br AAAA nic.br A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9982
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;registro.br. IN AAAA
;; ANSWER SECTION:
registro.br. 896 IN AAAA 2001:12ff:0:2::3
;; Query time: 40 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Mar 08 20:22:11 -03 2024
;; MSG SIZE rcvd: 68
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17031
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;nic.br. IN A
;; ANSWER SECTION:
nic.br. 1655 IN A 200.160.4.6
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Mar 08 20:22:11 -03 2024
;; MSG SIZE rcvd: 51
DIG - Output
Agora vamos entender a saída do comando dig, então tomemos como base o resultado abaixo:
dig @8.8.8.8 hermodr.com.br A
; <<>> DiG 9.18.18-0ubuntu0.23.04.1-Ubuntu <<>> @8.8.8.8 hermodr.com.br A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37656
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;hermodr.com.br. IN A
;; ANSWER SECTION:
hermodr.com.br. 21593 IN A 75.119.143.187
;; Query time: 64 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Mar 08 19:31:42 -03 2024
;; MSG SIZE rcvd: 59
>>HEADER<<
É o cabeçalho da resposta DNS. Esse cabeçalho contém informações importantes sobre a resposta recebida do servidor DNS.Opcode (Código de Operação):
Indica o tipo de consulta sendo feita. No nosso exemplo, é uma consulta do tipo consulta padrão, é uma requisição.
RCODE (Status):
Indica o resultado da operação de consulta.
- NOERROR A consulta foi bem-sucedida, sem erros.
- NXDOMAIN O domínio consultado não existe.
- SERVFAIL O servidor encontrou um erro ao processar a consulta.
- REFUSED O servidor se recusou a processar a consulta.
- NOSIG Significa que seu domínio não está assinado por nenhuma das chaves relacionadas aos DS informados na zona pai.
ID (Identificação):
Um número de 16 bits que identifica exclusivamente uma consulta e sua resposta. Ajuda a associar uma resposta a uma consulta específica.
QR (Flag de Resposta):
Indicam o tipo de resposta fornecida pelo servidor DNS na consulta.
qr (Query Response): Significa que esta é uma resposta a uma consulta e sempre será apresentada em uma resposta do
dig.aa (Authoritative Answer): Significa que a resposta veio de um servidor de nomes autoritativo para o domínio. Ou, que esta foi a primeira vez que os dados foram lidos de um servidor de nomes autoritativo para um servidor de nomes em cache. No último caso, se o comando
digfor imediatamente reemitido, a flag aa não será apresentada, pois terá sido lida do cache.rd (Recursion Desired): Significa que a consulta de entrada solicitou suporte recursivo.
ra (Recursion Available): Significa que o servidor de nomes que está respondendo suporta consultas recursivas.
ad (Authenticated Data): É válida apenas com DNSSEC e indica que o servidor de nomes de destino está ciente da segurança.
cd (Checking Disabled): É válida apenas com DNSSEC e indica que a consulta emitida deseja ignorar qualquer sequência de validação DNSSEC realizada pelo servidor de nomes ao acessar uma zona assinada. Esta flag só será apresentada na resposta a um comando
digse a opção+cdflagfor usada.do (DNSSEC OK): É válida apenas com DNSSEC e é apresentada na PSEUDOSEÇÃO OPT estendida que está sempre presente em transações DNSSEC. Só será apresentada em uma resposta do
digse a opção+dnssecfor usada e o servidor de nomes de destino estiver ciente da segurança.
Essa parte da saída do comando dig fornece informações estatísticas sobre a resposta da consulta DNS. Aqui está a tradução:
QUERY: 1 - Indica que houve uma única consulta realizada pelo comando
dig.ANSWER: 1 - Indica que a resposta da consulta continha uma entrada de resposta.
AUTHORITY: 0 - Indica que não há registros de autoridade incluídos na resposta. Os registros de autoridade normalmente indicam quais servidores de nomes são autoritativos para a zona consultada.
ADDITIONAL: 1 - Indica que há uma entrada adicional incluída na resposta. As entradas adicionais geralmente fornecem informações suplementares relacionadas à consulta original.
QUESTION SECTION:
Reflete a consulta original que está sendo respondida; neste caso, é uma consulta para o Registro A (A RR) de hermodr.com.br..
ANSWER SECTION:
Fornece os dois registros NS (NS RRs) para hermodr.com.br que respondem completamente à pergunta neste caso. Se aANSWER SECTIONestiver presente, mas não contiver entradas, a consulta não foi bem-sucedida. Nesse caso o campo destatusnoHEADERgeralmente fornece o motivo, a menos que a resposta seja uma referência, caso em que o campo de status seráNOERR.
AUTHORITY SECTION:
Se aparecer, fornece os registros NS (NS RRs) dos servidores que são autoritativos para o domínio.
ADDITIONAL SECTION:
Fornece informações que podem ser úteis ao servidor; neste caso, são os registros A (A RRs) dos servidores de nomes.
Agora vou explicar algumas informações encontradas no output do dig:
Essas partes adicionais na saída do comando dig fornecem informações suplementares sobre a resposta da consulta DNS. Aqui está uma explicação para cada uma delas:
(1 server found):
Indica quantos servidores DNS disponíveis para responder à consulta foram encontrados.global options: +cmd:
Mostra as opções globais que foram aplicadas durante a execução do comandodig. No caso, a opção+cmdestá habilitada, o que significa que as mensagens de comandodigserão exibidas na saída.Got answer:
Indica que uma resposta foi recebida do servidor DNS consultado.OPT PSEUDOSECTION:
Fornece informações adicionais sobre as opções de extensão DNS (EDNS) usadas na comunicação entre o cliente e o servidor DNS.EDNS: version:
Indica a versão do protocolo EDNS usado na comunicação. No exemplo, é a versão 0.flags:
Indica quaisquer flags específicas usadas nas opções de extensão. Neste caso, não há flags específicas definidas.udp:
Indica o tamanho máximo do datagrama UDP suportado pelo servidor DNS. No exemplo, é 512 bytes.COOKIE:
Mostra um cookie gerado pelo cliente e enviado ao servidor DNS como parte da consulta.
Isso pode ser usado para garantir integridade e autenticidade na comunicação DNS.Query time:
Indica o tempo decorrido desde o envio da consulta até a recepção da resposta, em milissegundos.SERVER:
Indica o servidor DNS que respondeu à consulta. No exemplo, o servidor é8.8.8.8e está associado ao domínio8.8.8.8(dns.google).
O número após o caractere#indica a porta usada para a comunicação (porta 53 neste caso).WHEN:
Indica a data e hora em que a resposta foi recebida.MSG SIZE rcvd:
Indica o tamanho da mensagem DNS recebida. Neste caso, a mensagem tinha 59 bytes de tamanho.
Host
O comando host é uma ferramenta de linha de comando utilizada para realizar consultas de DNS (Domain Name System). Ele é comumente usado para obter informações sobre resolução de nomes de domínio, como encontrar registros de IP associados a nomes de host, identificar servidores de e-mail (MX records), obter registros de servidores de nomes (NS records), entre outras consultas relacionadas ao DNS.
A sintaxe básica do comando host é:
host [opções] [nome_do_host]
Vejamos as opções mais comuns do comando host:
| Opção | Descrição |
|---|---|
-t | Especifica o tipo de registro DNS a ser consultado (A, AAAA, MX, NS, etc.). |
-a | Realiza uma consulta completa, mostrando informações detalhadas, incluindo registros de alias. |
-C | Mostra informações adicionais, como o tempo de vida (TTL) dos registros. |
Abaixo seguem alguns exemplos de uso:
| Comando | Descrição |
|---|---|
host -t mx google.com | Consulta os registros MX (Mail Exchange) para o domínio google.com, mostrando os servidores de e-mail associados. |
host -t A webmail.4linux.com.br | Consulta o registro A (IPv4) para o nome de host webmail.4linux.com.br, fornecendo o endereço IP associado ao servidor webmail. |
host -t NS 4linux.com.br | Consulta os registros NS (Name Server) para o domínio 4linux.com.br, exibindo os servidores DNS autoritativos para o domínio. |
Whois
O WHOIS é um protocolo (e também uma aplicação) de consulta de informações de registro de domínios e endereços IP. Ele permite que os usuários obtenham informações como o proprietário do domínio, a data de criação do domínio, as informações de contato do registrante, o servidor DNS autorizado, entre outras informações. er
O whois também pode ser usado para consultar informações de registro de Autonomous System Numbers (ASN), que são usados para identificar redes autônomas na internet. Ao realizar uma consulta WHOIS em um ASN, você pode obter informações como o nome da organização responsável pelo ASN, o país em que a organização está localizada, o número de blocos de endereços IP que o ASN controla e informações de contato para a organização responsável pelo ASN.
Veja exemplos de consultas usando o comando whois:
$ whois google.com.br
% Copyright (c) Nic.br
% The use of the data below is only permitted as described in
% full by the Use and Privacy Policy at https://registro.br/upp ,
% being prohibited its distribution, commercialization or
% reproduction, in particular, to use it for advertising or
% any similar purpose.
% 2023-04-21T11:28:10-03:00 - IP: 191.162.50.59
domain: google.com.br
owner: Google Brasil Internet Ltda
ownerid: 06.990.590/0001-23
responsible: Domain Administrator
country: BR
owner-c: DOADM17
tech-c: DOADM17
nserver: ns1.google.com
nsstat: 20230421 AA
nslastaa: 20230421
nserver: ns2.google.com
nsstat: 20230421 AA
nslastaa: 20230421
nserver: ns3.google.com
nsstat: 20230421 AA
nslastaa: 20230421
nserver: ns4.google.com
nsstat: 20230421 AA
nslastaa: 20230421
created: 19990518 #162310
changed: 20230420
expires: 20240518
status: published
nic-hdl-br: DOADM17
person: Domain Admin
e-mail: ccops@markmonitor.com
country: BR
created: 20100520
changed: 20220228
% Security and mail abuse issues should also be addressed to
% cert.br, http://www.cert.br/ , respectivelly to cert@cert.br
% and mail-abuse@cert.br
%
% whois.registro.br accepts only direct match queries. Types
% of queries are: domain (.br), registrant (tax ID), ticket,
% provider, CIDR block, IP and ASN.
Para consultar IP basta substituir o domínio pelo IP.
Abaixo segue um exemplo de como consultar um ASN:
$ whois as1916
% Copyright (c) Nic.br
% The use of the data below is only permitted as described in
% full by the Use and Privacy Policy at https://registro.br/upp ,
% being prohibited its distribution, commercialization or
% reproduction, in particular, to use it for advertising or
% any similar purpose.
% 2023-04-21T11:31:30-03:00 - IP: 191.162.59.128
aut-num: AS1916
owner: Rede Nacional de Ensino e Pesquisa
ownerid: 03.508.097/0001-36
responsible: Nelson Simões Silva
country: BR
owner-c: RCO217
routing-c: RCO217
abuse-c: SIC128
created: 19991116
changed: 20130306
inetnum: 200.129.0.0/16
inetnum: 200.130.0.0/16
inetnum: 200.131.0.0/16
inetnum: 200.137.0.0/16
inetnum: 200.139.0.0/18
inetnum: 200.143.192.0/18
inetnum: 200.159.240.0/20
inetnum: 200.17.0.0/20
inetnum: 200.18.128.0/18
inetnum: 200.18.192.0/19
inetnum: 200.18.224.0/20
inetnum: 200.17.32.0/19
inetnum: 200.19.32.0/20
inetnum: 200.19.112.0/20
inetnum: 200.19.128.0/18
inetnum: 200.237.0.0/18
inetnum: 200.239.128.0/18
inetnum: 2001:12f0::/32
inetnum: 132.255.96.0/22
inetnum: 138.121.68.0/22
inetnum: 170.79.212.0/22
inetnum: 200.18.20.0/22
inetnum: 200.18.24.0/21
inetnum: 200.19.8.0/21
inetnum: 200.19.16.0/20
inetnum: 200.18.80.0/20
inetnum: 200.17.128.0/19
inetnum: 200.17.176.0/20
inetnum: 200.17.64.0/20
inetnum: 200.17.112.0/20
inetnum: 200.133.0.0/17
inetnum: 200.133.128.0/18
inetnum: 200.133.192.0/19
inetnum: 200.133.240.0/20
inetnum: 200.128.128.0/18
inetnum: 200.128.192.0/19
inetnum: 200.128.224.0/20
inetnum: 150.165.0.0/16
inetnum: 200.235.0.0/17
nic-hdl-br: RCO217
person: RNP - Centro de Engenharia e Operações
e-mail: registro@rnp.br
country: BR
created: 20060406
changed: 20220524
nic-hdl-br: SIC128
person: Security Incidents Response Center
e-mail: cais@cais.rnp.br
country: BR
created: 20020417
changed: 20050309
% Security and mail abuse issues should also be addressed to
% cert.br, http://www.cert.br/ , respectivelly to cert@cert.br
% and mail-abuse@cert.br
%
% whois.registro.br accepts only direct match queries. Types
% of queries are: domain (.br), registrant (tax ID), ticket,
% provider, CIDR block, IP and ASN.
Saiba que o whois possui Rate Limits (Limites de Taxa), ou seja, possui uma quantidade máxima de consultas que um usuário pode efetuar, após atingir esse limite você não poderá mais efetuar consultas até que o seu IP seja desbloqueado (o que só pode acontecer ao entrar em contato com a Organização que mantém o Whois/RDAP ou até dar o tempo de limite de bloqueio).
Eles possuem esse Rate Limit para deter address scraping e outras formas de abusos. Para mais detalhes veja a RFC 7480. Nessa RFC existe um aviso sobre esse tipo de bloqueio:
RFC 7480, section-1 (traduzido) informa que:
Quando um servidor se recusa a responder a uma consulta devido a limites de taxa, ele retorna um código de resposta 429 (Too Many Requests), conforme descrito em [RFC6585].
Um cliente que recebe uma resposta 429 DEVE diminuir sua taxa de consulta e honrar o campo de cabeçalho Retry-After, se houver. Os servidores podem impor limites mais rígidos aos clientes que não respeitam o cabeçalho Retry-After. Opcionalmente, o servidor PODE incluir informações adicionais sobre o limite de taxa no corpo da entidade HTTP.
Mais informações sobre isso veremos em RDAP.
Informações encontradas no Whois
Com o Whois é posível encontrar algumas informações sobre o domínio consultado:
Registry Details
Aqui temos os detalhes de registro do domínio como: Quano o domínio foi registrado, Quando foi a última atualização de registro dentro do domínio, Nome do Registrar (Registrador) do domínio, URLs e contatos de abuso.Domain Registrant
São os dados do registrante do domínio, ou seja, quem registrou o domínio.Administrative Contact
Aqui temos as informações de quem é o Administrador do domínio, normalmente Administrative Contact e Domain Registrant são iguais, mas isso não é uma regra.Technical Contact
Este conjunto de contatos normalmente não exerce controle operacional ou administrativo sobre o domínio, é principalmente um ponto de contato que os operadores de rede podem usar para estabelecer comunicações a fim de resolver vários problemas de rede que possam surgir.Domain Status
Um ou mais campos de status estarão presentes para indicar quais operações podem ser realizadas no nome de domínio e em que estado ele se encontra. Esses status são definidos pelo registro do TLD pai ou pelo registrador do nome de domínio.Sinalizadores de status definidos pelo Registry:
OK
Se refere ao estado atual do domínio. Nenhuma proibição ou restrição está em vigor contra este domínio. Quando um domínio tem o status "OK", isso significa que ele está atualmente ativo e em boas condições, sem nenhum problema conhecido.inativo
O domínio não tem nenhuma delegação de servidor de nomes associada a ele e, portanto, não é resolvido na Internet.autoRenewPeriod
É um período de tempo que se aplica aos nomes de domínio que são configurados para renovação automática, mas que por algum motivo não conseguem ser renovados com sucesso na data de expiração. Durante esse período, que geralmente dura cerca de 45 dias, o proprietário ainda tem a chance de renovar o domínio, mas sem taxas adicionais.redemptionPeriod
Se aplica aos nomes de domínio que não foram renovados e que já passaram pelo período de grace period (período de carência) que geralmente dura cerca de 30 dias após a data de expiração. Se o domínio não for recuperado durante o redemptionPeriod, ele poderá ser liberado para registro por outras pessoas, ou em alguns casos, ser leiloado.pendingDelete
O RedempPeriod terminou e o domínio será completamente excluído do Registro dentro de alguns dias (geralmente 5). Feito isso, o domínio fica disponível para utilizado por outras pessoas.Sinalizadores de status definidos pelo Registrar ou Registrant
clientHold
Indica que o proprietário do domínio solicitou que o registrador mantenha o domínio em "pausa", impedindo que ele seja acessível na internet. Isso pode ser feito, por exemplo, para resolver problemas técnicos ou de segurança no domínio.clientDeleteProhibited
Indica que o proprietário do domínio não pode solicitar a exclusão do domínio. Isso pode ser feito, por exemplo, para evitar que o domínio seja excluído por engano.clientTransferProhibited
Indica que o proprietário do domínio não pode transferir o domínio para outro registrador. Isso pode ser feito, por exemplo, para evitar que o domínio seja transferido para outro proprietário sem autorização.clientUpdateProhibited
Indica que o proprietário do domínio não pode atualizar as informações de contato ou de DNS associadas ao domínio. Isso pode ser feito, por exemplo, para evitar que o domínio seja alterado por um invasor mal-intencionado.clientRenewProhibited
Indica que o proprietário do domínio não pode renovar o domínio antes da data de expiração. Isso pode ser feito, por exemplo, para evitar que o proprietário renove o domínio apenas para vendê-lo por um preço mais alto.
DNS Details
Aqui temos os detalhes do DNS, como a delegação do servidor de nomes e seu status de DNSSEC. A delegação do servidor de nomes são os servidores de nomes autorizados para o domínio em questão. Esses servidores de nomes são os que receberão e responderão a todas as consultas de DNS para o nome de domínio em questão. Os códigos de status podem ser aplicados a qualquer nome de domínio, independentemente da extensão de domínio (gTLD ou ccTLD). No entanto, a disponibilidade e os significados exatos dos códigos de status podem variar dependendo do registrador de domínios e das políticas da TLD específica.
whois.radb.net
Fugindo um pouco da parte de domínios que estão ligados diretamente ao DNS, vamos ver um pouco sobre esse servidor em específico que é muito usado.
O whois.radb.net é um servidor de WHOIS mantido pela RADB (Routing Assets Database), que é uma base de dados pública que contém informações sobre rotas BGP (Border Gateway Protocol) e outros recursos de roteamento da Internet. O objetivo principal da RADB é fornecer uma maneira para provedores de serviços de Internet e outros usuários avançados da rede compartilharem informações de roteamento e solucionarem problemas relacionados ao roteamento. A RADB é gerenciada pelo Merit Network, uma organização sem fins lucrativos que fornece serviços de rede e tecnologia para organizações de educação, pesquisa e governamentais.
O servidor de WHOIS da RADB é uma das fontes mais populares de informações de rotas BGP, pois permite que os usuários consultem informações de roteamento de prefixos de rede específicos ou ASN (Autonomous System Number). Além disso, o WHOIS da RADB também permite pesquisar informações de roteamento com base em filtros, como comunidades BGP, tipos de rotas e muito mais.
Outros serviços também estão disponíveis para consulta de informações de roteamento BGP, incluindo o Cymru Bogon Reference, o Hurricane Electric BGP Toolkit, o PeeringDB e o RIPE NCC. Cada servidor de WHOIS tem suas próprias vantagens e desvantagens, e alguns podem ser mais adequados para determinadas tarefas ou tipos de pesquisa do que outros.
Segue exemplo de uso para dois deles:
# Para consultar as rotas BGP do ASN 1916 no WHOIS da RADB:
$ whois -h whois.radb.net -- -i origin AS1916
# Para consultar informações no WHOIS da Cymru Bogon Reference:
$ whois -h whois.cymru.com "2001:12f0:a62::/48"
AS | IP | AS Name
1916 | 2001:12f0:a62::/48 | Rede Nacional de Ensino e Pesquisa, BR
$ whois -h whois.cymru.com "as1916"
AS Name
Rede Nacional de Ensino e Pesquisa, BR
RDAP
O RDAP (Registration Data Access Protocol) é um protocolo de consulta de informações de registro de domínios e endereços IP que foi criado como uma alternativa mais moderna e segura ao WHOIS. Ele fornece as mesmas informações que o WHOIS, mas com mais detalhes e em um formato mais padronizado. Dentre as melhorias trazidas pelo RDAP, podemos destacar o suporte a internacionalização, autenticação e a padronização do formato de consultas e respostas.
O RDAP usa REST como estilo arquitetural para acessar informações sobre recursos da Internet. O REST (Representational State Transfer) é um estilo arquitetural de software utilizado para criar serviços web que se comunicam através do protocolo HTTP.
Para usar um cliente de terminal para consultar o RDAP, o registro.br disponibiliza um cliente que pode ser encontrado aqui.
Apesar de existir um cliente de terminal, as consultas no RDAP se dão por meio de consultas HTTP GET, ou seja, é fácil implementar um script em Python ou qualquer outra linguagem de sua preferencia ou até mesmo usar o curl para fazer as requisições. Eu recomendo Python já que aplicações Web que usam REST estão fortimente interligadas com JSON, o que pode facilmente ser convertido em dicionário no Python, mas se mesmo assim quiser algo para o terminal do Linux, pode usar o utilitário chamado jq, que é uma biblioteca de linha de comando para manipulação de dados JSON.
As consultas com RDAP usam "segmento de caminho" para especificar um tipo de consulta, os segmentos são:
ip
Usado para identificar Redes IP e dados referentes a um determinado IPv4 ou IPv6.autnum
Usado para identificar um ASN.domain
Usado para identificar um nome de domínio (DNR) ou um DNS reverso (RIR).nameserver
Usado para identificar uma consulta de informações do servidor de nomes usando um nome de host.entity
Usado para identificar uma consulta de informações de entidade usando um identificador de string (como CNPJ/CFP).
Essas informações são encontradas na RFC 7482.
Abaixo seguem alguns exemplo de consulta (retirado do site registro.br/rdap):
# Consultando um domínio:
https://rdap.registro.br/domain/nic.br
# Consultando um IP:
https://rdap.registro.br/ip/200.160.0.1
# Consultando uma Rede:
https://rdap.registro.br/ip/2001:12ff::/32
# Consultando um ASN:
https://rdap.registro.br/autnum/22548
# Consultando um CNPJ:
https://rdap.registro.br/entity/05506560000136
Normalmente consultas para documentos como em CNPJ/CFP tanto para Whois quanto RDAP não são mais permitidas devido a LGPD. Isso fica claro com uma simples consulta usando Whois (via browser ou terminal), já via RDAP é necessário usar algum script já que o browser não retorna erro:
>>> import requests
>>> Url = "https://rdap.registro.br/entity/05506560000136"
>>> get_rdap = requests.get(Url, headers={'Content-Type':'application/json'})
>>> print(get_rdap.status_code)
403
Fontes
https://regional.forum.ix.br/files/apresentacao/arquivo/313/ICANN%20IX%20Forum%20SC.pdf
https://www.cloudflare.com/pt-br/learning/dns/glossary/what-is-a-domain-name-registrar/
https://ftp.registro.br/pub/doc/tutorial-dnssec.pdf
https://registro.br/tecnologia/provedores-de-hospedagem/dnsshim/
https://registro.br/tecnologia/dnssec/root-anchor/
https://bind9.readthedocs.io/en/v9.18.14
https://bind9.readthedocs.io/en/latest/
https://www.cloudflare.com/pt-br/dns/dnssec/how-dnssec-works/
https://ftp.registro.br/pub/doc/configuracao_dnssec_dominio.pdf
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
https://www.infoblox.com/dns-security-resource-center/dns-security-faq/what-is-dane/
https://weberblog.net/how-to-use-danetlsa/
https://www.antispam.br/admin/spf/
https://www.locaweb.com.br/ajuda/wiki/spf/
https://www.collegenote.net/curriculum/internet-technology-csit/37/161/
https://registro.br/tecnologia/dnssec/dnssec-para-provedores/
https://www.cloudflare.com/pt-br/learning/dns/dns-over-tls/
https://www.isc.org/blogs/bind-implements-doh-2021/
https://ftp.isc.org/isc/bind9/9.19.21/doc/arm/html/reference.html#namedconf-statement-tls-port
https://ftp.isc.org/isc/bind9/9.19.21/doc/arm/html/reference.html#namedconf-statement-tls
https://unix.stackexchange.com/questions/735368/how-to-use-dns-over-tls-with-bind9-forwarders
https://kb.isc.org/docs/aa-01589
RFCs: https://www.rfc-editor.org/rfc/rfc6781
https://www.rfc-editor.org/rfc/rfc4034
https://www.rfc-editor.org/rfc/rfc4035
https://www.rfc-editor.org/rfc/rfc8310
https://datatracker.ietf.org/doc/html/rfc7858
https://www.rfc-editor.org/rfc/rfc8484.html