On 06/02/2015 06:44 PM, Paul Wouters wrote:
On Tue, 2 Jun 2015, David Howells wrote:
>> Install a local DNS resolver trusted for the DNSSEC validation
>> running on
>> 127.0.0.1:53. This must be the only name server entry in
>> /etc/resolv.conf.
>>
>> The automatic name server entries received via dhcp/vpn/wireless
>> configurations should be stored separately (e.g. this is stored in the
>> NetworkManager internal state), as transitory name servers to be
>> used by the
>> trusted local resolver. In all cases, DNSSEC validation will be done
>> locally.
>
> How does this interact with dnsmasq which also wants to be the only name
> server entry in resolv.conf?
dnsmasq is not the default entry in
/etc/resolv.conf. It can be used
with NM, but unbound can be, too. dnsmasq was integrated with NM sooner,
since it didn't have DNSSEC support, which made a lot of corner cases
and issues basically non-existing.
Unbound it relatively simple and single purpose DNS resolver that was
designed with DNSSEC in mind from the beginning... in comparison to
dnsmasq. dnsmasq is a Swiss knife that is good for simple solutions
hacked together with single component (since it supports DHCPv4/6, TFPT
and also DNS+DNSSEC).
Not well? The problem is dnsmasq is not as feature complete as unbound
(and its dnssec implementation is very new).
I agree, and as a previous maintainer
of dnsmasq, I think unbound is
better option. Although dnsmasq has a simple DBus API, it is mostly for
DHCP. Also unbound has modular design and easy interface
(unbound-control) enabling to reconfigure it dynamically.
I think most people end up running dnsmasq because of KVM/libvirtd ?
I
think those dnsmasq's should be run in "dhcp only" mode and point to
the hosts's unbound.
Right. dnsmasq run by libvirtd uses the default
configuration WRT
resolv.conf. So it uses the servers from resolv.conf for resolution ->
which will be unbound. There are not conflicts between unbound running
as local resolver and dnsmasq instances run by libvirtd.
Tomas