Holger, I'll write most of my comments inline.
Yesterday I moved my code to https://github.com/svenvc/NeoDNS using Tonel format, to make it a bit easier to consume. I also did a couple of minor updates while going over the functionality. Note the 'my code' is in the package Net-Protocols-DNS-Experimental, which is using the object model in 'Net-Protocols-DNS-MessageFormat' (that already existed before, I just ported/cleaned it a little bit to my taste). Are you coming to the Pharo Days ? We could talk there. (More below) > On 28 Mar 2019, at 09:29, Holger Freyther <hol...@freyther.de> wrote: > > > >> On 28. Mar 2019, at 08:02, Sven Van Caekenberghe <s...@stfx.eu> wrote: >> >> Hi Holger & Norbert, >> > > great. Regardless of how many versions exist. We should get one into the > image with proper platform integration. > > I wasn't aware of your code but I assumed it is something you could write, > hence the Paleo prefix. Now that the Paleo code is the Neo one is more > funny... Yeah, naming is always fun, isn't it ? >> NeoSimplifiedDNSClient default addressForName: 'pharo.org'. "104.28.27.35" >> >> One of my goals was to use it as a more reliable, non-blocking 'do we have >> internet access' test: >> >> NeoNetworkState default hasInternetConnection. "true" > > > What is internet access and how would this be used? Is this about captive > portals? With local network policy the big anycast services might be blocked > but the user can still reach services. Or with deployed microservices they > might reach other but not the outside? For years there is this issue in Pharo that if we build features that require internet access (say for example automatic loading of the Catalog when you start using Spotter, but there are many more places where this could add lots of value), that people say "don't do this, because it won't work when I have slow or no internet (like on a train)". The core cause of the problems is that the current NameResolver is totally blocking, especially in failure cases, which gives a terrible experience. One way to fix this would be with the concept of NetworkState, a cheap, reliable, totally non-blocking way to test if the image has a working internet connection. Related is the option of 'Airplane Mode', so that you can manually say: "consider the internet unreachable". The main scope was real internet access, not (possibly) limited internal network access. But that is a good point to think about. > ... snip ... > > >> The main problems are concurrent and asynchronous requests, as well as error >> handling. >> >> I would be great if we could do this well in-image. (But getting OS DNS >> settings is hard too). >> >> We should talk ;-) > > Agreed that getting the OS DNS settings is hard but not impossible (go seems > to get away with its implementation on unix). It seems we manage to honor > platform settings for http proxies and I am confident we can do it for DNS as > well. I hacked a #getSystemDNS class method that goes via /etc/resolv.conf and it works (but of course not on Windows). In the 'initialise' protocol, there are #useCloudflareDNS, #useGoogleDNS, #useSystemDNS as well as #useMulticastDNS methods. I would *very* much prefer not to depend on any obscure, hard to maintain VM code (FFI would just be acceptable). > I planned to solve concurrency by creating one stub resolver per request and > having a shared cache. The internet can be a hostile place and DNS is an easy > victim. Cache poisoning does exist and random source port, 0x20 > randomization, random transaction ids, disrespecting PTMU ICMP messages are > the few mitigations we have. What I tried/implemented in NeoDNSClient (which inherits from the one-shot NeoSimplifiedDNSClient) is a requestQueue and a cache (respecting ttl), where clients put a request on the requestQueue and wait on a semaphore inside the request (respecting their call's timeout). A single process (that starts/stops as needed) handles the sending & receiving of the actual protocol, signalling the matching request's semaphore. (The #beThreadSafe option needs a bit more work though). But yes, ultimately, things might be more complex. There is of course a problem in doing in-image DNS: it creates a (possibly) huge maintenance burden with a lot of responsibility. Now, since we already do socket streams, TLS/SSL and HTTP, the risk/challenge is probably acceptable. In any case, any solution would first need to prove itself in lots of real world situations. I actually added a #install class method to NeoDNSClient that hacks into the existing NetNameResolver and takes over responsibility for #addressForName:[timeout:] - for the whole image - of course this is still pure alpha. I am curious though, what was your initial motivation for starting PaleoDNS ? Which concrete issues did you encounter that you wanted to fix ? > Let's definitely talk. I hang out in the pharo discord group. :) > > > holger I am only an occasional IM users, I more of an email guy. Sven
