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