Perguntas[domain-name-system](server)

Pesquisei em vários lugares online e todas as fontes parecem sugerir que se trata de um problema de resolução de DNS. No entanto, o DNS resolve bem na minha máquina, e consultas whois para outros TLDs (por exemplo, .com) não apresentam esse problema.

Também tentei em várias máquinas diferentes, obtendo o mesmo resultado.

Mon 04-28 03:49 OVH root ~
> whois google.com | head
   Domain Name: GOOGLE.COM
   Registry Domain ID: 2138514_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.markmonitor.com
   Registrar URL: http://www.markmonitor.com
   Updated Date: 2019-09-09T15:39:04Z
   Creation Date: 1997-09-15T04:00:00Z
   Registry Expiry Date: 2028-09-14T04:00:00Z
   Registrar: MarkMonitor Inc.
   Registrar IANA ID: 292
   Registrar Abuse Contact Email: [email protected]

Mon 04-28 03:49 OVH root ~
> whois icann.org | head
This domain is protected by the Registry Lock service. If you are the registrant and wish to take action on this lock, please contact your registrar.

Domain Name: icann.org
Registry Domain ID: 628dbbcb4edc464b9401cbadea0a08b2-LROR
Registrar WHOIS Server: http://whois.cscglobal.com
Registrar URL: http://www.cscglobal.com/global/web/csc/digital-brand
Updated Date: 2025-01-31T20:19:44Z
Creation Date: 1998-09-14T04:00:00Z
Registry Expiry Date: 2028-12-07T17:04:26Z
Registrar: CSC Corporate Domains, Inc.

Mon 04-28 03:49 OVH root ~
> whois nic.app | head
getaddrinfo(whois.nic.app): Name or service not known

Se, na minha configuração de DNS, eu tiver um registro como este:

sub.example.com NS ns1.nameserverexample.com

As solicitações de pesquisa para subdomínios de sub.example.com(por exemplo, a.sub.example.com) também serão direcionadas para ns1.nameserverexample.com? Ou eu precisaria criar um registro NS adicional para a.sub.example.compara enviar essas solicitações para ns1.nameserverexample.com?

Se possível, eu apreciaria ter uma fonte confiável para quaisquer respostas dadas. Passei algum tempo procurando a resposta, e até agora o Gemini do Google parece dizer que a resposta é "não" (mas não consigo encontrar isso claramente declarado em nenhuma das referências às quais ele faz link) e um comentário do Reddit sem fonte sugere que a resposta é "sim".

Para contexto: estou usando contêineres Podman (rootful) no meu host, que também está conectado a uma Tailscale VPN. O DNS do host é configurado via systemd-resolved.

Desde ontem, tenho lutado com meu contêiner Roundcube (cliente de e-mail da web) extremamente lento para se conectar ao contêiner do meu servidor de e-mail, cada ação (logar, listar pastas, abrir uma mensagem) carregava pelo menos 5 segundos. Então, percebi que cada contêiner /etc/resolv.confcomeçará com as seguintes linhas sempre que o contêiner for iniciado enquanto o Tailscale estiver habilitado:

search headscale.ts.net
nameserver 100.100.100.100
...

Presumo que seja por isso que o contêiner Roundcube primeiro tenta resolver o nome de domínio do servidor de e-mail via Tailscale, o que demora um pouco e depois falha, antes de finalmente resolver o domínio corretamente usando os outros servidores DNS.

Assim que desligo o Tailscale e reinicio o contêiner, tudo funciona perfeitamente e ele /etc/resolv.confnão contém mais o servidor DNS do Tailscale.

Não tenho certeza de como resolver isso, então minha(s) pergunta(s) seria(m):

1. Existe alguma maneira de configurar os contêineres para ignorar a resolução de DNS do Tailscale para domínios que não sejam do Tailscale
2. Como posso dizer ao contêiner para não usar os servidores DNS do Tailscale enquanto ainda o tenho habilitado no host

Estamos procurando um novo VPS.

O VPS vem com 1 IPv4 como padrão. Sempre usamos servidores de caixa de metal contendo funcionalidade de servidor de nomes BIND/DNS dentro. Eles tinham 2 IPs distintos (às vezes, lamentavelmente, na mesma máscara de sub-rede).

Pesquisei na internet e, no geral, é muito ambíguo e muito genérico para me dar dicas úteis. No entanto, esta pergunta está próxima do que estou perguntando: Como configurar meus próprios servidores de nomes com um serviço DNS compartilhado no meu VPS

No entanto, isso é de 2012 e também não responde totalmente à minha pergunta;

Acredito que , ao usar DNS em caixas de metal, preciso de dois IPs distintos para o servidor de nomes ns1.server.come ns2.server.comnão consigo ver nenhum indicador claro se isso continua verdadeiro para servidores VPS.

• Minha crença está correta, por exemplo, precisamos ter dois IPs distintos para melhores práticas para a mesma máquina VPS?

Bônus:

• Há algum benefício em ter o segundo/adicional IP do servidor de nomes como IPv6 em vez de IPv4 [no Reino Unido]?

Configurei um domínio para um amigo ( maple-tree.co.uk). Ele quer poder enviar e receber e-mails neste domínio, e parece estar funcionando, principalmente, mas não totalmente. Alguns servidores de e-mail (BTInternet em particular) não enviam e-mails para este domínio.

Acho que o problema provavelmente está relacionado aos registros DMARC e MX, que parece que estou tendo problemas para configurar. O domínio é hospedado com a GoDaddy, e dentro da ferramenta da GoDaddy ele mostra um registro DMARC como segue:

txt @   v=DMARC1; p=none;   1 Hour      

E um registro MX como segue:

mx  mail    mail.maple-tree.co.uk. (Priority: 0)    1 Hour      

Mas dentro do CPanel para o domínio, embora ele considere os registros SPF e DKIM corretos, ele alega que não há registro DMARC, e o dig / nslookup e várias ferramentas online não mostram o registro MX.

Alguém pode ajudar?

Tenho o bind9 configurado no meu PC roteador. Ele serve como servidor DNS para todas as máquinas na minha rede doméstica. Ele está configurado para que ele só encaminhe solicitações DNS para o stubby (escutando localmente na porta 54321), que então envia essas solicitações DNS com segurança para algum servidor DNS global por TLS. Geralmente está funcionando bem, a menos que ocorra um timeout, como este (retirado de syslogs):

Feb 05 15:51:19 router named[512]: timed out resolving 'accounts.youtube.com/A/IN': 127.0.0.1#54321

Quando liguei tcpdump, descobri que essas solicitações com tempo limite esgotado estão sendo enviadas em texto simples na porta 53 para servidores de nomes aleatórios (?). Sem paciência para solucionar o problema, apenas bloqueei os pacotes de saída na porta 53, e agora alguns novos logs aparecem no syslog (com, obviamente, nenhuma outra solicitação visível no PCAPS de tcpdump) após os logs de tempo limite:

Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.5.6.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.33.14.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.26.92.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.31.80.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.35.51.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.42.93.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.54.112.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.43.172.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.48.79.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.52.178.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.41.162.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.55.83.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.12.94.30#53

O que está acontecendo? Por que o bind9 faz failover para todos esses servidores DNS, ignorando completamente o stubby que está configurado como único encaminhador? Este é meu named.conf.optionsarquivo:

options {
    directory "/var/cache/bind";

    forwarders {
            127.0.0.1 port 54321;
    };

    dnssec-validation yes;

    allow-recursion { localhost; localnets; 192.168.0.0/24; };

    listen-on { 127.0.0.1; 192.168.0.0; };
    listen-on-v6 { none; };
};

Tenho meu servidor DHCP configurado para que ele defina todas as interfaces de rede para todas as máquinas na rede (incluindo o roteador) para que elas usem apenas meu próprio servidor DNS em execução no PC do roteador, então acredito (e os logs parecem confirmar isso) que o bind9 em si decide tentar outros servidores DNS sem que eu o permita explicitamente. Três perguntas surgem:

1. Por que ele faz isso?
2. De onde vêm os servidores de nomes para fazer o failover?
3. Como faço para desabilitar isso? Embora o bloqueio de tráfego de saída na porta 53 funcione, ainda tenho logs destruídos com suas tentativas de tentar outros servidores DNS para resolver solicitações com tempo limite esgotado, e não gosto disso.

Eu acidentalmente excluí o registro DKIM, e o provedor está tendo problemas e não consegue me fornecer o registro DNS com urgência.

Recebi um e-mail deste provedor que foi para a caixa de lixo eletrônico.

Como sei que este e-mail está assinado com uma chave DKIM válida, posso reverter a assinatura e extrair a chave DKIM pública? Depois de extraída, salvarei a chave na página DNS do domínio.

Recebo o seguinte erro:

3.033 Err:32 http://security.ubuntu.com/ubuntu noble-updates/main amd64 linux-libc-dev amd64 6.8.0-51.52
3.034   404  Not Found [IP: 91.189.91.82 80]

ao tentar executar o seguinte comando dentro de um contêiner Docker:

FROM ubuntu:24.04

RUN apt update
RUN apt upgrade

RUN apt -y install build-essential

É um problema relacionado ao DNS?

/etc/resolv.confno contêiner Docker:

# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 172.236.0.51
nameserver 172.236.0.54
nameserver 172.236.0.48
nameserver 172.236.0.46
nameserver 172.236.0.50
nameserver 172.236.0.47
nameserver 172.236.0.53
nameserver 172.236.0.52
nameserver 172.236.0.45
nameserver 172.236.0.49
search members.linode.com ip.linodeusercontent.com

# Based on host file: '/run/systemd/resolve/resolv.conf' (legacy)
# Overrides: []

é diferente da /etc/resolv.confminha máquina host (Ubuntu 24.04):

ll /etc/resolv.conf
lrwxrwxrwx 1 root root 37 Jan 23 18:19 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
cat /etc/resolv.conf

nameserver 127.0.0.53
options edns0 trust-ad
search members.linode.com ip.linodeusercontent.com

mas corresponde /run/systemd/resolve/resolv.confna máquina host.

Não entendo por que tenho dois diferentes resonv.confna minha máquina host.

Também não está claro o suficiente se o DNS dentro do contêiner do Docker está configurado corretamente ou não.

EDITAR1

Rotas no contêiner Docker:

ip route show
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.3

Rotas na máquina host:

ip route show
default via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-7c0ebcfd4e3a proto kernel scope link src 172.18.0.1
172.20.0.0/16 dev br-99d8bde8e488 proto kernel scope link src 172.20.0.1
172.236.0.45 via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.236.0.46 via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.236.0.47 via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.236.0.48 via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.236.0.49 via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.236.0.50 via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.236.0.51 via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.236.0.52 via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.236.0.53 via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.236.0.54 via 172.236.29.1 dev eth0 proto dhcp src 172.236.29.157 metric 1024
172.236.29.0/24 dev eth0 proto kernel scope link src 172.236.29.157 metric 1024
172.236.29.1 dev eth0 proto dhcp scope link src 172.236.29.157 metric 1024

Do contêiner Docker:

ping 91.189.91.82
PING 91.189.91.82 (91.189.91.82) 56(84) bytes of data.
64 bytes from 91.189.91.82: icmp_seq=1 ttl=47 time=82.5 ms
64 bytes from 91.189.91.82: icmp_seq=2 ttl=47 time=82.6 ms

telnet security.ubuntu.com 80
Trying 91.189.91.81...
Connected to security.ubuntu.com.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

EDITAR2

Do contêiner Docker:

root@4e534b3b6847:/# apt install --no-cache linux-libc-dev
E: Command line option --no-cache is not understood in combination with the other options
root@4e534b3b6847:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay          49G   34G   15G  70% /
tmpfs            64M     0   64M   0% /dev
shm              64M     0   64M   0% /dev/shm
/dev/sda         49G   34G   15G  70% /etc/hosts
tmpfs           985M     0  985M   0% /proc/acpi
tmpfs           985M     0  985M   0% /proc/scsi
tmpfs           985M     0  985M   0% /sys/firmware

root@4e534b3b6847:/# apt clean
root@4e534b3b6847:/# apt install linux-libc-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
linux-libc-dev
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,769 kB of archives.
After this operation, 7,508 kB of additional disk space will be used.
Ign:1 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 linux-libc-dev amd64 6.8.0-51.52
Err:1 http://security.ubuntu.com/ubuntu noble-updates/main amd64 linux-libc-dev amd64 6.8.0-51.52
404  Not Found [IP: 185.125.190.82 80]
E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/l/linux/linux-libc-dev_6.8.0-51.52_amd64.deb  404  Not Found [IP: 185.125.190.82 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

EDITAR3

Na máquina host:

  $ apt-cache policy linux-libc-dev
  linux-libc-dev:
  Installed: 6.8.0-52.53
  Candidate: 6.8.0-52.53
  Version table:
  *** 6.8.0-52.53 500
        500 http://mirrors.linode.com/ubuntu noble-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
        100 /var/lib/dpkg/status
     6.8.0-31.31 500
        500 http://mirrors.linode.com/ubuntu noble/main amd64 Packages

No contêiner Docker:

  # apt-cache policy linux-libc-dev
  linux-libc-dev:
  Installed: (none)
  Candidate: 6.8.0-51.52
  Version table:
     6.8.0-51.52 500
        500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
     6.8.0-31.31 500
        500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages

Recentemente configurei o ECMP no firewall da nossa rede para nos conectar totalmente a vários ISPs.

Foi fácil configurar o SPF corretamente, mas esse negócio anti-spam estilo anos 70 nem tanto... Algumas de nossas contrapartes (executando suas próprias instâncias do postfix que precisam continuar aceitando e-mails enviados por mim) insistem em executar o postfix com "reject_unknown_client_hostname", aqui está a definição dos documentos: "Rejeite a solicitação quando 1) o mapeamento de endereço IP do cliente->nome falhar, ou 2) o mapeamento de nome->endereço falhar, ou 3) o mapeamento de nome->endereço não corresponder ao endereço IP do cliente." Basicamente, o registro PTR para um determinado IP precisa estar correto.

Como nosso servidor postfix não sabe qual IP público ele realmente estará egressando para uma determinada conexão, temos que enviar o mesmo nome de servidor na mensagem EHLO, independentemente de qual link ele sai.

A melhor solução que podemos encontrar, sem precisar executar uma instância postfix inteira, é ter registros PTR em ambos os IPs públicos apontando para o mesmo nome de registro A e, então, ter dois registros A para esse nome, um para cada IP. Sei que essa é geralmente uma ideia horrível, pois muitas bibliotecas de SO nem retornam mais de um registro A para um cliente, e isso certamente levará a falhas intratáveis. Quais outras opções existem?

Os seguintes elementos

# postconf myhostname
myhostname = hostname.example.com
# postconf mydomain
mydomain = example.com
# postqueue -p
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
87C5DDD44B*     418 Mon Jan  6 13:02:36  root@ubuntu-4gb-nbg1-1
                                         [email protected]

está resultando em um tempo limite no servidor de e-mail do destinatário:

connect to in-smtp.example.org[192.0.2.1]:25: Connection timed out

O remetente do e-mail é identificado como from=<root@ubuntu-4gb-nbg1-1>em mail.log.

O hostname.example.come example.comtêm seus Aregistros DNS apropriados e TXT SPFregistros permitindo ip4:198.51.100.1.

O provedor de serviços (Hetzner neste caso) tem uma entrada DNS reversa para o endereço IPv4 primário definido como example.com.

Presumi que era a string do remetente do e-mail que estava sendo recusada pelo servidor MX. Mas quando fiz isso, o remetente correto apareceu no log.mail -s 'subject' "From: [email protected]" [email protected]

Então, onde poderia estar faltando a configuração?