- 1 Fix Network Name Resolution
- 1.1 Summary
- 1.2 Owner
- 1.3 Current status
- 1.4 Detailed description
- 1.5 Benefit to Fedora
- 1.6 Scope
- 1.7 How to test
- 1.8 User experience
- 1.9 Dependencies
- 1.10 Contingency plan
- 1.11 Documentation
- 1.12 Release notes
- 1.13 Comments and discussions
Fix Network Name Resolution
IPv4 and IPv6 host/service name resolution doesn't work very well in Fedora. The
getaddrinfo() 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 workaround.
- Name: Pavel Šimerda
- Email: psimerda at redhat.com
- Name: David Jaša
- Email: djasa at redhat.com
- Name Tore Anderson
- Email: tore at fud.no
- Targeted release: Fedora 19
- Last updated: 2013-01-15
- Percentage of completion: 10%
getaddrinfo() function doesn't work as it was desinged. 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.
We are submitting this bug fixing effort as a Feature because:
- It is a high-impact change that will (positively) affect allmost all networking software
- Developers will be able to use
getaddrinfo()without ugly workarounds for new code
- We are going to publish guidelines for proper
- Documentation for
getaddrinfo()bugs will be availabe
- Possible workarounds will be offered for backward compatibility
- Comments and errata will be sent to standards organizations
- We want to recieve critical response during the whole process
- It will be part of the next networking testweek
The behavior of
getaddrinfo() is often nonstandard, undocumented, surprising, or just plain wrong. We already indentified 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
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</code>
Whether or not the problematic actually occurs depends on
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.
Bug reports related to
getaddrinfo() can be found upstream:
The above problems affect software that wants to use
- Get parameters for
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:
Benefit to Fedora
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.
- Name service switch
- DNS module
- hosts module
- GLib networking API
- Qt networking API
- Guidelines for daemons and applications
- Backward compatibility guidelines
- Documentation and hints for testing
- Comments and/or errata for standards organizations
How to test
- Reproducers will be always documented in the (usually upstream) bug reports
- The best way to test
getaddrinfo()is with Python's socket module
- Qt and Glib can be also tested in Python
- Some test programs in C could also be helpful
- Lot of tests can be done with actual software using
getaddrinfo()or one of the libraries
- Everyday use can help, too
Please note that we are going to test this feature as part of the next Fedora Network Test Week.
- Users will be less likely to see confusing and hard-to-reproduce errors
- Some configurations will start working that didn't work before
- Name resolution bugs in applications will be resolved more quickly
- Developers will be able to concentrate on their real work
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.
Libraries that may need updating or fixing:
- GNU C Library
If there were no fixed upstream versions available for Fedora 19, and backported fixes will not be available, Fedora could continue to use the original version. All packages would continue to use workarounds that make them work with the buggy versions.
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.
Currently, all related documentation is being drafted on the Fedora Wiki:
Name resolution for network host and service names now works as expected and in line with the standards and user needs. Daemons and application will now resolve names correctly without extensive workarounds. Both IPv4 and IPv6 addresses are fully supported.