Task DNS Options

[nickethier]

This PR adds a dns stanza to network {...} which allows setting the dns servers, searches and options. Example:

network {
  dns {
    servers = ["10.0.0.1", "10.0.0.1"]
    searches = ["internal.corp"]
    options = ["ndots:2"]
  }
}

It is implemented to pass on the configuration to task drivers. This means the task driver is responsible for configuring the DNS settings. For executor style drivers, a resolvconf utility package is included to build the resolv.conf file on Linux and generate the drivers.Mount struct to mount it in.

Caveats

• raw_exec is not supported since it doesn't sandbox the filesystem
• qemu only exposes options to set the DNS resolver, thus searches and options are currently ignored.

TODO

• Support all built-in drivers
  • docker
  • exec
  • raw_exec Not supported
  • java
  • qemu
• Update network stanza docs
• Update API docs
• Update example job

fixes #7283 #7393 #6727

[danlsgiga]

Thank you for working on this... its a big blocker for us to use exec task isolation via bridged networks.

[tgross]

This looks great @nickethier. I left one question and some minor cleanup/docs items.

[tgross]

I think it might be valuable to have some brief info here about how this interacts with network isolation. If you set particular IPs as the nameservers, the routing is going to be different if the task uses host networking vs other networking modes (particularly once CNI support is complete). So something like a reminder that this uses the task's view of the network address space.

[tgross]

I really like how clean this makes the task driver tests that need it. 👍

[nickethier]

I borrowed the idea from @notnoop!

[tgross]

It looks like we're only using this function for exec and java task drivers. When we pass the TaskDir into this function to create the HostPath, is that path writable to the task? Mounting it from there read-only to /etc/resolv.conf makes it seem like it shouldn't be. It doesn't seem like a security issue because it's a copy of the host's /etc/resolv.conf and not a mount to it. Are we doing this bind-mount mostly for consistency with how we create mounts?

[nickethier]

Yeah the idea being that if Nomad is going to manage the dns configuration (resolv.conf) then the task shouldn't be able to write to it. I couldn't find a great place to write the resolv.conf as we don't really have a per alloc directory thats not actually accessible from the alloc. I figured mounting as ro would give the "Nomad manages this file" UX even if we change where its mounted from in the future.

I did try and keep the concept of just passing a bind mount consistent as that seems the most compatible way other drivers could consume this.

[tgross]

👍 That all sounds like solid reasoning.

[shoenig]

@nickethier double checking - this is going into master rather than a 0.12 branch?

[nickethier]

No I just haven’t made the 0.12 branch yet.

[github-actions]

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.