[Dnssec-trigger] Non-functional dnsmasq bugs detection

[Petr Menšík]

Hi Paul,

yes, I am confident it wasn't caused by systemd-resolved. I am running
Fedora 32 on my laptop and resolved only in container just to report new
bugs to it. They share some design patterns and also similar bugs.

Unfortunately, dnsmasq bug is not catched by dnssec-trigger.
systemd-resolved is consistent in refusing to pass any DNSSEC records to
clients, it would never be chosen by dnssec-trigger as forwarder
(fortunately). In your report, only AD flag changes, because that is the
only thing systemd-resolved can pass to client.

dnsmasq (<=2.79) would pass RRSIG, when it is not yet in cache. When it
is in cache (without DO bit), it responds without DNSSEC signatures.
That is the reason I would like to use NSEC3 probe for it (it would be
likely cached shorter time). And it may succeed first time, so it needs
two packets for the same name.

Fedora and RHEL8 dnsmasq has this bug fixed already, it were fixed in
2.80 [1].

My current workaround were to turn off forwarding by "unbound-control
forward off" command. I am running unbound 1.12 and
dnssec-trigger-0.17-1.fc32.x86_64 on my machine.

On 10/14/20 2:20 AM, Paul Wouters wrote:
> Are you sure this wasn’t caused by systemd-resolved ? I reported this exact bug there last week. Is this on fedora 33? If so, you cannot just check and rewrite /etc/resolv.conf, you also need to rewrite or symlink the version somewhere in /run/systemd which is used by glibc / getaddrinfo() 
> 
> Paul
> 
> Sent from my iPhone
> 
>> On Oct 13, 2020, at 18:42, Petr Menšík via dnssec-trigger <dnssec-trigger at lists.nlnetlabs.nl> wrote:
>>
>> Hello DNSSEC users,
>>
>> I maintain dnsmasq in Fedora, so I know about some of its bugs.
>> Today, I found issues on my provider connection. It uses some Ubiquity
>> device running dnsmasq inside. One device is dnsmasq-2.78-23-g9e09429,
>> second dnsmasq-2.79-1-2-geff17ee.
>>
>> Both detect support for DNSSEC on the first try, but then randomly fail
>> here and there to validate some sites during usage.
>>
>> I have found it has broken cache. When first query is made with
>> +nodnssec, second with +dnssec would get cached reply for the same name,
>> but without dnssec records. Unfortunately, it does not work for NULL
>> queries used now for nsec3.
>>
>> cache 10.129.0.26: OK
>>
>> $ HOST=_probe.cz && T=null && R=10.129.0.26 && dig -t $T $HOST @$R &&
>> dig +dnssec -t $T $HOST @$R
>> This command delivers always RRSIG, so resolver is detected DNSSEC
>> compatible.
>>
>> $ HOST=_probe.cz && T=A && R=10.129.0.26 && dig -t $T $HOST @$R && dig
>> +dnssec -t $T $HOST @$R
>> This command however never gets RRSIG in second query on that broken device.
>>
>> Because dnsmasq is quite common on cheap hardware at home, I think it
>> would be worth to detect its bugs and workaround.
>>
>> I would propose doubling NSEC3 test, first without DO bit in request,
>> then the second with the same name and type with DO bit set. And change
>> PROBE_NSEC3_QTYPE to A or AAAA record.
>>
>> What would you think about such change? I would prepare pull request,
>> once I find enough time. Was there specific reason to use NULL for NSEC3
>> probes?
>>
1.
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=a997ca0da044719a0ce8a232d14da8b30022592b
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/dnssec-trigger/attachments/20201014/96e77f58/attachment-0001.bin>