t/util.h uses undocumented and non-standard ns_* APIs

[omasanori]

resolve_esni_keys in util.h uses ns_ resolver APIs originated from BSD (BIND8's libbind more specifically, which is no longer maintained by ISC). They have some problems:

1. Not all platforms implement these APIs. For instance, OpenBSD implements well-known res_ and dn_ APIs but not ns_ ones. (This is the major problem to me who use h2o with OpenBSD.)
2. Even platforms with these APIs, they are not documented. See Debian's bug #629260 - ns_initparse(3), ns_msg_count(3), etc: please document resolver library routines for the case of GNU/Linux. FreeBSD's man page mentions only a few ns_ APIs, but not ones we use.

It would be great if the code is migrated to a cross-platform and well-maintained DNS parsing library. I am trying to port the code to LDNS now.

[kazuho]

Thank you for reporting the issue as well as working for a fix.

I am happy to look into a PR if it solves the issue without introducing additional complexity. The reason I state that is because the code exists solely for testing. Use of ESNI is meaningless without a trusted channel to the DNS recursor (either by using DoH or DoT). However, it is my understanding is that it's not easy to find a DNS stub library that supports either of the two.

Considering the facts, I am fine with disabling the feature on platforms where the ns_ API is unavailable. Therefore the premise stated above.

[omasanori]

Thank you for your rapid response.

I am happy to look into a PR if it solves the issue without introducing additional complexity.

Unfortunately no, we will need to check if libldns is installed in a CMake file, document it, update CI script etc.

Use of ESNI is meaningless without a trusted channel to the DNS recursor (either by using DoH or DoT). However, it is my understanding is that it's not easy to find a DNS stub library that supports either of the two.

Unbound, the resolver developed by the same organization as LDNS, has support for DoT (both upstream and downstream) so they probably provide a solution IMHO.

Considering the facts, I am fine with disabling the feature on platforms where the ns_ API is unavailable. Therefore the premise stated above.

I am OK with this direction.

[omasanori]

I will make the feature optional for platforms without required APIs when I have time.

While actually off-topic, @kazuho, my understanding is that DoT/DoH protect answers by hop-by-hop principle, so practically DNSSEC is also needed to verify if an answer is an unmodified copy of one provided by a content server. Is it correct?