On 11/03/2023 17:34, Ed W wrote:
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?
The problem with doing this in dnsmasq or with iptables is that the A
and AAAA queries are separate.
If you want to suppress the AAAA query (rather than the answer) you need
to know is the answer should be NODATA or NXDOMAIN.
If the A query happens first then A query happens first then you have
that information: an NXDOMAIN answer means the AAAA query can be
NXDOMAIN too. A NODATA or actual data means that the answer to the AAAA
query can be NODATA without every sending it upstream.
Of course there's the possibility that nothing is cached for the domain,
in which case you have to send the query upstream.
The resolver is somewhat different: it just returns IPv4 and IPv6
answers, if you could hack it to always return an empty set of IPv6
addresses and never make AAAA DNS queries, you're fixed, as long as
everything uses the resolver library calls to do DNS. As long.
For dnsmasq, an AAAA query will get an immediate NXDOMAIN if the A query
already happened and cached the NXDOMAIN response. Otherwise the AAAA
query gets sent upstream and if any RR are returned, that answer gets
turned into a NODATA answer by filter-aaaa.
What doesn'y happen, but could, is a search of the cache for A or other
records. If they exist, an AAAA query with filter-aaaa could get turned
into a NODATA answer without being sent upstream.
Simon.
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
