On Monday, 11.01.2016 at 00:26, Antti Kantee wrote:
> On 05/01/16 19:05, Martin Lucina wrote:
> >On Monday, 21.12.2015 at 15:25, Martin Lucina wrote:
> >>2. "env", "hostname", "net": Hopefully nothing controversial here. I plan
> >>to add a "net.dns{}" to generate resolv.conf and support for NFS mounts in
> >>some form, tentatively as "net.mount{}".
> >
> >I have now implemented support for configuring the DNS resolver. Excerpt
> >from the spec should be self-explanatory:
>
> > "dns": {
> > "nameservers": [
> > <ip-address>,
> > ...
> > ],
> > "search": [
> > <domain-suffix>,
> > ...
> > ]
> > }
>
> You need to define the semantics wrt. to dhcp (which will hopefully be fixed
> RSN to capture the resolver info), preferably so that those semantics are
> implied by the config format. Does a manual block replace or augment the
> resolver given by dhcp (augmentation above or below), or is the manual block
> ignored if a dhcp address is successfully retrieved?
Ugh. IMO resolv.conf is one of the most under-specified interfaces in UNIX
systems today, looking at the general mess with multiple things fighting
over it on my desktop systems. If resolver configuration was more like a
routing table with metrics and lifetimes then we would be much better off.
For the purposes of rumprun, unless we want to go reinventing resolv.conf
(I think not), we can whittle the usage down to three normal cases:
1) The unikernel does not need to configure DNS servers/manages DNS servers
itself.
2) The user wants to configure DNS statically.
3) The user wants to configure DNS from a single DHCP (or RDNSS for IPv6)
interface.
Option 1) is easy, don't specify anything. Option 2) is the static
"net.dns" configuration. Option 3) can be done by extending the "dhcp"
method syntax, requiring that you explicitly specify an "I want
nameservers" option.
If the config specifies both 2) and 3) then 3) wins and you get a warning
during boot. If you specify more than one interface with 3) then the first
one seen wins and you get a warning on boot.
If you want to do "something else" (worst case) then that usually implies
you have application logic to do it, and is covered by option 1).
I don't think there's much point in supporting a combination of 2) and 3),
or allowing multiple DHCP interfaces to provide nameservers, especially
given that MAXNS==3 so the resulting behaviour is going to be undefined
anyway. Also, if we eventually have a long-running (persistent) DHCP
thread, dealing with "the DHCP nameservers changed" will be a PITA if any
kind of augmenting of the existing list is supposed to happen.
> To me, it seems easier to minimize complexity by not sticking your hands
> into that pile at all, and just let people specify the dns server using
> existing methods; and potentially extend the dhcp configuration to support
> something like dns=yes/no.
DNS is one of the most frequently configured parameters in any
network-connected system. We should make an effort to support it through
our normal configuration mechanism rather than punting on it and saying "go
deal with resolv.conf yourself".
