[Dnsmasq-discuss] NXDOMAIN is sent instead of NODATA when querying for non-existent AAAA records

[Andrew Miskell]

> On Aug 5, 2021, at 2:45 PM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> 
> 
> 
> On 05/08/2021 19:24, Wojtek Swiatek wrote:
>> 
>> 
>> Le jeu. 5 août 2021 à 19:41, Simon Kelley <simon at thekelleys.org.uk
>> <mailto:simon at thekelleys.org.uk>> a écrit :
>> 
>>    OK. The problem is here: using local addresses only for domain
>>    swtk.info <http://swtk.info>
>> 
>>    That's an easy spot because I just fixed this particular combination.
>> 
>>    I guess you have something like
>> 
>>    local=/swtk.info/ <http://swtk.info/>
>> 
>>    and dnsmasq is using this to return NXDOMAIN without checking that it
>>    has more specific data for the query in other  types.
>> 
>>    As a workaround, removing that configuration should make things work, at
>>    the expense of extra trips to the upstream servers.
>> 
>> 
>> Thank you. The problem is that swtk.info <http://swtk.info> is also
>> declared on .info so (if I understand local= correctly), it would
>> attempt to resolve mqtt.swtk.info <http://mqtt.swtk.info> on Internet.
>> Which would fail.
> 
> That's fine. mqtt.swtk.info resolves to NXDOMAIN (at least it does here)
> and when dnsmasq gets that answer back, it will change it into NODATA.
> because it has an A record for mqtt.swtk.info derived from a DHCP
> record. That should be functional in 2.78.
>> 
>> The local=/swtk.info/ <http://swtk.info/> and
>> address=/swtk.info/192.168.10.2 <http://swtk.info/192.168.10.2> combo
>> fixes this.
>>  
>> 
>> 
>>    This should already be fixed in the development code: if it's possible
>>    for you to run
>>    https://thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.86test6.tar.gz
>>    <https://thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.86test6.tar.gz>
>>    that should fix things, and doing so would be a useful test for me.
>> 
>> 
>> Unfortunately, since the dnsmasq binary I use is part of a router, I
>> have no way to use another version. Which, as I realize now, will be a
>> major problem anyway since the issue is not a matter of configuration.
>>  
> 
> This is a major defect in the state of the world. Routers should be
> updated as often and as easily as desktops and laptops, but frequently
> aren't and can't be.
> 
> Cheers,
> 
> Simon.
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

UI updates the EdgeRouter firmware quite often, but on the EdgeMAX line of devices they tend to be more conservative about updating the underlying components (due to being billed as carrier grade devices). e.g. they released v2.0.9-hotfix.2 in June and back ported the fixes for DNSMasq for CVE-2021-3448.

UI is much more aggressive on the UniFi (consumer) side of the house, they’ve upgraded dnsmasq in their firmware much more often and usually to the latest version available (latest firmware on the UDM platform run 2.85).

Just depends on their update strategy for the underlying components. Same with operating systems like RHEL, they tend to favor back porting security fixes to a specific version instead of upgrading to a whole new release of the component.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210805/a7c6acdc/attachment.htm>