On 05/04/2023 14:32, Ed W wrote:
On 17/03/2023 17:54, Simon Kelley wrote:
On 16/03/2023 16:04, Petr Menšík wrote:
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.
I have customers on Iridium satellite links. So basic system is 2.4kbit (300
bytes/sec) and it costs
around $100/MB
Faster systems are limited by the 22kbit uplink (put a system with something
from Microsoft near
this link and it can nearly fill the uplink with spammy DNS queries for all the
junk the MS seem to
be pre-installing on Windows 11...). Data costs on this system are cheaper at
only $10/MB (so
$10,000/GB, although there are actually discounts on this level of data which
bring it down a bit)
A further issue with having to bridge typical commercial devices (iphones,
laptops, etc) is that the
modem link goes down when not in use and takes many seconds to bring it up.
Annoyingly the modem
hardware caches some of the packets in flight and so you easily get massive
bandwidth amplification,
eg many clients retry a DNS query every 2 seconds, so if it takes 10 seconds to
bring up the link
you have 5x as much traffic queued on the outbound, then you get 5x replies,
then if you aren't
careful you get 4x ICMP replies about the port being closed. At $10/MB this is
costly very quickly
We add value by using all kinds of tricks to filter the traffic to the very
minimum needed. However,
this game requires compressing data carefully, counting bytes and packets and
often peering inside
packets to decide what can get chopped and what can live.
Note I'm not looking for suggestions on alternatives or tips here. Just thought
you might be
interested that these worlds still exist...
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.
My opening position on filtering AAAA requests is to "REFUSED" them. However,
it seems like musl
resolver handles this as a fail for everything, including the A record. Now I'm
digging through the
code and pretty sure I can fix my own resolver, but we are looking to offer a
docker solution for
the customers, plus we assume we will have various IOT devices on the LAN side
using us as well, so
I can't necessarily have them all apply patches to their distros...
So I'm on the fence here over pragmatism and needing to get a solution that
works for everyone.
Broadly we have 2 modes, either we have cellular connectivity and we want to
let people do as they
wish, or we are in satellite mode and heavily filtering apps and traffic to the
minimum. Ideally I
want to use external firewall rules to decide the fate, but this looks
difficult. Also I want to
support wireguard and the like, so we will likely need AAAA in some limited
capacity...
I will likely end up butchering dnsmasq to get something reasonable for this
use case I think.
Ideally I would want AAAA for specific domains to complete and everything else
to magically give the
correct response without an upstream check. Simon's suggestion of being able to
search the cache for
the A and guess an answer would get me closer some of the time. I think for
the rest the best I can
do is blindly convert "REFUSED" into "NODATA" and accept this will break some
small proportion of
things, but it's the best I can do within these constraints?
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.
Yes, I think this should be low priority because it seems like there are a lot
of subtleties with
resolver implementations. Also for most users this is about advert blocking and
low priority stuff
really. We almost need a whole pluggable filtering system for these guys,
perhaps an embedded lua
decision engine for each query? My case is pragmatic and seemingly impossible
to do perfectly. So
overall I think this is a rather specialist feature which should be avoided by
most people...
I would love if we could improve things a little bit though. The idea of
filtering based on cached A
query results would be nice.
Thanks for all the replies and the very helpful insight into the underlying
challenges!
FYI the latest code allows you to do --filter-rr=HTTPS and it's cleverer
about using cache: if any query for a domain has already been answered
and cached then it uses that to decide if the answer should be NXDOMAIN
or NODATA and doesn't forward the query. If that's enough depends on
your resolver implementation, I guess.
Cheers,
Simon.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
