No macOS 26, configurações de DNS personalizadas como .internal deixam de funcionar

(gist.github.com/adamamyl)

2 pontos por GN⁺ 2026-03-21 | 3 comentários | Compartilhar no WhatsApp

No macOS 26.3.1, as configurações de DNS por domínio baseadas em /etc/resolver/ deixam de valer para TLDs não padrão, interrompendo ambientes locais de desenvolvimento já existentes
O mDNSResponder passa a tratar requisições para TLDs personalizados apenas como mDNS, sem consultar de forma alguma os nameservers unicast configurados
.internal, .test, .home.arpa, .lan e, de forma geral, TLDs fora da root zone da IANA falham, enquanto domínios padrão (google.com etc.) continuam funcionando normalmente
A única solução temporária é registrar manualmente no /etc/hosts, mas isso é impraticável em ambientes dinâmicos (Docker, Kubernetes etc.)
Todo o workflow de DNS local usado há anos pela comunidade de desenvolvedores macOS fica comprometido, com impacto amplo em ferramentas de desenvolvimento e recursos de integração com VPN

Regressão de DNS no macOS 26

No macOS 26.3.1 (Darwin 25.3.0, Build 25D771280a), o recurso de DNS por domínio via /etc/resolver/ está quebrado
- O recurso funcionava normalmente até o macOS 25.x, mas parou após a atualização para a versão 26
- Apesar de estar documentado oficialmente pela Apple (man 5 resolver), ele deixou de funcionar para TLDs não padrão
O mDNSResponder intercepta todas as requisições para TLDs personalizados, ignorando os nameservers unicast configurados
- Todos os aplicativos que usam getaddrinfo() (ping, curl, python3 socket) retornam erro “Unknown host”
- Pelo tcpdump, não há qualquer tráfego para o DNS local (127.0.0.1:53)
- No comando dns-sd -G v4, aparece a resposta “No Such Record” e um TTL anormalmente alto (cerca de 108.002 segundos)

Testes e procedimento de reprodução

Configurar o dnsmasq instalado via Homebrew como resolvedor DNS local e mapear domínios *.internal ou *.example-private para 127.0.0.1
- No arquivo /etc/resolver/example-private, definir nameserver 127.0.0.1
- O comando scutil --dns mostra que o resolvedor foi registrado corretamente
- Mesmo assim, ao executar ping probe.example-private, ocorre o erro “Unknown host”
Os comandos dig @127.0.0.1 e host retornam respostas normais, mas todos os apps que usam o resolvedor do sistema falham
- Isso acontece porque o mDNSResponder bloqueia internamente a query e não chega a chamar o DNS unicast

Lista de TLDs afetados

TLD	Status	Observação
`.internal`	Falha	TLD de uso especial em rascunho do IETF; funcionava no macOS 25
`.test`	Falha	Reservado para testes locais conforme RFC 6761 §6.2
`.home.arpa`	Falha	Reservado para redes domésticas conforme RFC 8375
`.lan`	Falha	Não oficial, mas amplamente usado
Outros TLDs não registrados	Falha	Todos os TLDs ausentes da root zone da IANA

No caso de .test, mesmo devendo ser resolvido via DNS normal conforme a RFC 6761, o macOS 26 o trata como exclusivo de mDNS
Em contrapartida, domínios registrados na IANA como google.com e bbc.co.uk continuam funcionando normalmente

Impacto em ambientes e ferramentas de desenvolvimento

Todo o workflow de DNS para desenvolvimento local fica quebrado
- Desenvolvedores que usam a combinação dnsmasq + /etc/resolver/ com *.test, *.internal etc.
- O recurso de resolução de nomes de contêineres do Docker Desktop e ferramentas similares
- Vagrant, Tailscale e clientes VPN que geram automaticamente arquivos em /etc/resolver/
- Ferramentas de desenvolvimento local para Kubernetes (minikube, kind, k3d etc.) na resolução de *.cluster.local
Como o sistema mostra a configuração do resolvedor como normal em scutil --dns, o usuário tem dificuldade para perceber o problema, e não há logs nem mensagens de erro úteis

Solução temporária e limitações

A única forma que funciona é adicionar manualmente o mapeamento de domínio em /etc/hosts
- Isso contorna completamente o mDNSResponder
- Porém, é impraticável em Docker ou ambientes com DNS dinâmico e exige privilégios sudo sempre que houver alteração

Especificações técnicas e ambiente de validação

macOS 26.3.1 (Build 25D771280a), Apple Silicon (arm64)
dnsmasq instalado via Homebrew, escutando em 127.0.0.1:53
Os comandos dig e host respondem normalmente; ping, curl e python3 socket.getaddrinfo falham
Documentação e padrões relacionados:
- man 5 resolver — documentação do mecanismo /etc/resolver/ no macOS
- RFC 6761 — definição de domínios de uso especial como .test, .localhost, .invalid, .example
- RFC 8375 — definição do domínio home.arpa
- IETF draft-ietf-dnsop-interneti-mdn — rascunho do domínio de uso especial .internal

3 comentários

lidar 2026-03-22

Por causa disso, não consigo usar o MagicDNS do Tailscale há dias..

minhoryang 2026-03-21

Espero que o Tailscale consiga contornar esse problema.

GN⁺ 2026-03-21

Comentários do Hacker News

Saí do macOS por causa desses pequenos incômodos (papercuts)
Escrever relatórios de bug com LLM é aceitável se houver revisão, mas quando erros óbvios como “funcionava no macOS 25” entram sem correção, a credibilidade cai
Se esse tipo de relatório aumentar, acho que as pessoas vão simplesmente descartar relatórios escritos por IA por causa do custo de verificação
- Acho totalmente inaceitável usar conteúdo gerado por IA sem deixar isso explícito
  Fazer a IA escrever em meu nome passa a impressão rude de que meu tempo vale mais que o seu
  Se for constrangedor admitir publicamente que você usou IA, isso por si só já é motivo para repensar esse uso
- Todo sistema operacional tem esse tipo de pequeno incômodo
  Dá para listar casos igualmente dolorosos no Linux ou no Windows. No fim, é uma questão de “qual veneno escolher”
- Esse tipo de problema é uma tradição da Apple que já dura décadas
  A Microsoft era conhecida por manter compatibilidade retroativa, enquanto a Apple ficou famosa por quebrar funcionalidades existentes sem medo
  Hoje em dia, a Microsoft também não é tão conservadora quanto antes, e a Apple até parece mais estável do que já foi
- De qualquer forma, a Apple já tem fama há muito tempo de não ler direito os relatórios, então mesmo que passe a descartar relatórios gerados por LLM, provavelmente nada muda
- Já passei por esses pequenos incômodos em todos os sistemas, mas no Linux é fácil fazer rollback
  Em algo como o NixOS, basta escolher a versão anterior no menu de boot e o sistema inteiro volta ao estado anterior
  No notebook eu uso macOS, mas na prática faço quase todo o trabalho dentro de containers Linux
O macOS 26 é, até agora, a versão que mais quebrou compatibilidade
Várias mudanças intencionais tornaram o desenvolvimento de apps muito mais difícil
Por exemplo, o app Lunar não consegue mais definir livremente os valores de nits SDR, o que bloqueou o controle de brilho,
e o app YellowDot ficou inutilizável porque o ajuste de brilho do indicador de microfone foi bloqueado
Além disso, há vários bugs, como problemas com eventos de mouse em janelas sem título, impossibilidade de aplicar tabelas gamma,
e perda do caminho do arquivo original ao arrastar em apps como Clop
- Há rumores de que o iOS 27 será uma versão de estabilização no estilo Snow Leopard
  Espero que o macOS 27 também seja assim (fonte)
- Como alguém que produz música por hobby, o indicador de microfone é realmente desnecessário e irritante
  A filosofia do macOS parece teimosa e unilateral demais, o que é frustrante
- Fico pensando se o problema do YellowDot não poderia ser contornado usando LUT para mapear a cor do ponto de gravação para preto
  Não uso macOS diretamente, mas em teoria parece possível
- Então era por isso que no M1 dava para ir até 1600 nits e no M5 não passa de 600 nits
  Pelo jeito vou ter que desistir por enquanto
- A limitação de brilho do ponto do microfone existe por motivo de proteção de privacidade
  A ideia é impedir que malware esconda o acesso à câmera e ao microfone
  Além disso, o limite de brilho SDR pode ter sido pensado para prevenir antecipadamente problemas de bateria nos futuros displays OLED
Ainda espero pelo dia em que a Apple separe hardware e software
Quero Apple Silicon, mas não quero o sistema operacional deles
Se eu não puder rodar meu próprio kernel e meus próprios módulos, então esse equipamento não é meu
O notebook ao lado inicializa com coreboot, e isso mostra bem minha filosofia
- Não dá para rodar seu próprio kernel no Mac? O problema não é mais suporte a drivers?
- O macOS não é perfeito, mas chamar tudo de “terrível” me parece uma avaliação exagerada
- Eu também não odeio o macOS. Só acho pouco convincente cravar que ele é “terrível”
No desenvolvimento web local eu uso *.localhost
Todos os navegadores modernos resolvem isso automaticamente para 127.0.0.1, então não é preciso configurar DNS nem mexer no hosts
Só que isso não se aplica a programas fora do navegador (python, wget etc.)
- *.*.localhost também é suportado, então agora dá para replicar localmente a mesma estrutura de domínio da produção
  O ArchiveBox usa isso para implementar isolamento de domínio por snapshot e reduzir riscos de segurança
- No Tahoe funciona bem também com python e wget
- Testei no Chrome e imagino que no Safari funcione do mesmo jeito
- Eu também uso esse método. Só acho .localhost meio longo
  Antes eu usava .local, mas dava muito conflito
- Nós usamos dev.our-root-domain.com mapeado para 127.0.0.1 no DNS público
Em uma máquina antiga com Yosemite, venho usando uma configuração que fornece vários TLDs locais
O método /etc/resolver já estava marcado para descontinuação desde algo como 2014, e agora parece ter sido removido de vez
O caminho correto agora é salvar a configuração usando scutil diretamente
- Mas só scutil não basta
  Algumas consultas no macOS ainda passam pelo mDNSResponder, que ignora ou sobrescreve essa configuração
  Então, no fim das contas, usar unbound ou dnsmasq acaba sendo mais simples
Eu também uso vários TLDs com a combinação de /etc/resolver/X e dnsmasq, e não tive problemas
Sempre incluo a diretiva domain no arquivo de configuração
Na prática, quase sempre isso foi necessário
Talvez adicionar a entrada domain resolva o problema
Eu uso Linux na maior parte do tempo, mas não entendo muito bem por que as pessoas dizem que o design do macOS é ruim
Olhando só para UX, o macOS sempre me pareceu bem refinado
A maioria dos temas populares do Gnome também imita o estilo do macOS
- Na internet existe um viés que dá mais visibilidade às pessoas mais insatisfeitas
  Acho que isso é ainda mais forte no HN
- A versão Tahoe também esteve boa na maior parte do tempo
  Ajustar o tamanho das bordas das janelas é meio incômodo, mas no geral estou satisfeito
  No fim, todo sistema operacional tem bugs
- Por causa da cultura da Apple de acréscimo excessivo de funcionalidades (feature creep), a UX muitas vezes muda desnecessariamente a cada versão
  As caixas de diálogo de notificação são um bom exemplo disso
- Também acho o senso estético do macOS bom
  Só sinto falta de mais opções de personalização
  Talvez sentir saudade de interfaces antigas como a do Windows 98 seja apenas uma questão geracional
- No geral eu gosto da UX
  O jeito como ele faz a transição para tela cheia é peculiar, mas depois que você se acostuma fica confortável
  Só que a falta de window tiling incomoda
  Mesmo assim, ainda prefiro Linux, embora suspend e gerenciamento de energia já sejam um problema há 8 anos
Houve uma época em que a Apple bloqueou certificados autoassinados no iOS, o que quase tornou impossível desenvolver HTTPS localmente
É difícil entender por que mexeram nisso
Eu gosto de macOS
Ele já vem com zsh por padrão, e eu consigo fazer no meu computador pessoal quase tudo o que fazia no Linux
*.localhost funciona por padrão
Dá para apontar vários nomes de host para 127.0.0.1 sem dnsmasq
- Mas quando é preciso mapear IPs privados internos para outros endereços, essa abordagem não basta
- Domínios como *.example-private são necessários para distinguir vários dispositivos por IP privado
  Se for só para localhost, basta usar 127.0.0.1
  Pessoalmente, eu uso mDNS com *.local para aproveitar a configuração automática baseada em DHCP