also sprach Robert Edmonds <edmo...@debian.org> [2010.02.01.1207 +1300]: > can you please explain exactly what this does and how it relates to > #562031?
My script supplements #562031, which talks only about how to teach the system to ask localhost (or whereever unbound listens). The way I do this is by adding dns-nameservers ::1 to the 'lo' stanza in /etc/network/interfaces. My script then simply makes sure that unbound knows what the DNS IPs obtained by e.g. DHCP are, so that it can forward queries recursively, rather than iteratively resolving them. > > +# Script to inform unbound about upstream resolvers. > > by "upstream resolver" do you mean a recursive nameserver? Yes. > > ++# Resolvconf integration ++# If you have the resolvconf > > package installed, you can uncomment the ++# following to let > > unbound forward queries to the DNS resolvers discovered by ++# > > resolvconf (e.g. from DHCP or static entries in > > /etc/network/interfaces). ++# include: > > "/var/cache/unbound/resolvconf_resolvers.conf" > > i'm confused. unbound is already a full service resolver. > doesn't this configure unbound to just act like a stub resolver by > forwarding all its queries to another full service resolver? why > not just set that resolver address in /etc/resolv.conf? I want to use unbound locally to be able to use e.g. local-data, and to stub some zones. Obviously I don't need to tell it about the resolvers because it can do it itself (using the root zones), but that's not really how DNS was designed: it should ask the resolvers rather than the root servers. > is there some use case that this solves, e.g. something to do with > DNSSEC validation (since there is no DNSSEC support in the glibc stub > resolver) or maybe operation on hostile networks that block / intercept > port 53 traffic? No, this really just does the following: Normally, you just put the ISP NSs from DHCP into /etc/resolv.conf, which will then cause the following (libc is just one possible resolver library): localhost → libc → ISP → … → root-servers If instead you plug in unbound like suggested in #562031, you get localhost → libc → unbound → root-servers My patch allows the admin to turn that into localhost → libc → unbound → ISP → … → root-servers by uncommenting the include directive. > > diff --git a/debian/rules b/debian/rules > > index ad1025f..f36201c 100755 > > --- a/debian/rules > > +++ b/debian/rules > > @@ -26,6 +26,8 @@ install: build > > dh_installinit --error-handler=true --restart-after-upgrade > > dh install --after dh_installinit > > install -m 0644 doc/example.conf debian/unbound/etc/unbound/unbound.conf > > + install -m 0755 contrib/resolvconf-update-script.sh \ > > + debian/unbount/etc/resolvconf/update.d/unbound > > s/unbount/unbound/ Yikes. This happened in the mailer, because my patch is correct (and tested). Sorry. -- .''`. martin f. krafft <madd...@d.o> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems eleventh law of acoustics: in a minimum-phase system there is an inextricable link between frequency response, phase response and transient response, as they are all merely transforms of one another. this combined with minimalization of open-loop errors in output amplifiers and correct compensation for non-linear passive crossover network loading can lead to a significant decrease in system resolution lost. however, of course, this all means jack when you listen to pink floyd.
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
