You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Am I overlooking something here?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: