[Dnsmasq-discuss] [RFC PATCH] Add support for blocking A or AAAA queries per domain

[Petr Menšík]

Hi!

It is probably too late for reactions. I think I had issues also with 
netflix.com specifically at home too.

I think you can do only address=/netflix.com/::1 now or use filter-AAAA 
to get rid of all AAAA responses. I like the desire to make it domain 
specific, but not the syntax.

There is filter-A and filter-AAAA option, which would be better to reuse 
for domain specific filtering. It does not take any parameter now. Could 
it be extended to:

filter-AAAA=/netflix.com/

or

filter-A=/example.com/

Similar way as we have local-service or enable-dbus with optional 
parameters. Make it global by default, but allow it more specific.

It might reuse the same code as address= when domain is present. I would 
avoid polluting address= or server= with more interpunction dividers if 
possible. Because it is possible to include more domains in single line.

This is valid too:

address=/example1.net/example2.com/example3.org/192.0.2.1

Parsing address correctly is already hard to decipher in the code. 
Ideally make some common static function and reuse the same parts, but 
do not make address parsing more complicated than it already is.

Otherwise I would love to see support for this merged in some form.

I think other implementations change the forwarded query from AAAA to A 
in this case (or the other way). If the answer is already cached, that 
won't forward anything, saving upstream query.

If not, we want to report difference between NXDOMAIN or NOERROR with 
empty answer. So some query is needed on that name. But the changed 
qtype should not deliver positive response to original requestor, answer 
must remain empty.

I assume that using both filter-A and filter-AAAA at the same time is 
not supported configuration, then using the other address type would be 
safe.

Cheers,
Petr

On 20/01/2023 05:34, Peter Tirsek wrote:
> On Wed, 18 Jan 2023, Buck Horn wrote:
>
>>> This patch extends the `--address` option to accept two new special
>>> address, `!4` and `!6`, which will cause the server to block A or AAAA
>>> queries for the specified domain(s), respectively.
>
>> I may be a bit late, but somehow, naming the options '!4' and '!6' 
>> does not sit right with me.
>
> You're not too late at all. Like I said, I'm not particularly happy 
> with parts of it as it is, so comments and suggestions are very welcome.
>
>
>> If I understand correctly, your patch is about blocking specific 
>> query types (namely A and AAAA), rather than blocking IPv4 or IPv6.
>> I'd prefer to see that reflected in the option name.
>
> Although I think it could be argued that IPv4 and A records are 
> intrinsically linked, as are IPv6 and AAAA records, your suggestion 
> makes a lot of sense. Does address=/netflix.com/!AAAA look better?
>
>
>> Thinking along the lines of query type would also point at potential 
>> issues with reverse lookups (query type PTR), which -going by your 
>> motivation- could be required to be dealt with as well?
>
> My requirement is only for forward lookups to prevent clients from 
> attempting IPv6 connections to sepcific domains. I have no need to 
> block reverse lookups, but if I did, I imagine I would simply 
> configure dnsmasq with address=/x.y.z.in-addr.arpa/ or 
> address=/x.y.z.ip6.arpa/ to block the reverse lookups.
>
>
>> For what it's worth, you may want to take a look at how Pi-hole 
>> (which is based on a specialised dnsmasq fork) is tackling filtering 
>> by query type - see 
>> https://docs.pi-hole.net/regex/pi-hole/#only-match-specific-query-types
>
> That's interesting. Maybe pihole is what I actually need to solve my 
> problem instead of dnsmasq. I'll have to look into that.
>
-- 
Petr Menšík
Senior Software Engieer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB