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

[Ed W]

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?

Thanks

Ed W