[Dnsmasq-discuss] issues resolving a DNSSEC domain with dnsmasq 2.76 [2.80 as well]

Sun Mar 28 00:03:21 UTC 2021

On 23/03/2021 13:53, Petr Menšík wrote:
> I guess similar rules exist for any serious software distribution, not
> only Linux distributions. Fedora allows rebasing as a security fix, but
> it should prevent any possible regressions. In Fedora it works, because
> it has short life cycle. For long release cycles products like RHEL (or
> CentOS), only security patches are applied. It might sometime just
> change some behaviour on new release and can break existing deployments.
> People don't want that.
> 
> Dnsmasq is small, but feature rich. It is often hard to add something
> and not break something else.
> 
> Anyway, a better regression test suite would help. I admit it might
> catch even my own typos sometime, I will have to work on it more. My
> attempt for at least some testing is at [1]. Pull requests welcome. Have
> also few unit tests [2] under work. Should we include them, shall I send
> a patch for it?
> 
> 1. https://github.com/InfrastructureServices/dnsmasq-tests
> 2. https://github.com/InfrastructureServices/dnsmasq/tree/unittests
> 

I'd love to have a a unit test system as part of the dnsmasq codebase.

Simon.

> On 3/20/21 10:49 PM, Simon Kelley wrote:
>>
>>
>> On 20/03/2021 15:02, Jelle de Jong via Dnsmasq-discuss wrote:
>>> Thank you all for the replies,
>>>
>>> I did some more testing on an up-to-date Debian 10 Buster system with
>>> all the security updates installed and it has the same time out problem.
>>>
>>> If version 2.80 is to old would it be possible to ask the Debian
>>> maintainer to push an update or even a security update as it is DNSSEC.
>>
>> Debian security updates don't usually use newer upstream releases, they
>> work on the principle of minimal changes to existing packages to close
>> the security hole. My life would be easier if they did, since
>> backporting securirt fixes is often hard.
>>
>> The upcoming 2.85 release compiles without problem on a Buster system.
>>
>>
>> Simon.
>>
>>>
>>> # dnsmasq --version
>>> Dnsmasq version 2.80  Copyright (c) 2000-2018 Simon Kelley
>>> Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua
>>> TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile
>>>
>>> # dig goededoelennederland.nl
>>> ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> goededoelennederland.nl
>>> ;; global options: +cmd
>>> ;; connection timed out; no servers could be reached
>>>
>>> Kind regards,
>>>
>>> Jelle de Jong
>>>
>>> On 3/19/21 11:46 PM, Simon Kelley wrote:
>>>> On 19/03/2021 17:08, Petr Menšík wrote:
>>>>> Hmm, I suspect the problem with this name lies in the server TTL setting
>>>>> for the key. DNSKEY has 0, which might not be handled well by older
>>>>> versions.
>>>>>
>>>>> Update:
>>>>> This was fixed by commit 7e194a0 [1] in version 2.82, where it modifies
>>>>> ttl to stay at least 60 seconds in a cache. I guess all previous
>>>>> versions need its backport, if they are validating.
>>>>
>>>>
>>>> As a general rule, if you're validating, use up-to-date releases, the
>>>> almost endless sequence of bug reports pointing out strange signed zones
>>>> which did things I'd not anticipated finally ended around 2.80, but 2.81
>>>> has a major performance fix for DNSSEC and 2.82 fixed a crash bug in the
>>>> 2.81 changes, so that gets you to 2.83 which is the first of three
>>>> releases to get security right, culminating (I hope) in the about-to-be
>>>> released 2.85.
>>>>
>>>> At least if you keep updating, you always have the current root zone
>>>> origin-of-trust :)
>>>>
>>>> Simon.
>>>>
>>>>
>>>>>
>>>>> 1.
>>>>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=7e194a0a7d483932eb3f416b8f26131ade588acc
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Petr
>>>>>
>>>>> On 3/19/21 5:08 PM, Petr Menšík wrote:
>>>>>> Okay, interesting bug. I were able to reproduce it also on RHEL8
>>>>>> version
>>>>>> of 2.79, which is not that old. So I guess I have to find a fix for
>>>>>> that.
>>>>>>
>>>>>> It worked on 2.85rc1, so fix must be something in between those. Or it
>>>>>> depends on nettle version used. RHEL8 uses nettle 3.4.1, my Fedora 32
>>>>>> has nettle 3.5.1.
>>>>>>
>>>>>> It seems I have to find the fix for that as well. Thanks for
>>>>>> reporting it!
>>>>>>
>>>>>> The problem is goededoelennederland.nl DNSKEY reply validation by
>>>>>> dnssec_validate_by_ds returns STAT_NEED_KEY. Which in turn generates
>>>>>> the
>>>>>> same query again, failing again.
>>>>>>
>>>>>> Cheers,
>>>>>> Petr
>>>>>>
>>>>>> On 3/19/21 1:50 PM, Jelle de Jong via Dnsmasq-discuss wrote:
>>>>>>> Hello everybody,
>>>>>>>
>>>>>>> I am having an issue resolving the MX record of a domain using DNSSEC,
>>>>>>> however I can not find anything wrong with this domain on a dnssec
>>>>>>> test
>>>>>>> sites, but dnsmasq goes into a loop until the dig tool times out.
>>>>>>>
>>>>>>> The dnssec test on the goededoelennederland.nl domain:
>>>>>>> https://dnsviz.net/d/goededoelennederland.nl/dnssec/
>>>>>>>
>>>>>>> The dnsmasq loop logs (a few pages full)
>>>>>>> Mar 19 13:37:18 firewall01 dnsmasq[26888]: reply
>>>>>>> goededoelennederland.nl
>>>>>>> is DNSKEY keytag 44143, algo 13
>>>>>>> Mar 19 13:37:18 firewall01 dnsmasq[26888]: dnssec-query[DNSKEY]
>>>>>>> goededoelennederland.nl to 208.67.220.220
>>>>>>> Mar 19 13:37:18 firewall01 dnsmasq[26888]: reply
>>>>>>> goededoelennederland.nl
>>>>>>> is DNSKEY keytag 44143, algo 13
>>>>>>> Mar 19 13:37:18 firewall01 dnsmasq[26888]: dnssec-query[DNSKEY]
>>>>>>> goededoelennederland.nl to 208.67.220.220
>>>>>>>
>>>>>>> The dnsmasq config:
>>>>>>> dnssec
>>>>>>> conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
>>>>>>>
>>>>>>> If I disable dnsmasq option it all works:
>>>>>>>
>>>>>>> # dnsmasq --version
>>>>>>> Dnsmasq version 2.76  Copyright (c) 2000-2016 Simon Kelley
>>>>>>> Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua
>>>>>>> TFTP conntrack ipset auth DNSSEC loop-detect inotify
>>>>>>>
>>>>>>> # dig MX goededoelennederland.nl @localhost
>>>>>>> ; <<>> DiG 9.10.3-P4-Debian <<>> MX goededoelennederland.nl @localhost
>>>>>>> ;; global options: +cmd
>>>>>>> ;; connection timed out; no servers could be reached
>>>>>>>
>>>>>>> # dig MX goededoelennederland.nl @208.67.222.222 | grep -v ";"
>>>>>>> goededoelennederland.nl. 0    IN    MX    0
>>>>>>> goededoelennederland-nl.mail.protection.outlook.com.
>>>>>>>
>>>>>>> I could reproduce this isuses on multipe dnsmasq servers.
>>>>>>>
>>>>>>> Could someone knowledgeable do a a quick dig MX
>>>>>>> goededoelennederland.nl
>>>>>>> and see what goes wrong?
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>> Jelle de Jong
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Dnsmasq-discuss mailing list
>>>>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>>>>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dnsmasq-discuss mailing list
>>>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>>>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Dnsmasq-discuss mailing list
>>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dnsmasq-discuss mailing list
>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>>>
>>>
>>> _______________________________________________
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
> 