[Dnsmasq-discuss] DNSSEC passtrough

[Simon Kelley]

Dnsmasq does pass on the do-bit, and return DNSSEC RRs, irrespective of
of having DNSSEC validation compiled in or enabled.

The thing to understand here is that the cache does not store all the
DNSSEC RRs, and dnsmasq doesn't have the (very complex) logic required
to determine the set of DNSSEC RRs required in an answer. Therefore if
the client wants the DNSSEC RRs, the query can not be answered from the
cache. When DNSSEC validation is enabled, any query with the do-bit set
is never answered from the cache, unless the domain is known not to be
signed: the query is always forwarded. This ensures that the DNSEC RRs
are included.

The same thing should be true when DNSSEC validation is not enabled, but
there's a bug in the logic.

line 1666 of src/rfc1035.c looks like this

 if ((crecp->flags & (F_HOSTS | F_DHCP | F_CONFIG)) || !do_bit ||
!(crecp->flags & F_DNSSECOK))

{ ...answer from cache ... }

So local stuff (hosts, DHCP, ) get answered. If the do_bit is not set
then the query is answered, and if the domain is known not to be signed,
the query is answered.

Unfortunately, if DNSSEC validation is not turned on then the
F_DNSSECOK bit is not valid, and it's always zero, so the question
always gets answered from the cache, even when the do-bit is set.

This code should look like that at line 1468, dealing with PTR queries

		  if ((crecp->flags & (F_HOSTS | F_DHCP | F_CONFIG)) ||
		      !do_bit ||
		      (option_bool(OPT_DNSSEC_VALID) && !(crecp->flags & F_DNSSECOK)))

where the F_DNSSECOK bit is only used when validation is enabled.

I think fixing that should make it work the way Petr wants, and I've
pushed the fix as


http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=a997ca0da044719a0ce8a232d14da8b30022592b


Cheers,

Simon.



On 29/06/18 12:18, Petr Menšík wrote:
> Hi Simon and others!
> 
> I am thinking about dnssec support of dnsmasq. Is it possible to enable
> dnssec support, but disable dnssec validation at the same time? Bind for
> example have options dnssec-enable and dnssec-validation. There is
> option proxy-dnssec, but I think it only copies AD flag in replies. The
> flag itself is worthless I think.
> 
> I have one issue with dnsmasq in RHEL. We support special FIPS 140-2
> mode with certified crypto libraries. gnutls is certified but nettle
> alone is not. Current versions in RHEL have disabled DNSSEC support. In
> Fedora it is enabled. Using gnutls for all crypto operations would make
> it trusted also.
> 
> Thing is, we would recommend using certified DNSSEC resolver behind
> dnsmasq. Problem is that without dnssec support, any server using
> dnsmasq as caching proxy is not able to validate a single thing. This is
> often case of libvirt.
> 
> Libvirt uses dnsmasq for DNS and DHCP. Any virtual machine under it is
> configured dynamically. But it is impossible to use validating resolver
> in such machine, like unbound. We use it together with dnssec-trigger to
> automatically configure from DHCP. Just try dig +dnssec in any libvirt
> machine. No signatures are included. Secondary problem is that libvirt
> has currently no was to enable dnssec in its configuration. But that is
> not to solve here.
> 
> Is there reason why validation and passing do bit and including
> signatures in replies is bundled together? I think dnssec support should
> be enabled by default today. But because dnssec validation can
> introduce, require cryptography support and configuration of trusted
> anchors, it is not so wise to enable it by default.
> 
> Would be patch splitting support for DNSSEC queries and separate
> validation welcome? What do you think about turning dnssec queries
> support on by default, so dig +dnssec would pass signatures without
> additional configuration?
>