IPv4 and IPv6 host/service name resolution doesn't work very well in Fedora. The <code>getaddrinfo()</code> function in glibc returns wrong results in many cases. This feature aims to fix a bunch of name resolution bugs in glibc that prevent applications from fully using name resolution functions without doing a bunch of workarounds.

+

The GNU C Library <code>getaddrinfo</code> API is the core name resolution API for C library. The API interprets and implements the requirements of several RFCs and harmonizes the requirements as needed by the project. Unfortunately some of the cases of name resolution are difficult implement and up for interpretation depending on the RFC. This has lead to sometimes different behaviour between OS implementations. In some cases the <code>getaddrinfo()</code> function in glibc return the wrong results.

+

+

This feature aims to fix a number of name resolution bugs in glibc that prevent applications from fully using name resolution functions without workarounds. The fixes should bring glibc closer to other OSs and their interpretations of the RFCs.

The GNU C Library getaddrinfo API is the core name resolution API for C library. The API interprets and implements the requirements of several RFCs and harmonizes the requirements as needed by the project. Unfortunately some of the cases of name resolution are difficult implement and up for interpretation depending on the RFC. This has lead to sometimes different behaviour between OS implementations. In some cases the getaddrinfo() function in glibc return the wrong results.

This feature aims to fix a number of name resolution bugs in glibc that prevent applications from fully using name resolution functions without workarounds. The fixes should bring glibc closer to other OSs and their interpretations of the RFCs.

Currently the getaddrinfo() function doesn't work as it was designed. Many of its features are buggy and cannot be used without extensive workarounds. Many software packages are using getaddrinfo() with such workarounds. Many can trigger its failures. And many packages that don't use getaddrinfo() will be ported in the near future.

The behavior of getaddrinfo() is often nonstandard, undocumented, surprising, or just plain wrong. We already identified a number of problems. The most prominent examples are here.

getaddrinfo() may return duplicate or even wrong addresses from /etc/hosts

getaddrinfo() with NULL servname may return duplicate addresses

getaddrinfo() with AI_PASSIVE may still return address list not suitable for bind()

getaddrinfo() with AI_ADDRCONFIG may fail to translate literal addresses

getaddrinfo() with AI_ADDRCONFIG may fail to resolve /etc/hosts addresses

getaddrinfo() with AI_ADDRCONFIG may send unwanted AAAA queries

getaddrinfo() has a bad choice of default flags

Whether or not the problematic actually occurs depends on /etc/hosts configuration, /etc/resolv.conf configuration, getaddrinfo() input parameters, runtime kernel network interface configuration, and more. While testing the known bugs or reading the source code, more and more bugs are discovered.

The above problems affect software that wants to use getaddrinfo() to:

Get parameters for connect() or sendto() to start communicating

Get parameters for bind() to listen on specific addresses

Build IP address based accesslists

Perform name resolution for other purposes

Although it would be nice to also test and fix all software in Fedora using getaddrinfo(), that is not feasible. Therefore we are going to concentrate on checking and fixing the GNU C library, checking and fixing the most important toolkits dealing with networking, and documenting a set of guidelines for daemons and application software.

Fedora bugs related to dualstack networking including name resolution problems should be added to the following tracker bug:

Most Fedora installations are being used in networking environments. Many of them are laptop installations that connect to various networks or even work offline. As name resolution is a critical part of networking experience, Fedora will benefit from being able offer reliability and avoid surprising and buggy behaviour.

Bugs addressed by this feature page are especially tricky because an ordinary user is usually not able to properly report them, not to say analyze them. Especially bugs affecting plain old IPv4 services should be fixed and avoided in the future.

And there's a bonus. As all the documentation will be on Fedora Wiki, attracting attention of other members of the community. Together with other network-related efforts, Fedora could be seen as the leader in linux networking.

Almost all development will be done via contributions upstream. Each library will have to be either updated or the fixes backported. Networking APIs are fairly independent from the rest of the libraries.

In case the fixes are not ready in time, all packages would continue to use
workarounds that make them work with the buggy versions of glibc and/or other libraries.h

If, on the other hand, there are packages negatively affected by the changes, we will offer help with fixing the package and/or revert the changes for the next Fedora release. We do not expect any negative impact, though, and we are analysing any potential problems in advance.

We plan to publish a list of packages that might be directly affected by our modifications.

Name resolution for network host and service names now works as expected and in line with the standards and user needs. Daemons and applications will now resolve names correctly without
extensive workarounds. Both IPv4 and IPv6 addresses are fully supported.