Changes/FixNetworkNameResolution

Fix Network Name Resolution

Summary

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 workarounds.

Owner

• 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
• Name Carlos O'Donell
• Email: carlos at redhat.com
• Release notes owner:

Current status

• Targeted release: Fedora 20
• Last updated: 2013-03-14
• Tracker bug: <will be assigned by the Wrangler>

Detailed Description

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.

Rationale

We are submitting this bug fixing effort as a Feature because:

• It is a high-impact change that will (positively) affect almost all networking software
• Developers will be able to use getaddrinfo() without ugly workarounds for new code
• We are going to publish guidelines for proper getaddrinfo() usage
• Documentation for getaddrinfo() bugs will be available
• Possible workarounds will be offered for backward compatibility
• Comments and errata will be sent to standards organizations
• We want to receive critical response during the whole process
• It will be part of the next networking testweek

Problem statement

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.

Bug reports related to getaddrinfo() can be found upstream:

http://sourceware.org/bugzilla/buglist.cgi?quicksearch=getaddrinfo

Affected software

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:

http://bugzilla.redhat.com/show_bug.cgi?id=883152

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.

Scope

The scope of this change is entirely restricted to the glibc resolver functions e.g. getaddrinfo and friends. The getaddrinfo function must be reviewed entirely with an eye towards an implementation that more closely mirrors other operating system best practices for return codes and behaviours. The function getaddrinfo must be evaluated against not only the RFC's, but their interpretation as seen from other operating system perspectives. It is not useful for Linux's main C library to have widely different interpretation of the RFCs. This work should be strictly focused on fixing the submitted defects from users. There are roughly 15-20 core bugs that identify the problems with getaddrinfo and each bug must be worked through to completion and fixed either by rejecting it or adjusting the implementation to match the RFC or interpretations of the RFC (where vague). Perhaps the most important thing to come out of this work will be a wiki page that documents glibc's decisions and positions on the various RFCs where they differ from other operating systems. This documentation will allow future RFEs to proceed in the knowledge of exactly what was implemented and why and the risks involved in future changes.

• Proposal owners: Carlos O'Donell

• Other developers: N/A (not a System Wide Change)

• Release engineering: N/A (not a System Wide Change)

• Policies and guidelines: N/A (not a System Wide Change)

Upgrade/compatibility impact

There is a serious potential for changes in getaddrinfo to impact application behaviour. No amount of work will fix the problems we will have to correct in applications using the resolver. Even if we were to version the old interface we would still have applications being rebuilt which would then use the new slightly adjusted semantics. It will require that we shake out any problems via rawhide builds with these changes and interacting and responding quickly to problems seen in rawhide including deep-dives into application code to determine use cases we missed.

N/A (not a System Wide Change)

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.

User Experience

• 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

Dependencies

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
• GLib
• Qt

Contingency Plan

• Contingency mechanism: Keep the current code
• Contingency deadline: Anytime
• Blocks release: No

Documentation

Currently, new documentation for name resolution is being drafted on the Fedora Wiki:

• Networking/NameResolution

Existing documentation:

• POSIX.1-2008
• RFC 3493 (informational)
• RFC 2553 (obsolete informational)
• Current getaddrinfo manpage: mostly like RFC 3493
• Ulrich Drepper: Userlevel IPv6 Programming Introduction

Release Notes

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.