"¿Puede alguien darme una idea de por qué esto funciona así y ayudar con alguna solución, si la hay? "
RESPUESTA CORTA:
Se crea una máquina virtual de Azure predeterminada con un DNS roto:systemd-resolved necesita más configuración. sudo systemctl status systemd-resolved lo confirmará rápidamente. /etc/resolv.conf apunta a 127.0.0.53 - un resolutor de stub local no configurado.
El solucionador de código auxiliar local systemd-resolved estaba desconfigurado. No tenía un reenviador configurado, así que después de presionar 127.0.0.53 no tenía a nadie más a quien preguntar. Puaj. Vaya al final para ver cómo configurarlo para Ubuntu 18.04.
Si le interesa cómo se llegó a esa conclusión, lea la respuesta larga.
RESPUESTA LARGA:
Por qué las respuestas de DNS se truncaron en 512 bytes:
TCP [RFC793] siempre se usa para transferencias de zona completa (usando AXFR) y se usa a menudo para mensajes cuyo tamaño excede el límite original de 512 bytes del protocolo DNS.
Fuente:https://tools.ietf.org/html/rfc7766
ANÁLISIS:
Esto fue más complicado de lo que pensaba. Así que hice girar una máquina virtual Ubuntu 18.04 en Azure para poder probar desde el punto de vista del OP:
Mi punto de partida fue validar que nada estuviera ahogando las consultas de DNS:
sudo iptables -nvx -L
sudo apparmor_status
Todas las cadenas en iptables tenían su política predeterminada establecida en ACEPTAR y aunque Apparmor se configuró en "hacer cumplir ", no estaba en nada relacionado con el DNS. Por lo tanto, no se observaron problemas de conectividad o permisos en el host en este momento.
A continuación, necesitaba establecer cómo las consultas de DNS estaban dando vueltas a través de los engranajes.
cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0
search ns3yb2bs2fketavxxx3qaprsna.zx.internal.cloudapp.net
Entonces de acuerdo con resolv.conf , el sistema espera un resolutor de stub local llamado systemd-resolved . Comprobando el estado de systemd-resolved según la sugerencia dada en el texto anterior, vemos que es error :
sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2019-10-08 12:41:38 UTC; 1h 5min ago
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 871 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 441)
CGroup: /system.slice/systemd-resolved.service
└─871 /lib/systemd/systemd-resolved
Oct 08 12:42:14 test systemd-resolved[871]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
<Snipped repeated error entries>
/etc/nsswitch.conf establecer el orden de las fuentes de las fuentes utilizadas para resolver las consultas de DNS. ¿Qué nos dice esto?:
hosts: files dns
Bueno, las consultas de DNS nunca llegarán al systemd-resolved local. resolución de código auxiliar ya que no se especifica en /etc/nsswitch.conf .
¿Están configurados los reenviadores para el systemd-resolved? resolver stub?!?!? Revisemos esa configuración en /etc/systemd/resolved.conf
[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes
No:systemd-resolved no tiene un reenviador configurado para preguntar si no se encuentra una asignación de nombre:ip local.
El resultado neto de todo esto es:
-
/etc/nsswitch.conf envía consultas de DNS a DNS si no hay una IP:nombre local mapeo encontrado en
/etc/hosts -
El servidor DNS a consultar es
127.0.0.53y acabamos de ver que esto no está configurado al revisar su archivo de configuración/etc/systemd/resolved.conf. Sin un reenviador especificado aquí, no hay forma de que resolvamos nada con éxito.
PRUEBA:
Intenté anular el resolutor de código auxiliar 127.0.0.53 especificando directamente 168.63.129.16. Esto falló:
dig aerserv-bc-us-east.bidswitch.net 168.63.129.16
; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> aerserv-bc-us-east.bidswitch.net 168.63.129.16
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24224
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;168.63.129.16. IN A
;; Query time: 13 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 08 13:26:07 UTC 2019
;; MSG SIZE rcvd: 42
No:viendo ;; SERVER: 127.0.0.53#53(127.0.0.53) en el resultado nos dice que no lo hemos anulado y que todavía se está utilizando el resolutor de stub local no configurado.
Sin embargo, el uso de cualquiera de los siguientes comandos anuló el 127.0.0.53 predeterminado stub resolver y, por lo tanto, logró devolver NOERROR resultados:
sudo dig aerserv-bc-us-east.bidswitch.net @168.63.129.16
o
dig +trace aerserv-bc-us-east.bidswitch.net @168.63.129.16
Entonces, cualquier consulta que se basara en el uso de systemd-resolved Los resolutores de stub estaban condenados hasta que se configuraron.
SOLUCIÓN:
Mi inicial- incorrecto - se creía que TCP/53 estaba siendo bloqueado:todo el "Truncado 512 " fue un poco como una cortina de humo. El resolutor de stub no estaba configurado. Supuse, lo sé, lo sé, "NUNCA ASUMAS;-) - que el DNS estaba configurado de otra manera.
Cómo configurar systemd-resolved :
Ubuntu 18.04
Edite el hosts directiva en /etc/nsswitch.conf como se muestra a continuación anteponiendo resolve para establecer systemd-resolved como primera fuente de resolución de DNS:
hosts: resolve files dns
Edite el DNS directiva (como mínimo) en /etc/systemd/resolved.conf para especificar el reenviador deseado, que en este ejemplo sería:
[Resolve]
DNS=168.63.129.16
Reiniciar systemd-resolved :
sudo systemctl restart systemd-resolved
RHEL 8:
Red Hat casi hace todo por usted con respecto a la configuración de systemd-resolved como un resolutor de stubs, ¡excepto que no le dijeron al sistema que lo usara!
Edite el hosts directiva en /etc/nsswitch.conf como se muestra a continuación anteponiendo resolve para configurar systemd-resolved como primera fuente de resolución de DNS:
hosts: resolve files dns
Luego reinicie systemd-resolved :
sudo systemctl restart systemd-resolved
Fuente :https://www.linkedin.com/pulse/config-rhel8-local-dns-caching-terrence-houlahan/
CONCLUSIÓN:
Una vez systemd-resolved se configuró el DNS de mi máquina virtual de prueba se comportó de la manera esperada. Creo que eso es suficiente....