software probe DNS resolving not via OS functions
Hello! I have a software probe and it does many DNS requests. I installed the nscd cache on my machine, but the probe itself doesn't use the operating system's libc functions to resolve names. Is there a special reason for that? I am aware I can install a real local caching DNS server on the machine like dnsmasq, but I would like to ask the question. :-) -- kind regards Marco
Hi Marco, The answer is a bit more complex than yes or no :) Let me get into the weeds here: The Atlas UI by default has probes resolve DNS queries using the local (system) resolver. This is done to ensure that probes with a non-functional DNS configuration can still execute measurements properly, and reach the same results other probes would. See below the setting in the Atlas UI:  The Atlas API by default resolves DNS queries on the Atlas infrastructure, that is prior to the measurement being executed by the probe. That means the probe will not resolve DNS at all, and get a target IP address specified to perform the measurement on Assuming the probe will be asked to locally resolve a DNS query, this can be done in 2 ways for most measurements, except 1. Taking ‘ping’ as an example: Looking at eperd/evping.c, the usage comments list an option -e which forces the libc stub resolver to be used The handling of this -e option is done in eperd/ping.c, line 1359, where delay_name_res is set to 0 (it is 1 by default for legacy compatibility). If delay_name_res is set to 0, host_and_af2sockaddr() is invoked which in turn can be found in libbb/xconnect.c at line 352 This in turn invokes str2sockaddr in the same file at line 213 which tries a number of ways to resolve the string to an address (IP string to number conversion for one), but ends up at line 317 with a call to getaddrinfo() getaddrinfo() is a function in the std C library If the -e option is not supplied, it seems that the libevent getaddrinfo() is called, which seems to be an asynchronous implementation of the same function call. In conclusion, if the probe is asked to resolve locally, getaddrinfo() is called, which should tie into the libc resolver. The one exception is the ‘DNS’ measurement. In this specific case, the target of the measurement is a DNS server, and because the intent is to get detailed information from the DNS server, the requests will be performed directly to the DNS server without talking to the libc resolver (that cannot provide this level of detail). Hope this helps. Regards, Michel
On 17 Aug 2024, at 06:22, Marco Moock <mm@dorfdsl.de> wrote:
Hello!
I have a software probe and it does many DNS requests. I installed the nscd cache on my machine, but the probe itself doesn't use the operating system's libc functions to resolve names.
Is there a special reason for that?
I am aware I can install a real local caching DNS server on the machine like dnsmasq, but I would like to ask the question. :-)
-- kind regards Marco ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
participants (2)
-
Marco Moock
-
Michel Stam