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