DNS Configuration

    By default, DNS resolution on Flatcar Container Linux is handled through /etc/resolv.conf, which is a symlink to /run/systemd/resolve/resolv.conf. This file is managed by systemd-resolved . Normally, systemd-resolved gets DNS IP addresses from systemd-networkd , either via DHCP or static configuration. DNS IP addresses can also be set via systemd-resolved’s resolved.conf . See Network configuration with networkd for more information on systemd-networkd.

    Using a local DNS cache

    systemd-resolved includes a caching DNS resolver. To use it for DNS resolution and caching, you must enable it via nsswitch.conf by adding resolve to the hosts section.

    Here is an example Butane Config snippet to do that:

    variant: flatcar
    version: 1.0.0
        - path: /etc/nsswitch.conf
          overwrite: true
          mode: 0644
            inline: |
              # /etc/nsswitch.conf:
              passwd:      files usrfiles
              shadow:      files usrfiles
              group:       files usrfiles
              hosts:       files usrfiles resolve dns
              networks:    files usrfiles dns
              services:    files usrfiles
              protocols:   files usrfiles
              rpc:         files usrfiles
              ethers:      files
              netmasks:    files
              netgroup:    files
              bootparams:  files
              automount:   files
              aliases:     files          

    Only nss-aware applications can take advantage of the systemd-resolved cache. Notably, this means that statically linked Go programs and programs running within Docker/rkt will use /etc/resolv.conf only, and will not use the systemd-resolve cache.

    To use systemd-resolved as the default DNS resolver for all applications on the host, switch to the systemd-resolved provided stub-resolv.conf:

    variant: flatcar
    version: 1.0.0
       - path: /etc/resolv.conf
         overwrite: true
         target: /run/systemd/resolve/stub-resolv.conf

    This is known to interfere with Kubernetes in certain situations.