I'm trying to trace an issue where gethostbyname only appears to work if lookups is not provided, or is explicitly passed as "b". When it it is defined as "f" (or "fb" or "bf") it raises Could not contact DNS servers.
Here is a scenario I pieced together from a larger program:
$ echo "1.2.3.4 calendar.google.com calendar" > /tmp/foo
$ cat /tmp/foo
1.2.3.4 calendar.google.com calendar
$ export HOSTALIASES=/tmp/foo
$ echo $HOSTALIASES
/tmp/foo
$ python
Python 3.8.3 (default, May 12 2021, 11:42:13)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> from aiodns import DNSResolver
>>> from aiodns.error import DNSError
>>> from socket import AF_INET
>>>
>>> dns_resolver = DNSResolver(domains=["google.com"], lookups="f")
>>> name = "calendar"
>>> try:
... dns_resolver.gethostbyname(name, AF_INET).result()
... except DNSError as exception:
... print(f"Oh no: {name}; {exception}")
...
Oh no: calendar; (11, 'Could not contact DNS servers')
>>>
From what I can tell, this is happening because the initial status is being returned when the search loop falls through. ...but I cannot figure out why it is not matching any entries.
From what I can find in the man page, this lookup should work when the FQDN is listed first in the alias list.
The upstream c-ares project appears to have an internal test covering this scenario, with the ordering reversed: which I have tried without success.
I'm trying to trace an issue where gethostbyname only appears to work if
lookups
is not provided, or is explicitly passed as"b"
. When it it is defined as"f"
(or"fb"
or"bf"
) it raisesCould not contact DNS servers
.Here is a scenario I pieced together from a larger program:
From what I can tell, this is happening because the initial status is being returned when the search loop falls through. ...but I cannot figure out why it is not matching any entries.
From what I can find in the man page, this lookup should work when the FQDN is listed first in the alias list.
The upstream c-ares project appears to have an internal test covering this scenario, with the ordering reversed: which I have tried without success.
Am I overlooking something here?