If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

gethostbyname() API is not good for IPv4+IPv6 dual-mode system

RESOLVED DUPLICATE of bug 66872

Status

NSPR
NSPR
--
enhancement
RESOLVED DUPLICATE of bug 66872
17 years ago
17 years ago

People

(Reporter: Matti Aarnio, Assigned: larryh (gone))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
I have a web-site which hostname as both IPv4 and IPv6 addresses,
but Apache 1.3 running there supports only IPv4...

My home Alpha runs (with a one to NSPR configuration -- always adding
'-lc' to OS_LIBS for all Linux systems)  Mozilla 0.8.1, and besides of
heaps of suspicuous 64-bitness warnings, it looks fairly nice.

What me and my collegues (using i386 box) didn't understand initially is: 
Why I get "The connection was refused when attempting to connect zmailer.org"

SOMETIMES it succeeds, sometimes it keeps consistently failing.
"Why on earth isn't it falling back to other address-types ?"

Turns out that deep down in NSPR the API uses  gethostbyname()  for domain
lookup, and collects the data into single address-family HostEnt structure.

The current IETF and POSIX/Austin-group preferred API is  getnameinfo(), which
gets a chain of socket addresses + their associated flags, including
address-family.

I have learned the value of that API while working at ZMailer MTA, which
natively speaks both IPv4 and IPv6.

Switching from gethostbyname() to getnameinfo() is fairly extensive effort, but
after that, it indeed rewards handsomely in future dual-address-family internet.
(Reporter)

Comment 1

17 years ago

*** This bug has been marked as a duplicate of 66872 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.