Hi Holger & Norbert, Great, but ...
This did already exist in various forms, a couple of years ago I made a newer version, they can all be found in http://www.smalltalkhub.com/#!/~BenComan/DNS/ - including unit tests (but some of the older code in there is a bit stale). It covers most record types, but most of them are not used a lot. Simple usage: 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" From the class comments: ======================= I am NeoSimplifiedDNSClient. I resolve fully qualified hostnames into low level IP addresses. NeoSimplifiedDNSClient default addressForName: 'stfx.eu'. I use the UDP DNS protocol. I handle localhost and dot-decimal notation. I can be used to resolve Multicast DNS addresses too. NeoSimplifiedDNSClient new useMulticastDNS; addressForName: 'zappy.local'. Implementation I execute requests sequentially and do not cache results. This means that only one request can be active at any single moment. It is technically not really necessary to use my default instance as I do not hold state. ==================================== I am NeoDNSClient. I am a NeoSimplifiedDNSClient. NeoDNSClient default addressForName: 'stfx.eu'. I add caching respecting ttl to DNS requests. I allow for multiple outstanding requests to be handled concurrently. Implementation UDP requests are asynchroneous and unreliable by definition. Since DNS requests can take some time, it should be possible to have multiple in flight at the same time, thus concurrently. Replies will arrive out of order and need to be matched to their outstanding request by id. If a request has been seen before and its response is not expired, it will be answered from the cache. Each incoming request is handled by creating a NeoDNSRequest object and adding that to the request queue. This triggers the start up of the backend process, if necessary. The client then waits on the semaphore inside the request object, limited by the timeout. The backend process loops while there are still outstanding requests that have not expired. It sends all unsent requests at once, and then listens briefly for incoming replies. It cleans up expired requests. When a reply comes in, it is connected to its request by id. The semaphore in the request object is then signalled so that the waiting client can continue and the request is removed from the queue. The process then loops. If the queue is empty, the backend process stops. ================ But that last one is less reliable, it was my last addition. 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 ;-) Sven > On 28 Mar 2019, at 01:32, Holger Freyther <hol...@freyther.de> wrote: > > Norbert and me looked at using DNS for service discovery and ran into some of > the limitations of the NetNameResolver[1]. In the end I created an initial > DNS implementation in Pharo called Paleo-DNS[2] to overcome these. > > DNS is a protocol we use every day but rarely think of. There is an active > IETF community that is evolving the protocol and finding new usages (service > discovery is one of them). > > In DNS there are different types of resource records (RR). The most commonly > used ones in a client ("stub") are "A" for IPv4 addresses, "AAAA" for IPv6 > addresses, "CNAME" for aliases, "SRV" records. So far only support for "A" > records was implemented. > > So if you are curious about DNS then this is a great opportunity to add your > favorite RR implementation to it and send a PR. There are probably 20+ of > them to go. ;) > > > Query example using DNS-over-TLS (DoT) to Google Public DNS > > PaleoDNSTLSTransport new > destAddress: #[8 8 4 4] port: 853; > timeout: 2 seconds; > query: (PaleoDNSQuery new > transactionId: (SharedRandom globalGenerator > nextInt: 65535); > addQuestion: (PaleoRRA new rr_name: > 'pharo.org.'); > addAdditional: (PaleoRROpt new udpPayloadSize: > 4096)) > > > [1] It's blocking on Unix, on Mac only one look-up may occur at a time and it > returns exactly one address. There is also no IPv6 support. > > [2] https://github.com/zecke/paleo-dns
