[Dnsmasq-discuss] [PATCH] return responses without qname

Petr Menšík pemensik at redhat.com
Wed Jul 22 22:59:54 BST 2020


Hi Simon,

I admit it can be dangerous. It might instead just mark waiting query as
"received invalid response", so without any better response received, it
should syntetize SERVFAIL reply after some timeout. Or it might just
postpone that response to timeout. If valid response arrived sooner, it
would be delivered instead, no qname reply dropped (and maybe logged).

I am not sure response without qname in body violates any RFC. It is not
usual and it was fixed in unbound 1.7.0. However, there should be some
response to a query. Currently it just timeouts reliably, which is not
valid response. Any response would be fine, since forwarder provided
negative response.

Cheers,
Petr

On 7/22/20 1:19 PM, Simon Kelley wrote:
> I'm not sure that this is the correct solution to the problem.
> 
> I'd argue that this is an unbound issue: A reply to a DNS query that
> doesn't echo the qname surely cannot be considered a valid reply?
> I'm not sure why unbound would do that.
> 
> The query-id is only 16 bits, so can't be considered enough to uniquely
> identify queries. Also, this provides a very easy DoS attack vector:
> just firehose qname-less replies at the dnsmasq instance with random ids
> and you're more-or-less guaranteed to fail a reasonable proportion of
> DNS queries in progress.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> 
> 
> On 20/07/2020 15:04, Petr Menšík wrote:
>> Hi,
>>
>> found out even latest dnsmasq is not able to forward reply, when it does
>> not contain qname in response body. I discovered it when testing
>> RHEL/CentOS 7, which has Unbound 1.6.6. If you send non-recursive query
>> to it, it responds with REFUSED. But no query name copied in response.
>>
>> dig itself can handle it well. But dnsmasq does not forward such query back.
>>
>> Steps to reproduce:
>> start unbound < 1.7.0, listening on localhost
>> start dnsmasq with:
>> bind-interfaces
>> listen-address=127.0.0.2
>>
>> It can be tested with unbound configured on localhost. Then use:
>> dig @127.0.0.2 +norec localhost
>>
>> It would always fail with timeout, because dnsmasq discards the reply. I
>> attached my attempt to fix the issue. It just provides null hash, which
>> is then supported by cache lookup.
>>
>> Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1826691
>> Github link: https://github.com/InfrastructureServices/dnsmasq/pull/6
>>
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB




More information about the Dnsmasq-discuss mailing list