Re: [Dnsmasq-discuss] DNSSEC passtrough
Thank you for looking into this Simon.
On 06/29/2018 03:47 PM, Simon Kelley wrote:
> Dnsmasq does pass on the do-bit, and return DNSSEC RRs, irrespective of
> of having DNSSEC validation compiled in or enabled.
Sure, this is true. Dnsmasq will pass DO bit from query. I think my
issue is, once address is cached, it will serve it from cache only. That
was fixed by your commit, thanks! It did break as soon as first client
asked without DO bit before, until cache record expired. Which was
almost never true for top level domains.
>
> 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.It would be nice if also DNSSEC were cached. Most dnssec capable
resolvers would probably have its own cache, so it should not be
critical for performance. It is much more important it can work now.
Made new bug on Fedora for it:
https://bugzilla.redhat.com/show_bug.cgi?id=1597309
> 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
>
Yes it fixed it!
>
> Cheers,
>
> Simon.
>
Cheers,
Petr
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com PGP: 65C6C973
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSSEC passtrough
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?
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] DNSSEC passtrough
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? -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
