11.20 Obsolete IPv6 Address Lookup Functions
While IPv6 was being developed, the API to request the lookup of an IPv6 address went through several iterations. The resulting API was complicated and not sufficiently flexible, so it was deprecated in RFC 2553 [Gilligan et al. 1999]. RFC 2553 introduced its own new functions, which were finally simply
The RES_USE_INET6 Constant
doesn't have an argument to specify what address family is of interest (like
struct entry), the first revision of the API used the
constant, which had to be added to the resolver flags using a private, internal interface. This API was not very portable since systems that used a different internal resolver interface had to
to look up AAAA records first, and only look up A records if a
to return IPv4 addresses as IPv4-mapped IPv6 addresses. We will describe
The gethostbyname2 Function
The gethostbyname2 function adds an address family argument to gethostbyname .
When the af argument is AF_INET , AF_INET , gethostbyname2 behaves just like gethostbyname , looking up and returning IPv4 addresses. When the af argument is AF_INET6 , AF_INET6 , gethostbyname2 looks up and returns only AAAA records for IPv6 addresses.
The getipnodebyname Function
RFC 2553 [Gilligan et al. 1999] deprecated RES_USE_INET6 and gethostbyname2 because of the global nature of the RES_USE_INET6 flag and the wish to provide more control over the returned information. It introduced the getipnodebyname function to solve some of these problems.
This function returns a pointer to the same hostent structure that we described with gethostbyname . The af and flags arguments map directly to getaddrinfo's hints.ai_family and hints.ai_flags arguments. For thread safety, the return value is dynamically allocated, so it must be freed with the freehostent function.
The getipnodebyname and its matching getipnodebyaddr functions are deprecated by RFC 3493 [Gilligan et al. 2003] in favor of getaddrinfo and getnameinfo .
11.21 Other Networking Information
Our focus in this chapter has been on hostnames and IP addresses and service
All four types of information can be stored in a file and three functions are defined for each of the four types:
Each of the four types of information defines its own structure, and the following definitions are provided by including the
In addition to the three get , set , and end functions, which allow sequential processing of the file, each of the four types of information provides some keyed lookup functions. These functions go through the file sequentially (calling the getXXXent function to read each line), but instead of returning each line to the caller, these functions look for an entry that matches an argument. These keyed lookup functions have names of the form getXXXbyYYY . For example, the two keyed lookup functions for the host information are gethostbyname (look for an entry that matches a hostname) and gethostbyaddr (look for an entry that matches an IP address). Figure 11.21 summarizes this information.
Figure 11.21. Four types of network-related information.
How does this apply when the DNS is being used? First, only the host and network information is available through the DNS. The protocol and service information is always read from the corresponding file. We mentioned earlier in this chapter (with Figure 11.1) that different
Second, if the DNS is being used for the host and network information, then only the keyed lookup functions make sense. You cannot, for example, use gethostent and expect to sequence through all entries in the DNS! If gethostent is called, it reads only the /etc/hosts file and avoids the DNS.