On Fri, 29 Mar 2019 at 18:08, Sven Van Caekenberghe <[email protected]> wrote:
> 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 <[email protected]> wrote: > > > > > > > >> On 28. Mar 2019, at 08:02, Sven Van Caekenberghe <[email protected]> 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. > Not that we want the everything in the kitchen sink in Pharo, but DNS is PERVASIVE!!! :) A lot of experimentation with new services goes on with RR records such that having a "live" DNS implementation would facilitate Pharo being a platform to play with leading edge services. Can we discuss putting an in-Image DNS on the Pharo 8 roadmap? First consideration - what are the argument against this? Second consideration - who would volunteer for a working party to make this happen? btw, years ago I found the BIND book really entertaining reading... http://shop.oreilly.com/product/9780596100575.do > > > 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. > The maintenance burden has been the argument against in the past. But the opportunity of "liveness" may be worth bit. My presumption is the main part of DNS changes slowly, so the big question for me is how feasible is it to fall back to the C-library for things the in-Image stuff doesn't handle. cheers -ben
