Tenho algumas instâncias 17.10 em execução no Amazon EC2 em uma VPC. Quando reinicio um servidor recentemente (não tenho certeza se isso acontece em uma inicialização a frio, não testei), o /etc/resolv.confarquivo aparece vazio:
# 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.
A resolução de nomes falha conforme esperado, por exemplo, ao conectar-se a um servidor com um IP estático na sub-rede privada através do seu nome DNS interno:
ssh: Could not resolve hostname example: Temporary failure in name resolution
Agora, se eu esperar algum tempo, de repente os valores adequados aparecerão em /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
O systemd-resolve --statuscomando relata o mesmo. O /etc/resolv.confarquivo também será configurado corretamente se eu forçar uma dhclientrenovação manualmente e sei que esses valores vêm do servidor DHCP EC2.
Portanto, a questão é: que parte da minha configuração está faltando para impedir que isso aconteça imediatamente após a inicialização?
Adicionar esses valores diretamente a algo como /etc/resolvconf/resolv.conf.d/basefuncionaria, mas estou codificando algo que deve chegar via DHCP, acredito. Eu /etc/netplantambém procurei ( ifupdownnão está sendo usado) e isso parece vir do material de inicialização da nuvem, então me pergunto se talvez esteja faltando alguma coisa /etc/cloud/cloud.cfgou algo semelhante.