[Dnsmasq-discuss] State of blocking type=65 requests?

[Simon Kelley]

On 11/03/2023 17:34, Ed W wrote:
> On 07/03/2023 21:50, Simon Kelley wrote:
>>
>> On 06/03/2023 22:36, Ed W wrote:
>>> Hi, can I get a leg up in understanding the options for blocking dns queries for a specific resource
>>> type, specifically type 65 queries
> 
>>> My motivation for needing this is that we operate a firewalling system for a very bandwidth
>>> constrained system (even DNS is extremely expensive) and we operate a 'blocked unless whitelisted'
>>> firewalling system. The type 65 queries are currently inhibiting some of the whitelisting
>>> capability. Whilst we can potentially improve things, the short term solution would be to block
>>> type 65
>>>
>>> I see that there is an option in pi-hole, but I'm looking for an option within dnsmasq, ideally
>>> without maintaining my own out of tree patch
>>>
>>>
>>
>> Just to make clear, as I know you count every every byte of traffic, these filters are on
>> _answers_ not on queries. The query for A or AAAA (or in future an arbitrary type) still gets sent
>> upstream and when the answer comes back, the RRs are stripped out of the answer. It has to be that
>> way because the upstream there may not be an positive answer from upstream, and in that case we
>> need to know is it's a NODATA answer (The RRtype we queried doesn't exist) or an NXDOMAIN answer
>> (the domain we queried doesn't exist.)
> 
> 
> So I've kind of realised that it might be difficult to implement my preferred option to kill the
> upstream query (and save the bytes).
> 
> I created a very simple iptables rule that (probably) blocks AAAA queries by just matching on the
> query type in the packet (motivation is that then I can block only on expensive connections and
> leave cheap connections untouched)
> 
> However, I then hit an issue with the musl resolver. It seems that this got changed last year to
> return both A and AAAA results OR error. So if the AAAA query fails, then it retries a few times and
> then returns an error (rather than partial result with just the A). There is some reference in the
> commit to this being "correct"?
> 
> I'm not sure I know which RFC might dictate this? I'm tempted to patch this to do what I want it to
> do, but first any observations on why this might be a bad idea in the real world (to be clear,
> change of behaviour that failed AAAA request will be ignored and remaining A response will be
> returned on it's own)? My proposal would be to match the A response, so if NX-Fail on A, then that's
> what you get, but otherwise "NO-DATA" for the AAAA. What am I missing?
> 

The problem with doing this in dnsmasq or with iptables is that the A 
and AAAA queries are separate.


If you want to suppress the AAAA query (rather than the answer) you need 
to know is the answer should be NODATA or NXDOMAIN.

If the A query happens first then A query happens first then you have 
that information: an NXDOMAIN answer means the AAAA query can be 
NXDOMAIN too. A NODATA or actual data means that the answer to the AAAA 
query can be NODATA without every sending it upstream.


Of course there's the possibility that nothing is cached for the domain, 
in which case you have to send the query upstream.


The resolver is somewhat different: it just returns IPv4 and IPv6 
answers, if you could hack it to always return an empty set of IPv6 
addresses and never make AAAA DNS queries, you're fixed, as long as 
everything uses the resolver library calls to do DNS. As long.


For dnsmasq, an AAAA query will get an immediate NXDOMAIN if the A query 
already happened and cached the NXDOMAIN response. Otherwise the AAAA 
query gets sent upstream and if any RR are returned, that answer gets 
turned into a NODATA answer by filter-aaaa.

What doesn'y happen, but could, is a search of the cache for A or other 
records. If they exist, an AAAA query with filter-aaaa could get turned 
into a NODATA answer without being sent upstream.

Simon.



> Thanks
> 
> Ed W
> 
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>