martin f krafft wrote: > 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.
hm, i see.
> > > ++# 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.
ah, so you have some sort of split horizon DNS setup? in the past i've
seen this done with dnscache, dnsmasq, and i believe it's in fact built
into the macosx stub resolver. of course unbound and bind can do it
too.
> 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.
well, no, in fact this is just one possible configuration. see RFC
1035, section 2.2. especially,
Information flow can also be tailored so that a group of hosts act
together to optimize activities. Sometimes this is done to offload less
capable hosts so that they do not have to implement a full resolver.
This can be appropriate for PCs or hosts which want to minimize the
amount of new network code which is required. This scheme can also
allow a group of hosts can share a small number of caches rather than
maintaining a large number of separate caches, on the premise that the
centralized caches will have a higher hit ratio. In either case,
resolvers are replaced with stub resolvers which act as front ends to
resolvers located in a recursive server in one or more name servers
known to perform that service:
(by root servers, i think you meant content servers, btw.)
in principle if everyone switched to the first diagram in 1035 2.2 there
would be global DNS scalability issues, but i don't see any harm in
debian users running unbound in full service mode. they may even prefer
it to avoid censorship and NXDOMAIN rewriting by ISP resolvers which is
unfortunately becoming quite common.
> 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.
well, i am philosophically opposed to the latter configuration. but i
will merge this patch anyway since it seems like useful functionality to
have.
--
Robert Edmonds
edmo...@debian.org
signature.asc
Description: Digital signature
