# [SOLVED] dns_options in /etc/conf.d/net apparently ignored

## orionbelt

My /etc/conf.d/net consists of this single line:

```
dns_options="rotate single-request-reopen"
```

However, when i restart the net service the line "rotate single-request-reopen" does not appear in /etc/resolv.conf:

```
# /etc/init.d/net.enp2s0 restart

 * Caching service dependencies ...                                       [ ok ]

 * Bringing down interface enp2s0

 *   Stopping udhcpc on enp2s0 ...                                        [ ok ]

RTNETLINK answers: No such file or directory

Error talking to the kernel

 * Bringing up interface enp2s0

 *   config_enp2s0 not specified; defaulting to DHCP

 *   dhcp ...

 *     Running udhcpc ...

udhcpc: started, v1.28.0

udhcpc: sending discover

udhcpc: sending select for 172.x.x.x

udhcpc: lease of 172.x.x.x obtained, lease time 43200                     [ ok ]

 *     received address 172.x.x.x/24                                      [ ok ]

 *   Waiting for IPv6 addresses (5 seconds) .                             [ ok ]

# grep rotate /etc/resolv.conf

#
```

I also tried the following format, which i found in older comments, but it did not work either:

```
dns_options=( "rotate" "single-request-reopen" )
```

Any ideas?Last edited by orionbelt on Wed Aug 08, 2018 9:30 am; edited 1 time in total

----------

## khayyam

orionbelt ...

you need to use a dhcp client other than udhcpc, its 'default.script' doesn't handle 'options':

```
echo "Recreating $RESOLV_CONF"

# If the file is a symlink somewhere (like /etc/resolv.conf

# pointing to /run/resolv.conf), make sure things work.

realconf=$(readlink -f "$RESOLV_CONF" 2>/dev/null || echo "$RESOLV_CONF")

tmpfile="$realconf-$$"

> "$tmpfile"

[ -n "$domain" ] && echo "search $domain" >> "$tmpfile"

for i in $dns ; do

   echo " Adding DNS server $i"

   echo "nameserver $i" >> "$tmpfile"

done

mv "$tmpfile" "$realconf"
```

So, emerge net-misc/dhcpcd or some other dhcp client.

 *orionbelt wrote:*   

> I also tried the following format, which i found in older comments, but it did not work either:
> 
> ```
> dns_options=( "rotate" "single-request-reopen" )
> ```
> ...

 

This syntax ... using bash array's ... is nolonger supported.

best ... khay

----------

## orionbelt

khayyam,

Many thanks for the reply!

In fact, i had net-misc/dhcp installed. Not sure why /etc/init.d/net.enp2s0 was using udhcpc instead...

I now uninstalled net-misc/dhcp and installed net-misc/dhcpcd but the problem persists: The line "rotate single-request-reopen" still does not appear in /etc/resolv.conf.

However, if i put the line in /etc/resolv.conf.tail, it now gets appended at the end of /etc/resolv.conf, so this essentially solves my problem! Previously, udhcpc (or dhcp...) was ignoring the contents of /etc/resolv.conf.tail.

But it would still be nice to sort out this problem or make a bug report if it is a bug. As far as i can tell, dhcpcd generates /etc/resolv.conf using /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf. I cannot see any reference to dns_options in that script, only to domain and search servers, but i do not pretend to fully understand its workings...

----------

## khayyam

 *orionbelt wrote:*   

> However, if i put the line in /etc/resolv.conf.tail, it now gets appended at the end of /etc/resolv.conf, so this essentially solves my problem! Previously, udhcpc (or dhcp...) was ignoring the contents of /etc/resolv.conf.tail.

 

orionbelt ... I'm not sure why, but it works here:

```
% grep dns_options /etc/conf.d/net.wlan1

dns_options_wlan1="edns0"

% grep options /etc/resolv.conf

options edns0
```

 *orionbelt wrote:*   

> But it would still be nice to sort out this problem or make a bug report if it is a bug. As far as i can tell, dhcpcd generates /etc/resolv.conf using /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf. I cannot see any reference to dns_options in that script, only to domain and search servers, but i do not pretend to fully understand its workings...

 

It's not dhcpcd that provides this but /lib/netifrc/net/system.sh, and on closer inspection it should in fact work with udhcpc. Why it doesn't in your case I'm not sure, do you perhaps have net-dns/openresolv installed?

best ... khay

----------

## orionbelt

I see that you use /etc/conf.d/net.wlan1 and not /etc/conf.d/net, which is what is mentioned in the handbook. I tried both /etc/conf.d/net and /etc/conf.d/net.enp2s0 but neither name worked.

I also tried both dns_options and dns_options_enp2s0, again to no avail (so, 4 combinations in all).

And i do not have net-dns/openresolv installed.

My netifrc is net-misc/netifrc-0.5.1:0.

Bummer?...   :Rolling Eyes: 

You said it is /lib/netifrc/net/system.sh that provides this. I placed an echo statement just before these lines in /lib/netifrc/net/system.sh:

```
echo HELLO

eval options=\$dns_options_${IFVAR}

   [ -z "${options}" ] && options=${dns_options}
```

but nothing gets printed out when i run the dhcpcd init script. Could this mean that /lib/netifrc/net/system.sh is never even run?

----------

## khayyam

 *orionbelt wrote:*   

> I see that you use /etc/conf.d/net.wlan1 and not /etc/conf.d/net, which is what is mentioned in the handbook. I tried both /etc/conf.d/net and /etc/conf.d/net.enp2s0 but neither name worked.

 

orionbelt ... well, little known fact, openrc/netifrc supports per interface (and/or runlevel) init/config with the syntax 'service.{interface}.{runlevel}' ... see here for an example.

 *orionbelt wrote:*   

> My netifrc is net-misc/netifrc-0.5.1:0.

 

Mine is 0.2.2 ... I don't update openrc/netifrc as random breakage/incompetance has become the norm. 

 *orionbelt wrote:*   

> You said it is /lib/netifrc/net/system.sh that provides this. I placed an echo statement just before these lines in /lib/netifrc/net/system.sh [...] but nothing gets printed out when i run the dhcpcd init script. Could this mean that /lib/netifrc/net/system.sh is never even run?

 

Notice there is no interpreter provided, it contains definitions/functions and so is sourced, rather than executed, so you might only see output if that function containing the 'echo' is called.

best ... khay

----------

## orionbelt

 *khayyam wrote:*   

>  *orionbelt wrote:*   I see that you use /etc/conf.d/net.wlan1 and not /etc/conf.d/net, which is what is mentioned in the handbook. I tried both /etc/conf.d/net and /etc/conf.d/net.enp2s0 but neither name worked. 
> 
> orionbelt ... well, little known fact, openrc/netifrc supports per interface (and/or runlevel) init/config with the syntax 'service.{interface}.{runlevel}' ... see here for an example.

 

Little known (and documented), indeed. Thanks.

 *khayyam wrote:*   

>  *orionbelt wrote:*   My netifrc is net-misc/netifrc-0.5.1:0. 
> 
> Mine is 0.2.2 ... I don't update openrc/netifrc as random breakage/incompetance has become the norm. 

 

I downgraded net-misc/netifrc to 0.2.2 but it didn't fix the problem. My sys-apps/openrc is 0.34.11 and in any case there is no earlier version available on portage.

I have never experienced, to my knowledge, any problems due to upgrading openrc/netifrc, but then again my setup is boringly standard.

 *khayyam wrote:*   

>  *orionbelt wrote:*   You said it is /lib/netifrc/net/system.sh that provides this. I placed an echo statement just before these lines in /lib/netifrc/net/system.sh [...] but nothing gets printed out when i run the dhcpcd init script. Could this mean that /lib/netifrc/net/system.sh is never even run? 
> 
> Notice there is no interpreter provided, it contains definitions/functions and so is sourced, rather than executed, so you might only see output if that function containing the 'echo' is called.

 

But i put the 'echo' right before the place where (i think) dns_options are handled. So if that function is not called, it would explain why dns_options are not passed...

----------

## khayyam

 *orionbelt wrote:*   

> I downgraded net-misc/netifrc to 0.2.2 but it didn't fix the problem. My sys-apps/openrc is 0.34.11 and in any case there is no earlier version available on portage.

 

orionbelt ... there isn't no, I have =sys-apps/openrc-0.12.4 in a local overlay. 

 *orionbelt wrote:*   

> I have never experienced, to my knowledge, any problems due to upgrading openrc/netifrc, but then again my setup is boringly standard.

 

I was at one point following every commit, but for various reasons realised that something was seriously wrong with how the project was managed. That's mostly about decisions made, rather than being the subject of their effects ... but I won't accept people playing willy-nilly with a critical component of my system.

 *khayyam wrote:*   

> Notice there is no interpreter provided, it contains definitions/functions and so is sourced, rather than executed, so you might only see output if that function containing the 'echo' is called.

 

 *orionbelt wrote:*   

> But i put the 'echo' right before the place where (i think) dns_options are handled. So if that function is not called, it would explain why dns_options are not passed...

 

Not really, it suggests only that it's not getting called, or that some corner case is being hit. Again, I don't know why, it works here, but then you might try being a little more explcit in conf.d/net, eg:

```
modules_enp2s0="!plug dhcpcd"

config_enp2s0="dhcp"

dns_options_enp2s0="rotate single-request-reopen"
```

Not sure that will have any effect, but as the default is triggered in absence of config_* and modules_* it may be a case that dns_options are ignored if that is the case.

HTH & best ... khay

----------

## orionbelt

 *khayyam wrote:*   

> Notice there is no interpreter provided, it contains definitions/functions and so is sourced, rather than executed, so you might only see output if that function containing the 'echo' is called.

 

 *orionbelt wrote:*   

> But i put the 'echo' right before the place where (i think) dns_options are handled. So if that function is not called, it would explain why dns_options are not passed...

 

 *khayyam wrote:*   

> Not really, it suggests only that it's not getting called, or that some corner case is being hit.

 

Well, wouldn't it be a bit peculiar if the call were made at some place other than system.sh, which seems to be the main script for starting dhcp and it does include code to handle the dns_options functionality?...

 *khayyam wrote:*   

> Again, I don't know why, it works here, but then you might try being a little more explcit in conf.d/net, eg:
> 
> ```
> modules_enp2s0="!plug dhcpcd"
> 
> ...

 

A reasonable suggestion in the face of desperation    :Confused:   but unfortunately it did not work either.

I thought of tracing code execution to figure it out but i am not sure how. /etc/init.d/dhcpcd provides a debug option which produces this output:

```
# /etc/init.d/dhcpcd -d start

+ sourcex -e /etc/rc.conf

+ '[' -e = -e ']'

+ shift

+ '[' -e /etc/rc.conf ']'

+ . /etc/rc.conf

++ rc_shell=/sbin/sulogin

++ unicode=YES

++ rc_tty_number=12

+ '[' -d /etc/rc.conf.d ']'

+ _conf_d=/etc/init.d/../conf.d

+ _c=dhcpcd

+ '[' -n dhcpcd -a dhcpcd '!=' dhcpcd ']'

+ unset _c

+ sourcex -e /etc/init.d/../conf.d/dhcpcd.default

+ '[' -e = -e ']'

+ shift

+ '[' -e /etc/init.d/../conf.d/dhcpcd.default ']'

+ return 1

+ sourcex -e /etc/init.d/../conf.d/dhcpcd

+ '[' -e = -e ']'

+ shift

+ '[' -e /etc/init.d/../conf.d/dhcpcd ']'

+ return 1

+ unset _conf_d

+ sourcex /lib64/rc/sh/runit.sh

+ '[' /lib64/rc/sh/runit.sh = -e ']'

+ . /lib64/rc/sh/runit.sh

+ sourcex /lib64/rc/sh/s6.sh

+ '[' /lib64/rc/sh/s6.sh = -e ']'

+ . /lib64/rc/sh/s6.sh

++ '[' -z '' ']'

++ s6_service_path=/var/svc.d/dhcpcd

+ sourcex /lib64/rc/sh/start-stop-daemon.sh

+ '[' /lib64/rc/sh/start-stop-daemon.sh = -e ']'

+ . /lib64/rc/sh/start-stop-daemon.sh

+ sourcex /lib64/rc/sh/supervise-daemon.sh

+ '[' /lib64/rc/sh/supervise-daemon.sh = -e ']'

+ . /lib64/rc/sh/supervise-daemon.sh

+ sourcex /etc/init.d/dhcpcd

+ '[' /etc/init.d/dhcpcd = -e ']'

+ . /etc/init.d/dhcpcd

++ command=/sbin/dhcpcd

++ pidfile=/var/run/dhcpcd.pid

++ command_args=-q

++ name='DHCP Client Daemon'

+ yesno ''

+ '[' -z '' ']'

+ return 1

+ for _cmd in "$@"

+ '[' start '!=' status -a start '!=' describe ']'

+ '[' -n '' ']'

++ command -v cgroup_add_service

+ '[' cgroup_add_service = cgroup_add_service ']'

+ '[' -d /sys/fs/cgroup -a '!' -w /sys/fs/cgroup ']'

+ cgroup_add_service /sys/fs/cgroup/openrc

+ for d in /sys/fs/cgroup/*

+ '[' -w /sys/fs/cgroup/cpuacct/tasks ']'

+ printf %d 0

+ for d in /sys/fs/cgroup/*

+ '[' -w /sys/fs/cgroup/cpuset/tasks ']'

+ printf %d 0

+ for d in /sys/fs/cgroup/*

+ '[' -w /sys/fs/cgroup/openrc/tasks ']'

+ printf %d 0

+ for d in /sys/fs/cgroup/*

+ '[' -w /sys/fs/cgroup/unified/tasks ']'

+ openrc_cgroup=/sys/fs/cgroup/openrc

+ '[' -d /sys/fs/cgroup/openrc ']'

+ cgroup=/sys/fs/cgroup/openrc/dhcpcd

+ mkdir -p /sys/fs/cgroup/openrc/dhcpcd

+ '[' -w /sys/fs/cgroup/openrc/dhcpcd/tasks ']'

+ printf %d 0

+ cgroup_add_service /sys/fs/cgroup/systemd/system

+ for d in /sys/fs/cgroup/*

+ '[' -w /sys/fs/cgroup/cpuacct/tasks ']'

+ printf %d 0

+ for d in /sys/fs/cgroup/*

+ '[' -w /sys/fs/cgroup/cpuset/tasks ']'

+ printf %d 0

+ for d in /sys/fs/cgroup/*

+ '[' -w /sys/fs/cgroup/openrc/tasks ']'

+ printf %d 0

+ for d in /sys/fs/cgroup/*

+ '[' -w /sys/fs/cgroup/unified/tasks ']'

+ openrc_cgroup=/sys/fs/cgroup/openrc

+ '[' -d /sys/fs/cgroup/openrc ']'

+ cgroup=/sys/fs/cgroup/openrc/dhcpcd

+ mkdir -p /sys/fs/cgroup/openrc/dhcpcd

+ '[' -w /sys/fs/cgroup/openrc/dhcpcd/tasks ']'

+ printf %d 0

++ command -v cgroup_set_limits

+ '[' cgroup_set_limits = cgroup_set_limits ']'

+ cgroup_set_limits

+ local blkio=

+ '[' -n '' ']'

+ local cpu=

+ '[' -n '' ']'

+ local cpuacct=

+ '[' -n '' ']'

+ local cpuset=

+ '[' -n '' ']'

+ local devices=

+ '[' -n '' ']'

+ local hugetlb=

+ '[' -n '' ']'

+ local memory=

+ '[' -n '' ']'

+ local net_cls=

+ '[' -n '' ']'

+ local net_prio=

+ '[' -n '' ']'

+ local pids=

+ '[' -n '' ']'

+ return 0

++ command -v cgroup2_set_limits

+ '[' cgroup2_set_limits = cgroup2_set_limits ']'

+ '[' start = start ']'

+ cgroup2_set_limits

+ local cgroup_path

++ cgroup2_find_path

++ grep -qw cgroup2 /proc/filesystems

++ case "${rc_cgroup_mode:-hybrid}" in

++ printf /sys/fs/cgroup/unified

++ return 0

+ cgroup_path=/sys/fs/cgroup/unified

+ '[' -d /sys/fs/cgroup/unified ']'

+ rc_cgroup_path=/sys/fs/cgroup/unified/dhcpcd

+ local 'OIFS=    

'

+ IFS='

'

+ '[' '!' -d /sys/fs/cgroup/unified/dhcpcd ']'

+ mkdir /sys/fs/cgroup/unified/dhcpcd

+ printf %d 0

+ IFS='    

'

+ read -r key value

+ echo ''

+ '[' -z '' ']'

+ continue

+ IFS='    

'

+ read -r key value

+ IFS='    

'

+ return 0

+ break

+ eval 'printf '\''%s\n'\'' '

+ read _d

++ printf '%s\n'

+ '[' -n '' ']'

+ read _d

+ '[' 0 -ne 0 ']'

+ unset _d

+ read _f

+ eval 'printf '\''%s\n'\'' '

++ printf '%s\n'

+ '[' -n '' ']'

+ read _f

+ '[' 0 -ne 0 ']'

+ unset _f

+ '[' -n '' ']'

+ '[' -n start ']'

+ '[' start = depend ']'

+ for _cmd in describe start stop status ${extra_commands:-$opts} $extra_started_commands $extra_stopped_commands

+ '[' describe = start ']'

+ for _cmd in describe start stop status ${extra_commands:-$opts} $extra_started_commands $extra_stopped_commands

+ '[' start = start ']'

++ command -v start

+ '[' start = start ']'

+ yesno

+ '[' -z '' ']'

+ return 1

+ for _cmd in $extra_stopped_commands

+ '[' cgroup_cleanup = start ']'

+ unset _cmd

+ case $1 in

+ verify_boot

+ '[' '!' -e /run/openrc/softlevel ']'

+ return 0

++ command -v start_pre

+ '[' '' = start_pre ']'

+ start

+ default_start

+ local func=ssd_start

+ case "$supervisor" in

+ ssd_start

+ '[' -z /sbin/dhcpcd ']'

+ local _background=

+ ebegin 'Starting DHCP Client Daemon'

+ local _r

+ command ebegin 'Starting DHCP Client Daemon'

+ ebegin 'Starting DHCP Client Daemon'

 * Starting DHCP Client Daemon ...+ _r=0

+ EINFO_LASTCMD=ebegin

+ export EINFO_LASTCMD

+ return 0

+ yesno ''

+ '[' -z '' ']'

+ return 1

+ yesno ''

+ '[' -z '' ']'

+ return 1

+ eval start-stop-daemon --start --exec /sbin/dhcpcd --pidfile /var/run/dhcpcd.pid -- -q

++ start-stop-daemon --start --exec /sbin/dhcpcd --pidfile /var/run/dhcpcd.pid -- -q

+ eend 0 'Failed to start DHCP Client Daemon'

+ local _r

+ command eend 0 'Failed to start DHCP Client Daemon'

+ eend 0 'Failed to start DHCP Client Daemon'

 [ ok ]

+ _r=0

+ EINFO_LASTCMD=eend

+ export EINFO_LASTCMD

+ return 0

+ service_set_value command /sbin/dhcpcd

+ '[' -n '' ']'

+ '[' -n /var/run/dhcpcd.pid ']'

+ service_set_value pidfile /var/run/dhcpcd.pid

+ '[' -n '' ']'

+ return 0

++ command -v start_post

+ '[' '' = start_post ']'

++ command -v cgroup_cleanup

+ '[' cgroup_cleanup = cgroup_cleanup ']'

+ '[' start = stop ']'

++ command -v cgroup2_remove

+ '[' cgroup2_remove = cgroup2_remove ']'

+ '[' start = stop ']'

+ '[' -z /sbin/dhcpcd ']'

+ shift

+ continue 2

+ '[' -n '' ']'

+ exit 0

# /etc/init.d/dhcpcd status

 * status: started

```

I am not sure i can get anything useful out of it except that it reports 'Failed to start DHCP Client Daemon' but the service nonetheless starts... Perhaps someone better versed with the workings of openrc can understand more?

----------

## khayyam

orionbelt ...

I think I understand what's going on here. Firstly, why are you starting the dhcpcd service? If you do this then anything in /etc/conf.d/net isn't applicable/applied. I think this is the source of your problem, you have dhcpcd set to start in the runlevel (or it's started to 'provide net'), when it should be started by net.enp2s0. This would explain why 'dns_options' don't show up in resolv.conf, because dhcpcd is never informed that it should do so.

If this is the case then the following should resolve the issue (please test):

```
rc_dhcpcd_provide="!net"
```

```
# rc-update del dhcpcd default

# rc-update add net.enp2s0 default
```

HTH & best ... khay

----------

## orionbelt

khayyam,

Thanks again for your efforts and persistence!   :Confused: 

I was starting dhcpcd only during these trial runs to address this bug, because doing so is less disruptive to my system than restarting net. I have not set dhcpcd to start in the runlevel. Only net.enp2s0 is started:

```
# rc-status 

Runlevel: default

 dbus                                                              [  started  ]

 syslog-ng                                                         [  started  ]

 consolekit                                                        [  started  ]

 net.enp2s0                                                        [  started  ]

 upsdrv                                                            [  started  ]

 upsd                                                              [  started  ]

 sshd                                                              [  started  ]

 chronyd                                                           [  started  ]

 gpm                                                               [  started  ]

 privoxy                                                           [  started  ]

 upsmon                                                            [  started  ]

 vixie-cron                                                        [  started  ]

 local                                                             [  started  ]

Dynamic Runlevel: hotplugged

Dynamic Runlevel: needed/wanted

 lvmetad                                                           [  started  ]

 modules-load                                                      [  started  ]

Dynamic Runlevel: manual

```

But yeah, i was not aware of what you said, so i retried all the stuff the we tried earlier by starting /etc/conf.d/net.enp2s0 this time, but unfortunately the problem persists...

Here is the debug [EDIT: the verbose] output from starting /etc/conf.d/net.enp2s0:

```
# /etc/init.d/net.enp2s0 -v start

 * Bringing up interface enp2s0

 *   Skipping module adsl due to missing program: /usr/sbin/adsl-start /usr/sbin/pppoe-start

 *   Skipping module br2684ctl due to missing program: br2684ctl

 *   Skipping module clip due to missing program: /usr/sbin/atmsigd

 *   Skipping module ethtool due to missing program: ethtool

 *   Skipping module netplugd due to missing program: /sbin/netplugd

 *   Skipping module ifplugd due to missing program: /usr/sbin/ifplugd

 *   Skipping module ipppd due to missing program: /usr/sbin/ipppd

 *   Skipping module firewalld due to missing program: firewall-cmd

 *   Skipping module pppd due to missing program: /usr/sbin/pppd

 *   Skipping module dhclient due to missing program: /sbin/dhclient

 *   Skipping module pump due to missing program: /sbin/pump

 *   Loaded modules: apipa arping bonding l2tp tuntap bridge ccwgroup dummy hsr macvlan macchanger macnet wpa_supplicant ssidnet iproute2 system vlan dhcpcd ip6rd ip6to4

 *   ip link set dev enp2s0 up

 *   Configuring enp2s0 for MAC address x:x:x:x:x:x ... [ ok ]

 *   dhcp ...

 *     Running dhcpcd ...DUID x:x:x:x:x:x:x:x:x:x:x:x:x:x

enp2s0: IAID x:x:x:x

enp2s0: adding address x::x:x:x:x

enp2s0: rebinding lease of 172.x.x.x

enp2s0: probing address 172.x.x.x/24

enp2s0: soliciting an IPv6 router

enp2s0: leased 172.x.x.x for 43200 seconds

enp2s0: adding route to 172.x.x.0/24

enp2s0: adding default route via 172.x.x.x

forked to background, child pid 10512

 [ ok ]

 *     received address 172.x.x.x/24

 [ ok ]

 *   ip -4 route flush table cache dev enp2s0

 *   ip -6 route flush table cache dev enp2s0

```

For the record, this is my /etc/conf.d/net at this point:

```
# egrep -v '^#' /etc/conf.d/net

modules_enp2s0="dhcpcd"

config_enp2s0="dhcp"

dns_options_enp2s0="rotate single-request-reopen"

```

----------

## khayyam

orionbelt ...

can you try adding the following to conf.d/net

```
dhcp_enp2s0="nodns"

dns_servers_enp2s0="1.1.1.1"
```

... does 'options' now show in resolv.conf?

best ... khay

----------

## orionbelt

I was just trying to sort out the *debug* output of "/etc/init.d/net.enp2s0 start" which is too long to post here, and it looks like dns_options *is* being treated, so i was thinking of putting it up on pastebin to share it here, but it looks like we made some progress from your side:

 *khayyam wrote:*   

> can you try adding the following to conf.d/net
> 
> ```
> dhcp_enp2s0="nodns"
> 
> ...

 

Yes, 'options' now does show in resolv.conf, yay!

What now?  :Smile: 

----------

## khayyam

 *orionbelt wrote:*   

> Yes, 'options' now does show in resolv.conf, yay! What now? :)

 

orionbelt ... ok, this suggests that options are only applied when no dns request is made, I assume because it's the dhcp server task it is to provide such things. That places you in the situation of either configuring dhcpd to do that (assuming the router supports this) or hardcoding dns_servers.

edit: actually, there is a third option: use resolv.conf.tail ... as it seems to provide what you're looking for without any configuration.

I should note that the reason I didn't catch this earlier is that I run a local dns cache, and so have dhcp="nodns", and dns_server="127.0.0.1" ... along with dns_options.

best ... khay

----------

## orionbelt

 *khayyam wrote:*   

> orionbelt ... ok, this suggests that options are only applied when no dns request is made, I assume because it's the dhcp server task it is to provide such things.

  Do you think this is something that should be brought to the attention of any developers or is it indisputable that it is a dhcp server's task alone? I would think that at least a warning should be added in /usr/share/doc/netifrc-*/net.example.bz2 for this and any other option that is ignored when a dns request is made. Is there any sense in introducing an option to not ignore the dns_option if so desired? Or are resolv.conf.head and resolv.conf.tail meant to do just that when a dns request is made? Note that there is an old bug report about this here.

 *khayyam wrote:*   

> That places you in the situation of either configuring dhcpd to do that (assuming the router supports this) or hardcoding dns_servers.

  I am not sure either option is good for me. The dhcp server is run by my employer's IT department, and it's in fact shortcomings in their setup that my dns_options are trying to solve... And i would probably rather not hardcode dns servers and take over the maintenance that this entails since i have the resolv.conf.tail option that works for me.

 *khayyam wrote:*   

> edit: actually, there is a third option: use resolv.conf.tail ... as it seems to provide what you're looking for without any configuration.

 Yes, i mentioned it in my second thread posting here.

Thanks a lot for all your help in figuring this out, khayyam!

----------

## khayyam

 *khayyam wrote:*   

> orionbelt ... ok, this suggests that options are only applied when no dns request is made, I assume because it's the dhcp server task it is to provide such things.

 

 *orionbelt wrote:*   

> Do you think this is something that should be brought to the attention of any developers or is it indisputable that it is a dhcp server's task alone? I would think that at least a warning should be added in /usr/share/doc/netifrc-*/net.example.bz2 for this and any other option that is ignored when a dns request is made. Is there any sense in introducing an option to not ignore the dns_option if so desired? Or are resolv.conf.head and resolv.conf.tail meant to do just that when a dns request is made? Note that there is an old bug report about this here.

 

orionbelt ... net.example doesn't say explictly that dns_options are dependent on dns_server, but it is in the same section, and so we can assume their relatedness. I expect developers to know this is how it functions, and I'm fairly certain that if we looked at the RFC for dhcp we'd find that when requesting dns it can not only provide the address, but any options required (domain, options, etc) ... and so that points to it being correct in ignoring dns_options when dns_server isn't defined.

 *khayyam wrote:*   

> That places you in the situation of either configuring dhcpd to do that (assuming the router supports this) or hardcoding dns_servers.

 

 *orionbelt wrote:*   

> I am not sure either option is good for me. The dhcp server is run by my employer's IT department, and it's in fact shortcomings in their setup that my dns_options are trying to solve...

 

I see, but those "shortcomings" should effect every client, and so there is a case for them doing something to remedy the problem.

 *orionbelt wrote:*   

> [...] i would probably rather not hardcode dns servers and take over the maintenance that this entails since i have the resolv.conf.tail option that works for me.

 

Sure, but if you hardcode dns, then you can avoid the issue entirely, ie, you can setup a local cache and/or use non-problematic nameservers. 

 *khayyam wrote:*   

> edit: actually, there is a third option: use resolv.conf.tail ... as it seems to provide what you're looking for without any configuration.

 

 *orionbelt wrote:*   

> Yes, i mentioned it in my second thread posting here.

 

I remember, hence the "as it seems".

 *orionbelt wrote:*   

> Thanks a lot for all your help in figuring this out, khayyam!

 

You're welcome & best ... khay

----------

## orionbelt

 *khayyam wrote:*   

>  *khayyam wrote:*   That places you in the situation of either configuring dhcpd to do that (assuming the router supports this) or hardcoding dns_servers. 
> 
>  *orionbelt wrote:*   I am not sure either option is good for me. The dhcp server is run by my employer's IT department, and it's in fact shortcomings in their setup that my dns_options are trying to solve... 
> 
> I see, but those "shortcomings" should effect every client, and so there is a case for them doing something to remedy the problem.

 Yes, of course, but you know how bureaucracies often work...  :Confused: 

 *khayyam wrote:*   

>  *orionbelt wrote:*   [...] i would probably rather not hardcode dns servers and take over the maintenance that this entails since i have the resolv.conf.tail option that works for me. 
> 
> Sure, but if you hardcode dns, then you can avoid the issue entirely, ie, you can setup a local cache and/or use non-problematic nameservers. 

 I'll keep in mind this option, though resolv.conf.tail solves my problem for now.

By the way, i mentioned near the beginning of this thread that the udhcpc client that i was using before, besides not handling dns_options, seems to also ignore resolv.conf.{head,tail}. Is this an issue to report or is udhcpc a minimal thing that's not supposed to undertake any other action beyond the necessary to establish a dhcp connection?

----------

## khayyam

 *orionbelt wrote:*   

> By the way, i mentioned near the beginning of this thread that the udhcpc client that i was using before, besides not handling dns_options, seems to also ignore resolv.conf.{head,tail}. Is this an issue to report or is udhcpc a minimal thing that's not supposed to undertake any other action beyond the necessary to establish a dhcp connection?

 

orionbelt ... udhcpc is from busybox, so, yes, it's a minimal client ... see the output of 'busybox udhcpc --help'. If you wanted you might be able to use it in conjuction with net-dns/openresolv.

best ... khay

----------

