resolvconf(8): misleading description of dns-* options

Given that actually supporting the "options" resolv.conf option isn't all that easy (it would require having the update.d/libc script combine all the "options" lines from all interfaces, and somehow dealing with any duplicate options found, etc.), I'm guessing that the best resolution here is to edit resolvconf(8) so that it just lists explicitly the dns-* options that are supported in the interfaces file (and only refer to resolv.conf(5) as a source of additional details about how the resolver library handles each of those specific options).

(Related to the discussion in LP: #990660, this revised "ifup" description could also include some sort of mention that the "dns-domain" and "dns-search" options are merged together by the update.d/libc processing.)

Thanks for reporting this. Yes, the manpage should be changed so that it explicitly lists only "nameservers", "search" and "sortlist". (The "domain" option is deprecated in favor of "search". The "options" option belongs in /etc/resolvconf/resolv.conf.d/base.)

I will make this change to the Debian package, version 1.66. I will post the patch here in case the Ubuntu maintainers want to include the fix before 1.66 gets merged.

Update: Nathan and I are editing resolvconf(8).

Nathan and I have come up with an improved version of the man page. I attach it here in case the Ubuntu maintainers want to include it without having to wait for the new Debian package to appear. The attached file is the man page for the Debian package, so it still needs to be patched for Ubuntu, e.g., to replace references to "/etc/resolvconf/run/resolv.conf" to "/run/resolvconf/resolv.conf".

The attachment "new manpage as diff from debian 1.65" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

The new man page has been included in Debian resolvconf 1.66 which was released today.

Ubuntu resolvconf maintainers: Please merge resolvconf 1.66 to quantal!

> Please merge resolvconf 1.66

Make that 1.67. :)

This bug was fixed in the package resolvconf - 1.67ubuntu1

---------------
resolvconf (1.67ubuntu1) quantal; urgency=low

  * Merge from Debian. Remaining changes:
    (LP: #994575, LP: #999337, LP: #1012355)
    - Make /etc/resolv.conf a relative symlink so that it works when
      setting up chroots.
    - Instead of throwing an error that aborts the upgrade when
      /etc/resolv.conf is immutable, pop a debconf error message to let the
      user know what's happening, then clear the immutable flag and continue
      with the installation. LP: #989585.
    - debian/config, debian/templates, debian/postinst: if we don't know that
      /etc/resolv.conf was being dynamically managed before install (in at
      least some cases), link the original contents of /etc/resolv.conf to
      /etc/resolvconf/resolv.conf.d/tail so that any statically configured
      nameservers aren't lost. LP: #923685.
    - Use an upstart job instead of sysvinit script.
    - Pre-Depend on the /run-providing version of initscripts instead of
      depending, so that the preinst does the right thing when creating
      /run/resolvconf/interfaces instead of getting clobbered later by a bind
      mount on initscripts upgrade. LP: #922491.
    - Completely drop the standard_run_subdirs_created helper function from
      debian/postinst, since it serves no purpose here.
    - postinst: Set resolvconf/linkify-resolvconf to false after initial
      conversion, ensuring upgrades won't convert /etc/resolv.conf to
      a symlink if the user manually converted it back to plain text.
      (LP: #922677)
    - Move the #DEBHELPER# token in debian/postinst to after the resolv.conf
      symlink is set, so the init script can actually start (since it expects
      /etc/resolv.conf to be a symlink).
    - Eliminate all references to /etc/resolvconf/run. This should all be done
      directly in /run, there is no reason to support making any of this
      configurable with a symlink since we already have a versioned dependency
      on the version of initscripts that introduces the /run transition.
    - Also remove debian/triggers to avoid needlessly calling resolvconf's
      postinst. (LP: #931335)
 -- Stephane Graber <email address hidden> Fri, 22 Jun 2012 17:29:50 -0400

I understand a fix has been released containing a more accurate manpage which is great, but I'm wondering if there are any plans to update the libc script to actually support dns-options at some point. I'd like to avoid my typical solution of "breaking" resolvconf by setting /etc/resolv.conf immutable if at all possible.

Thanks.

@Anthony:

A "dns-options" option in /e/n/i is indeed not currently supported. Do you need this?

The current practice is to put an "options" line in /etc/resolvconf/resolv.conf.d/base.

@Thomas: Thanks, yes I actually discovered that after finding this bug. The resolv.conf.d/base solution is working just fine for me.