晚上好，伙计们。
是否可以使用getaddrinfo() / getnameinfo()将非FQDN名称解析为其FQDN版本，但不必一直向下到规范名称，方式类似于gethostbyname()？
为了澄清我的问题，让我试着描述下面的使用场景。
假设我的公司example.com有几个内部部门负责（半）自治DNS区域管理，每个部门都发布为deptX.example.com，deptY.example.com等。
每个部门的计算机都配置为具有类似
的形式的DNS后缀搜索列表
search deptX.example.com example.com example.org
部门X提供公开称为host1.deptX.example.com托管的服务，但该名称实际上是internal-unique-name.cloud.example.org的别名。
内部名称（几乎）从未在任何地方发布或知晓任何客户端（当然，除非客户关注查看DNS响应）。
在许多（可能是大多数）情况下，管理员将其客户端配置为使用较短的部分名称host1.deptX，依靠DNS后缀搜索列表来解析全名host1.deptX.example.com。 （请注意，它可以在任何地方使用，而不仅仅是在X部门。）
某些管理员（AKA me）必须在各地将已发布的服务唯一标识为按部门分类的汇总列表，将引用同一主机的不同已发布名称（例如部分名称和相应的FQDN）折叠到一个条目中
过去，当gethostbyname()是唯一的选项时，我过去常常使用"host1.deptX"这样的部分名称来提供，并且回复中的h_name字段会给我FQ，但不是规范，DN "host1.deptX.example.com"，这对我来说非常好。
由于gethostbyname()和gethostbyaddr()已经正式淘汰了一段时间，我认为我应该转移到getaddrinfo()和getnameinfo()，尤其是新实现。
但是，我找不到等同于struct hostent的{{1}}字段。在我看来，最接近的是h_name struct addrinfo，只有在我请求使用ai_canonname标志解析规范名称时才会填充。如果我使用上面的场景，那么结果名称将是AI_CANONNAME，这不是我想要的。
我错过了什么，可能会误导internal-unique-name.cloud.example.org？有没有办法让这个功能给我我需要的答案？
国际海事组织，从一开始就应该避免使用那些部分名称。 OTOH，现在尝试修复它们是不切实际的（特别是在我自己以外的部门），所以这不是一个真正的选择。
我当然能够从getaddrinfo()进一步切换到libresolv＆＃39; s getaddrinfo()及其兄弟姐妹，但我想避免这种情况，原因有多种，包括解决本地问题的能力名称（例如res_query()），使用本地名称缓存（例如UNIX上的/etc/hosts）和在备用目录（例如LDAP和NIS）上发布的名称，但在DNS中不存在（很少见，但绝对是现存的情况）。
编辑：我进一步测试了，发现我上面犯了一个错误。我的印象是
ncsdstruct hostent总是只附加短名称的相应FQDN，但这种行为只发生在本地数据库中的名称（h_name，在任何尝试咨询DNS之前读取的，并且FQDN是该行中的第一个条目。对于一般情况，DNS解析的名称，/etc/hosts会填充规范名称，而非规范的FQDN只会出现在h_name字段指向的列表中。所以
h_aliases＆＃39;struct hostent实际上等同于h_namestruct addrinfo，行为差异显然ai_canonname始终使其版本指向某些数据，而gethostbyname()仅在使用选项标志明确命令时才使用getaddrinfo()。OTOH，
ai_canonname没有像指向已知别名列表的指针，我可以检查以确定主机所属的部门。最后，我想我会坚持
struct addrinfo一段时间，至少对于当前的工具而言。