A number of years ago I wrote code that uses dns_open(...) and dns_lookup(...) to call a remote name server for dns resolution.
Testing in Monterey, Big Sur and Catalina I get a NULL reply from dns_lookup. The code produces an expected result with Mojave and High Sierra.
If I pass NULL as the argument to dns_open() then resolution is successful, but that is not using the desired name server.
I have submitted feedback request FB10027085 with a small project that demonstrates the failure.
I have submitted feedback request
FB10027085
Thanks.
<dns.h> is a pretty obscure API, and we strongly encourage folks to use the system resolver, so I’m not totally surprised it’s having problems in this case.
In your bug you wrote:
The builtin
hostcommand succeeds
That’s because host doesn’t use this API. Rather, it’s a subcommand within the dig project and it uses the same infrastructure as dig.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Thanks for looking Quinn. I understand the benefits of using the system resolver and in general I do. However there are times when it's handy to check alternate name servers to see if records have propogated, compare response times between servers and stuff like that. I guess this can all be done from calling out to host or dig, but the <dns.h> api was there so I used it.
I have a suspicion that this problem is related to the libresolv security patches applied in https://support.apple.com/en-us/HT213257 and https://support.apple.com/en-us/HT213256.
