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

[Simon Kelley]

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
>