Como as solicitações de pesquisa de DNS de rótulo único são tratadas pelo systemd-resolved?

Esta questão fica muito longa para explicar. A descrição curta (imprecisa) é:

para onde irão as solicitações de pesquisa de rótulo único?

Rótulo único? (não localhostet al.): Sempre ao sistema LLMNR.

Multi-label?: Para os servidores DNS de cada interface. Em caso de falha (ou se não estiver configurado), para os servidores DNS globais.

Sim, a sequência geral segue conforme descrito em systemd-resolved.service(8) MAS :

O roteamento de pesquisas pode ser influenciado pela configuração de nomes de domínio por interface. Veja systemd.network(5) para detalhes.

Define o systemd.network(5) como um recurso adicional para resolução de DNS.

E, entenda que da RFC 4795 :

Como o LLMNR opera apenas no link local, ele não pode ser considerado um substituto para o DNS.

A sequência (simplificada) é:

• O nome de host local configurado é resolvido para todos os endereços IP configurados localmente ordenados por seu escopo, ou — se nenhum estiver configurado — o endereço IPv4 127.0.0.2 (que está no loopback local) e o endereço IPv6 ::1 (que é o hospedeiro local).

• Os nomes de host "localhost" e "localhost.localdomain" (e qualquer nome de host que termine em ".localhost" ou ".localhost.localdomain") são resolvidos para os endereços IP 127.0.0.1 e ::1.

• O nome do host "_gateway" foi resolvido para…

• Os mapeamentos definidos em /etc/hostsestão incluídos (para frente e para trás).

• Se o nome a ser pesquisado não tiver pontos (um nome como home.tem um ponto), ele será resolvido pelo protocolo LLMNR.

  As consultas LLMNR são enviadas e recebidas na porta 5355. RFC 4795

• Nomes de várias palavras (um ponto ou mais) para alguns sufixos de domínio (como ".local", veja a lista completa com systemd-resolve --status) são resolvidos por meio do protocolo MulticastDNS.

• Nomes de várias palavras são verificados na Domains=lista em systemd.network(5) por interface e, se houver correspondência, a lista de servidores DNS dessa interface será usada.

• Outros nomes de vários rótulos são roteados para todas as interfaces locais que possuem um servidor DNS configurado, além do servidor DNS configurado globalmente, se houver.

#Editar

O título da sua pergunta diz:

Como as solicitações de pesquisa de DNS de rótulo único são tratadas pelo systemd-resolved?

Então, eu centralizei minha resposta systemd-resolvedexclusivamente.

Agora você pergunta:

1. Se uma interface estiver configurada com o domínio de pesquisa "mydomain" e LLMNR desabilitado, qualquer solicitação de pesquisa de rótulo único será roteada para essa interface?

2. Se uma interface estiver configurada com o domínio de pesquisa "mydomain" e o LLMNR habilitado e uma solicitação de pesquisa para "xyz" for recebida, "xyz" por meio de LLMNR e "xyz.mydomain" por meio do servidor dns especificado acontecerão?

Aqueles parecem estar fora de systemd-resolvedexclusivamente.

Vamos tentar analisá-los:

• LLMNR desativado? Como? Posso perguntar?. Desabilitando systemd-resolved-se com algo semelhante a systemctl mask systemd-resolved?

Se systemd-resolvedestiver desativado/parado, não há LLMNR em uso (provavelmente, a menos que você instale o Avahi, Apple bonjour ou um programa similar) Mas certamente, isso está fora da systemd-resolvedconfiguração.

Nesse caso, devemos perguntar: o que acontece quando uma resolução de nomes falha? (pois não há servidor para responder). Que está configurado emnsswitch (arquivo /etc/nsswitch.conf). A configuração padrão para o Ubuntu (como Debian) contém esta linha:

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

Isso significa (na linguagem nsswitch):

1. Comece verificando o /etc/hostsarquivo. Se não encontrar, continue.

2. Tente mdns4_minimal( Avahi et al. ) que tentará resolver o nome via DNS multicast somente se terminar com .local. Se isso acontecer, mas nenhum host mDNS estiver localizado, mdns4_minimal retornará NOTFOUND. A resposta de troca de serviço de nome padrão para NOTFOUND seria tentar o próximo serviço listado, mas a entrada [NOTFOUND=return] substitui isso e interrompe a pesquisa com o nome não resolvido. Se mdns4_minimal retornar UNAVAIL (não está em execução), vá para dns.

A trama engrossa todo mundo quer ser o primeiro da lista para resolver nomes e todo mundo se oferece para fazer todas as resoluções sozinho.

3. A dnsentrada na nsswitch verdade chama nss-resolveprimeiro que substitui nss-dns

   nss-resolve é um módulo de plug-in para a funcionalidade GNU Name Service Switch (NSS) da GNU C Library (glibc), permitindo que ele resolva nomes de host por meio do serviço de resolução de nomes de rede local systemd-resolved(8). Ele substitui o módulo de plug-in nss-dns que tradicionalmente resolve nomes de host via DNS.

   O que dependerá das várias DOMAINS=entradas em geral /etc/systemd/resolved.confe/ou de cada interface via /etc/systemd/networkarquivos. Isso foi explicado acima da entrada EDIT .

   Entenda que sytemd-resolved pode consultar os servidores dns sozinho antes da entrada dns no nsswitch.

4. Se ainda não for encontrado (sem [notfound=return]entrada), tente os servidores DNS. Isso acontecerá mais ou menos imediatamente se o nome não terminar em .local, ou não se terminar. Se você remover a entrada [NOTFOUND=return], o nsswitch tentará localizar hosts .local não resolvidos via DNS unicast. Isso geralmente seria uma coisa ruim, pois enviaria muitas dessas solicitações para servidores DNS da Internet que nunca as resolveriam. Aparentemente, isso acontece muito.

5. O final myhostnameatua como um resolvedor de último recurso para localhost, hostname, *.local e alguns outros nomes básicos.

Se systemd-resolvedtiver um LLMNR=noconjunto na /etc/systemd/resolved.confmesma lista acima, aplique, mas systemd-resolvedainda consiga resolver localhoste aplicar DOMAINS=configurações (globais ou por interface).

Entenda que há a configuração LLMNR em systemd-resolved e também há a configuração LLMNR por link em systemd-networkd. ligação .

#O que significa tudo isso? Que é muito difícil dizer com certeza o que acontecerá, a menos que a configuração seja muito, muito específica. você terá que desabilitar os serviços e tentar (no seu computador com sua configuração) o que vai acontecer.

#Q1

Se uma interface estiver configurada com o domínio de pesquisa "mydomain" e LLMNR desabilitado, qualquer solicitação de pesquisa de rótulo único será roteada para essa interface?

Sim, claro, pode . Que o LLMNR esteja desabilitado apenas bloqueia a resolução local (nenhum outro servidor na rede local ( yes: .local ) será solicitado), mas a resolução para esse nome deve encontrar uma resposta (mesmo que negativa) para que possa (se não houver NOTFOUND =entrada de retorno , por exemplo) acontece que os servidores DNS para uma interface correspondente são contatados para resolver mylocalhost.mylocaldomainquando uma resolução para mylocalhostfoi iniciada e há uma entrada para mylocaldomainno "domínio de pesquisa". responder em um sentido geral é quase impossível, muitas variáveis.

#Q2

Se uma interface estiver configurada com o domínio de pesquisa "mydomain" e o LLMNR habilitado e uma solicitação de pesquisa para "xyz" for recebida, "xyz" por meio de LLMNR e "xyz.mydomain" por meio do servidor dns especificado acontecerão?

Não. se tudo estiver configurado corretamente, um único nome de rótulo "xyz" deve ser resolvido apenas por LLMNR e, mesmo que solicitado, um servidor DNS não deve tentar resolvê-lo. Bem, isso é teoria. Mas o sistema DNS deve resolver com(claramente, ou a rede cairia como está agora). Mas existe uma solução simples: solicite com., tem um ponto, é um FQDN. Em qualquer caso, um servidor DNS deve responder com NOERROR(com um A vazio (ou AAAA)) se o servidor não tiver informações suficientes sobre um rótulo e a resolução deve continuar com os servidores raiz (para .). Ou com um NXDOMAIN (a melhor resposta para evitar mais resoluções) para domínios que ele sabe que não existem.

A única maneira segura de controlar isso é ter um servidor DNS local e escolher quais nomes resolver e quais não.

Ele será roteado para todos eles, usando tanto LLMNR quanto DNS e a primeira resposta recebida será usada.

Veja esta parte da página de manual resolvida pelo systemd:

Se as pesquisas forem roteadas para várias interfaces, a primeira resposta bem-sucedida será retornada (combinando efetivamente as zonas de pesquisa em todas as interfaces correspondentes). Se a pesquisa falhou em todas as interfaces, a última resposta com falha será retornada.