new tool: getaddrinfo frontend

[RavuAlHemio]

Greetings,

it might be interesting to provide a new tool: a frontend for the getaddrinfo function.

There are copious amounts of DNS clients out there -- nslookup, dig, drill and host, to name a few -- but mechanisms such as /etc/nsswitch.conf allow to completely change a system's name resolution behavior, prioritizing other mechanisms over DNS or replacing it outright, to say nothing of caching behavior, and most programs do not perform DNS resolution themselves, relying on functionality provided by the C library instead. This creates a discrepancy between the information provided by the DNS clients and that provided by the C library.

As I understand it, the C functions getaddrinfo and getnameinfo are the most flexible interfaces to the C library's name resolution facility, with older functions such as gethostbyname and gethostbyaddr accessing the same data but providing fewer options to influence the lookup. To my knowledge, while getaddrinfo and getnameinfo are absolutely great for C programs (as well as programs in other programming languages that have access to the C library), there is currently no executable whose primary purpose is querying this name resolution facility, and I think it might be a good idea to introduce one.

The most important purpose of this tool would be troubleshooting, e.g. identifying discrepancies between DNS and whatever data the system resolver is using.

What's the uutils team's opinion on this?

[tertsdiepraam]

Hi! I'll start of by saying that the coreutils is not the right place for this utility, since it is a well-defined set of utilities.

I think the standard getent utility might do what you want? I suppose we could decide at some point to add a repository for that tool in the future, although we cannot do everything of course.

[RavuAlHemio]

Ah, you're right, getent performs exactly those kinds of queries; apparently, it's part of the glibc utilities. (I should probably look around which tools are on offer by other C libraries.)

Regarding "well-defined set of utilities": well-defined, yes, but I wouldn't consider the set immutable -- after all, GNU coreutils introduced two new utilities, timeout and truncate, in version 7.0 (to say nothing of GNU coreutils' origin as an amalgamation of textutils, shellutils and fileutils). However, on reflection -- and skimming the list of GNU software projects --, if I were to choose one of the *utils projects for this idea, I guess inetutils is a better match.

[tertsdiepraam]

At least for now, I'd like people to get the utils that they expect when they swap out GNU coreutils for uutils coreutils. Just keeping it in a separate repo (and separate packages) would also work. I wonder how hard this would be to implement. It sounds fairly simple. You could probably also just whip out some quick Python to get what you want.