>>>>> "Philip" == Philip Blundell <pb@labs.futuretv.com> writes:
Philip> Neither of these is the case. The getaddrinfo function won't
Philip> stop processing just because it has found an entry; it will
Philip> continue searching other protocols and methods to see if there
Philip> are more details.
It will stop. For example, in my former example, if I change AF_UNSPEC to
AF_INET, once it notice that /etc/hosts contains the correct entry it stop
processing (i.e. /lib/libnss_dns.so.2 is never loaded). Strace verifies
this.
Anyway, getaddrinfo is probably not the only function that has the strange
behaviour (of resolving all methods for IPv6 protocols before resolving
methods for IPv4). The reason why I single out that particular statement is
simply that SSH tried its best to pass AF_INET instead of AF_UNSPEC if it is
given a -4 parameter, only (carelessly?) leaving a call to getaddrinfo not
modified.
Philip> You should probably set up a local DNS server for this
Philip> situation.
This seems messy. I have an on-demand dialing systems with dynamic IP
addresses. It relies on the initial remote DNS query generated by most
network application to bring the link up, so that TCP connections can be
made when the IP addresses are correct. Making a local DNS server defeat
this--DNS queries will be answered by the local server and the first
outgoing network packet will already be a TCP packet instead of a UDP one.
This means the first TCP connection will always fail, which won't be retried
since TCP is supposed to be reliable.
Also, this will delay the boot process of the local DNS server since it will
try to get information from the root server, requiring to bring up the link.
Isaac.
Attachment:
pgpdLEfej9wm8.pgp
Description: PGP signature