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

[Simon Kelley]

On 16/03/2023 16:04, Petr Menšík wrote:
> I do not like attempts to filter out valid queries from clients on the 
> side of dns cache. It should cache the HTTPS type, which it currently 
> does not. That makes those kind of queries much more expensive.

Agree about HTTPS caching.
> 
> I think it should be fixed on the side of clients instead. If they ask 
> for all addresses, just give them when they do exist. If the network is 
> very expensive (can you be more concrete about type of connection?) then 
> find a way to tell clients what it does provide (and what it does not). 
> It does not provide IPv6? Well, then clients should not ask for it 
> without a reason. They also have to be special on such expensive 
> network, haven't they? I expect they have to be tuned somehow to avoid 
> unnecessary network communication anyway.

Ed can answer this.
> 
> What is a good response for AAAA record, which may exist, but we pretend 
> it does not? NODATA or REFUSED? 

NODATA or NXDOMAIN are the only good answers. You can answer NXDOMAIN if 
a query for another RRtype for the same domain returned NXDOMAIN. You 
can also answer NODATA if that query returned an answer or NODATA. If 
you don't have the answer to another query, then you have to send it 
upstream. The current dnsmasq code handles cached NXDOMAIN. This is 
valid, not just if you're filtering the requested rrtype.  I'm tempted 
to add the NODATA check, that's only useful with filtering.

> All similar quirks break DNSSEC 
> deployment. 

Having DNS clients of dnsmasq which do DNSSEC validation is pretty 
hopeless anyway. It will work only if you don't use any the facilities 
in dnsmasq to alter the client's view of the DNS.  No overriding A/AAAA 
records in /etc/hosts or --address. No generating A, AAAA or other 
record types in dnsmasq. The only way it works is just using dnsmasq as 
a pure caching forwarder. That's a valid use case, but lots of people 
use dnsmasq to alter the client's view of the DNS and that's a valid use 
case too and there's no reason to avoid additional features that do it.

> Would you want also EDNS0 extension stripped from forwarded 
> queries? Or at least reset DO bit to 0 always? I would prefer if it 
> could return REFUSED to queries it does not want to forward. Faking 
> empty responses is poor man's choice just to dodge assumptions on 
> multiple sides. But if it does not want to forward something , I think 
> REFUSED would be correct response. It would also solve problem to decide 
> whether to send NOERROR or NXDOMAIN. And would cause no forwarded 
> queries of unwanted types.
> 

The problem with REFUSED is that the behaviour of resolvers to a REFUSED 
answer is not well defined. I bet lots of them will just retry, 
especially when they only have one recursive server configured. That's 
not very useful.


> If it would work the same way as faking empty responses, I would vote 
> for --reject-rrset=https instead of --filter-rrset=https. AAAA would be 
> probably more difficult, because getaddrinfo(AF_UNSPEC) implementations 
> may not handle REFUSED just one one of two queries well. But if browsers 
> doing HTTPS would handle it better, please try that first. I admit I 
> haven't tried. But HTTPS should not have similar legacy problems, it may 
> work better.


I think we have consensus that that filter-a and filter-aaaa should be 
generalised to filer=rrset.

I'd also like to generalise the cache to allow something like 
cache-rrtype=SRV or cache-rrtype=https.



Simon.


> 
> Regards,
> Petr
> 
> On 06. 03. 23 23: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
>>
>> I see there was a patch to implement a "filter-http" option here:
>>
>>      https://github.com/rozahp/dnsmasq
>>
>> It possibly seems like there is a filter-aaaa implemented in dnsmasq 
>> already, so I wonder if there
>> is appetite for the filter-http to also be accepted?
>>
>>
>> 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
>>
>>
>> Have I missed a solution that is possible within vanilla dnsmasq?
>>
>> Has the idea to implement a filter-http option been rejected already? 
>> (I'm happy to send a patch if
>> not?)
>>
>>
>> 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
>