Your message dated Fri, 10 Feb 2017 15:46:34 -0700 with message-id <[email protected]> and subject line Re: Bug#854663: resolvconf ignores dns entries has caused the Debian Bug report #854663, regarding resolvconf ignores dns entries to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 854663: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854663 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: resolvconf Version: 1.79 Severity: important Dear Maintainer, either I misunderstood resolvconf or I resolvconf does not recognize dns entries. In /etc/network/intefaces I have -------- snip ----- auto lo eth0 wlan0 iface lo inet loopback address 127.0.0.1 netmask 255.0.0.0 #### at home ###### iface eth0 inet static address 192.168.178.17 netmask 255.255.255.0 broadcast 192.168.178.255 gateway 192.168.178.1 dns-nameserver 208.67.222.222 dns-nameserver 208.67.220.220 iface wlan0 inet static address 192.168.1.107 netmask 255.255.255.0 broadcast 192.168.1.255 gateway 192.168.1.1 wpa-driver wext wpa-scan-ap 1 wpa-key-mgt WPA-PSK wpa-ssid oberg-freifunk.net wpa-psk trustno1.! dns-nameserver 208.67.222.222 dns-nameserver 208.67.220.220 ----------- snap -------- But /etc/resolv.conf is showing me this: ------snip ----- # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 -------- snap -------- IMO the entries for 208.67.222.222 and 208.67.220.220 should also appear in resolv.conf. However, they appear in dhcp.conf. Is this a bug or is this correct this way? And is it recommended to use resolvconf in changing environments or should resolvconf be uninstalled? Thanks for any help. Best regards Hans -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages resolvconf depends on: ii debconf [debconf-2.0] 1.5.60 ii ifupdown 0.8.19 ii init-system-helpers 1.47 ii lsb-base 9.20161125 resolvconf recommends no packages. resolvconf suggests no packages. -- debconf information: resolvconf/downup-interfaces: resolvconf/link-tail-to-original: false resolvconf/linkify-resolvconf: true resolvconf/reboot-recommended-after-removal:
--- End Message ---
--- Begin Message ---Hello Hans, Hans wrote: > thank you for the fast and very informative response. Indeed, I have bind9 > installed and everything you wrote, is exactly like it is on my system. Oh good. :-) > I am sure, I misunderstood resolvconf, and your description explains, why > domain resolution is still working, although the missing entry in resolvconf. > > Resolvconf is running for may years on my systems, but as I got some problems > in the last two weeks to resolve my mailservers, I thought it would be a > problem with resolvconf. However, might be another problem. I have had many cases recently where things in general, other things, have been breaking that have been working fine. Gremlins! > Of course, I read all the manuals and documentations, but not all was clear > to > me (i.e. the bind9 thingi). So thank you for enlightening me. There are a zillion ways to configure things. Everyone has different needs. This makes it hard to set up automatically. And harder to document. But it sounds like you are saying server machines. Can I assume a server machine with a static IP address on the network? You said running bind9. In such cases I think you can mostly ignore the dns-nameserver directives, regardless of what you might have had there, and simply rely upon the bind9 caching nameserver running locally to resolve everything. That will work fine. The local running named will be a recursive nameserver by default and will look up names globaly okay. It is not necessary for named to "forward" lookups to the listed dns-nameservers in order to get a DNS answer. This is one valid configuration. In which case the dns-nameserver lines in /etc/network/interfaces are not doing anything and could be removed. In server environments like that resolvconf is not as critical. It is in mobile devices such as laptops connecting using dhcp where resolvconf is really the critically useful utility. With bind9 running on a server you can use the really basic default and have a good working environment without a lot of configuration. In yet other environments, a very specific local nameserver might be needed in order to resolve private names. I need to do this in VPN situations. I need to resolve private names over the VPN. In that case I need to configure bind9's named and resolvconf to use those specific nameservers. That doesn't sound like your case. But I will mention it here anyway. In that case the named.conf needs to be modified to include the dynamically generated file from resolvconf and resolvconf needs the resolvconf-update-bind script to be installed and configured in place. However see http://bugs.debian.org/483098 for the long running conflict on this item. > I think, this bug can safely be closed now. And please apologize for the > noise. Okay. I am closing the bug ticket with this mail message. If you have any additional follow-up please go ahead and follow-up to the bug ticket address normally. It will all get logged normally. Bob
--- End Message ---
