Tengo algunas instancias 17.10 ejecutándose en Amazon EC2 en una VPC. Cuando reinicio un servidor (no estoy seguro si sucede en un arranque en frío, no lo he probado), el /etc/resolv.confarchivo se muestra vacío:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
La resolución de nombres falla como se esperaba, por ejemplo, cuando se conecta a un servidor con una IP estática en la subred privada a través de su nombre DNS interno:
ssh: Could not resolve hostname example: Temporary failure in name resolution
Ahora, si espero un período de tiempo, de repente aparecen los valores adecuados en /etc/resolv.conf:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
search subdomain.example.com
El systemd-resolve --statuscomando informa lo mismo. El /etc/resolv.confarchivo también está configurado correctamente si fuerzo manualmente una dhclientrenovación y sé que estos valores provienen del servidor DHCP de EC2.
Entonces la pregunta es: ¿Qué parte de mi configuración falta que impide que esto suceda inmediatamente después del arranque?
Agregar estos valores directamente a algo así /etc/resolvconf/resolv.conf.d/basefuncionaría, pero luego estoy codificando algo que debería llegar a través de DHCP, creo. /etc/netplanTambién miré ( ifupdownno se está usando) y esto parece provenir del material de inicio de la nube, así que me pregunto si tal vez me falta algo /etc/cloud/cloud.cfgo algo similar.