DNS configuration

rkt can automatically prepare /etc/resolv.conf and /etc/hosts for the apps in the pod. They can either be generated at runtime, or the host's configuration can be used.


Four options affect how this file is created:

  • --dns : Specify either a DNS server, or one of the "magic" values host or none
  • --dns-domain : The resolv.conf domain parameter
  • --dns-opt : One or more resolv.conf option parameters
  • --dns-search : One or more domains for the search list

The simplest configuration is:

$ sudo rkt run --dns= pod.aci

Other parameters can be given:

$ sudo rkt run \
    --dns= --dns= \
    --dns-domain=example.org \
    --dns-opt=debug --dns-opt=rotate \
    --dns-search=example.com --dns-search=example.gov \

This will generate the following /etc/resolv.conf for the applications:

# Generated by rkt run

search example.com example.gov
options debug rotate
domain example.org

"Magic" parameters


The magic parameter host will bind-mount the host's /etc/resolv.conf in to the applications. This will be a read-only mount.


The magic parameter none will ignore any DNS configuration from CNI. This will ensure that the image's /etc/resolv.conf has precedence.


resolv.conf can be generated by multiple components. The order of precedence is:

  1. If --dns, et al. are passed to rkt run
  2. If a CNI plugin returns DNS information, unless --dns=none is passed
  3. If a volume is mounted on /etc/resolv.conf
  4. If the application container includes /etc/resolv.conf



rkt run provides one option with two modes:

  • --hosts-entry <IP>=<HOST>
  • --hosts-entry host

Passing --hosts-entry=host will bind-mount (read-only) the hosts's /etc/hosts in to every application.

When passing IP=HOST pairs:

$ rkt run ... --hosts-entry, --hosts-entry

rkt will take some standard defaults and append the requested entries.

< the default entries > host1 host3 host2


/etc/hosts can be generated by multiple components. The order of precedence is:

  1. If --hosts-entry is passed to rkt run
  2. If a volume is mounted on /etc/hosts
  3. If the app image includes /etc/hosts
  4. Otherwise, a fallback stub /etc/hosts is created


The following example shows that the DNS options allow the pod to resolve names successfully:

$ sudo rkt run --net=host --dns= quay.io/coreos/alpine-sh --exec=/bin/ping --interactive -- -c 1 coreos.com

PING coreos.com ( 56 data bytes
64 bytes from seq=0 ttl=63 time=5.421 ms

--- coreos.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 5.421/5.421/5.421 ms