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
_______________________________________________
Dnsmasq-discuss mailing list
[email protected]
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
