On 2022-04-19 16:24:57 +0300, Michael Tokarev wrote: > 19.04.2022 16:02, Vincent Lefevre wrote: > > On 2022-04-19 15:15:11 +0300, Michael Tokarev wrote: > > > unbound resolvconf integration (the disabled one) works by setting > > > DNS servers obtained via DHCP to become the forwarders in > > > unbound. As simple as that. I'm not saying about 127.0.0.1 > > > filtering there, it's a different issue. > > > > > > If we (re)enable /etc/resolvconf/update.d/unbound , the dhcp-provided > > > nameservers will be used as the primary nameservers with unbound sitting > > > just as a local cache. Unbound will not use them as fallbacks but as > > > primary forwarders. > > > > The issue is that resolvconf assumes that unbound will use them > > as fallbacks (see below). > > Um. Did you forget to describe this "below" case? I don't see where you > wrote that below.
No, I meant what I wrote about how resolvconf behaves. > > > The only way to do what - I think - you're asking for, is for > > > resolvconf to modify /etc/resolv.conf file to specify one unbound- > > > provided nameserver line (with 127.0.0.1 in there) and *add* the > > > dhcp-provided nameservers there *too*. And you don't want in this > > > case to enable unbound's resolvconf integration. > > > > resolvconf actually does the opposite: instead of leaving the > > /etc/resolv.conf contents as is, it removes every nameserver > > after 127.0.0.1, assuming that they will be handled by the > > local nameserver. > > Yes, I know what it does, and why. It assumes whatever is running > at 127.* is a local caching thing which will do its own forwarding > when needed, and for that forwarding resolvconf gives it the > dhcp-provided nameservers. What I wrote is the only way I know > to achieve what you wanted. > > > Perhaps this is something to see with the resolvconf authors. > > I don't think this is in the scope of resolvconf people, because > the whole purpose of resolvconf is different. I don't know what you mean here. In my case, the purpose of resolvconf is just to restart postfix each time /etc/resolv.conf is modified (typically due to the connection of a laptop to a different network), as recommended at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964762 However, the upcoming postfix package version will contain another method without needing resolvconf: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003152 > > > But this doesn't really work and it is unreliable. Because quite > > > some software will query *all* nameservers listed in resolv.conf > > > at the same time (accepting the first reply), and some software > > > will only query the first one. > > > > This would clearly be a bug, as not conforming with the > > /etc/resolv.conf spec. See the resolv.conf(5) man page: > > I know perfectly well what resolv.conf manage says. And I know > perfectly well that software already uses it in slightly different > ways, for different reasons. Usually you don't have lots of stuff > in there - it is either your upstream nameservers from dhcp, or > something like 8.8.8.8, or 127.0.0.{1,53} which is your local > dns cache. In most cases it is irrelevant in which way or in > which order you query them. There is another use case: by default, have some nameserver that doesn't use the ones provided by DHCP, e.g. 127.0.0.1 or 8.8.8.8, and have the nameservers provided by DHCP as a fallback. The fallback is needed in case UDP packets are filtered, as with captive portals; see example at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003135 and it is important that the query to the default nameserver is done first, because the nameservers provided by DHCP can provide incorrect answers (e.g. preventing users from using servers blacklisted by the government). > I tend to close this bug report, Vincent. This is not the intended > usage of resolvconf, and is not something to fix in unbound, either. > Unbound can either accept whatever resolvconf gives it from dhcp and > use that as its own forwarders (with the the script in $subject > enabled), or it can continue to perform recursive queries as before, > starting with the root nameservers. There's no such thing as a > "fallback" here, at all. Then this should be a resolvconf bug. But the fix on the postfix side (Debian bug 1003152) makes resolvconf no longer needed. So, as long as other Debian packages do not need resolvconf, I no longer care about it. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
