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.
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.
What is a good response for AAAA record, which may exist, but we pretend
it does not? NODATA or REFUSED? All similar quirks break DNSSEC
deployment. 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.
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.
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
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
