1

Good evening, folks.

Is it possible to use getaddrinfo()/getnameinfo() to resolve non-FQDN names to their FQDN versions, but without necessarily going all the way down to the canonical name, in a way similar to that of gethostbyname()?

To clarify my question, let me try to describe my use scenario, below.

  1. Suppose that my company, example.com, has several internal departments with (semi-)autonomous DNS zone administration, each published as deptX.example.com, deptY.example.com etc.

  2. Every department's computer is configured to have a DNS suffix search list in a form like

    search deptX.example.com example.com example.org

  3. Department X offers a service publicly known as hosted by host1.deptX.example.com, but that name is actually an alias to internal-unique-name.cloud.example.org.

  4. The internal name is (almost) never published or known by any client anywhere (unless, of course, that client cares to look at the DNS response).

  5. In many (possibly most) cases, administrators configure their clients to use a shorter, partial name host1.deptX, relying on the DNS suffix search list to resolve the full name host1.deptX.example.com. (Notice that it works everywhere, not just in Department X.)

  6. Some administrator (AKA me) has to uniquely identify published services everywhere into a summarized list, classified by department, collapsing different published names referring to same host (such as the partial names and corresponding FQDN) into a single entry.

In the past, when gethostbyname() was the only option, I used to feed it with a partial name such as "host1.deptX", and the h_name field in the response would give me the FQ, but not canonical, DN "host1.deptX.example.com", which was very good for me.

Since gethostbyname() and gethostbyaddr() are officially obsolete for quite some time, I thought that I should move to getaddrinfo() and getnameinfo(), especially with new implementations.

However, I didn't find an equivalent to struct hostent's h_name field. The closest, as it seems to me, is struct addrinfo's ai_canonname, which only gets filled when I request to resolve the canonical name, with the AI_CANONNAME flag. If I do that with the scenario above, the resulting name would however be internal-unique-name.cloud.example.org, which is not what I want.

Am I missing anything, and maybe misusing getaddrinfo()? Is there a way to have that function give me the answer that I need?

IMO, those partial names should have been avoided from the beginning. OTOH, it would be impractical to try to fix them now (especially in departments other than my own), so that is not really an option.

I am certainly able to switch further from getaddrinfo() to libresolv's res_query() and its siblings, but I would like to avoid that for a number of reasons, including the ability to resolve local names (e.g. /etc/hosts), use local name caches (e.g. ncsd on UNIX) and names that are published on alternate directories, such as LDAP and NIS, but absent from the DNS (a rare, but definitely extant situation).

EDIT: I tested further, and noticed that I made a mistake above. I was under the impression that struct hostent's h_name would always just append the short name's corresponding FQDN, but such behavior was only happening with names that were in the local database (/etc/hosts, which was being read before any attempt to consult DNS) and for which the FQDN was the first entry in the line. For general, DNS-resolved names, h_name gets filled with the canonical name, and the non-canonical FQDN only appears in list pointed to by the h_aliases field.

So struct hostent's h_name is actually equivalent to struct addrinfo's ai_canonname, with the behavior difference that gethostbyname() apparently always makes its version point to some data, while getaddrinfo() only uses ai_canonname if explicitly commanded by the option flag.

OTOH, struct addrinfo doesn't have anything like a pointer to list of known aliases, that I can check against to figure out what department the host belongs to.

In the end, I think I will stick to gethostbyname() for a little while, at least for the current tool.

4

0 回答 0