From Fedora Project Wiki
 
(68 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Domain Name System ==
== Overview ==


=== Resolving using <code>getaddrinfo()</code> in applications ===
Name resolution topics:
 
* [[/DNS]]
* [[/DNSSEC]]
 
Host and services are often called by names which need to be translated to IP addresses and port numbers.
 
Input arguments:
 
* node
* service
* filters (address family, socktype, protocol)
* flags
 
On output, we expect a list of address records that can be used for connection and other purposes, each consisting of the following fields:
 
* address family and data (network layer)
* protocol and port (transport layer)
* socktype (mode of operation)
 
Additional information can be provided:
 
* canonical name
 
== Use cases ==
 
* Generic translation between hostnames and IP addresses (e.g. for ACL purposes)
* Preparing for connect() or sendto() to contact a service
* Preparing for bind() to provide a service
 
== Name resolution methods ==
 
* [[Networking/NameResolution/Hosts|files (/etc/hosts)]]
* [[Networking/NameResolution/Hosts|myhostname]]
* [[Networking/NameResolution/DNS|DNS]]
* [[Networking/NameResolution/mDNS|mDNS]]
 
== Using getaddrinfo() ==
 
=== Connecting to services using <code>getaddrinfo()</code> ===


The <code>getaddrinfo()</code> function is a dualstack-friendly API to name
The <code>getaddrinfo()</code> function is a dualstack-friendly API to name
resolution. It is used by applications to translate host and
resolution. It is used by applications to translate host and
service names to a linked list of <code>struct addrinfo</code>
service names to a linked list of <code>struct addrinfo</code>
objects.
objects. It has its own manual page <code>getaddrinfo(3)</code> in the Linux
Programmer's Manual.


==== Running <code>getaddrinfo()</code> ====
==== Running <code>getaddrinfo()</code> ====
Line 17: Line 57:
struct addrinfo hints = {
struct addrinfo hints = {
     .ai_family = AF_UNSPEC,
     .ai_family = AF_UNSPEC,
     .ai_socktype = SOCK_DGRAM,
     .ai_socktype = SOCK_STREAM,
     .ai_flags = 0,
     .ai_protocol = IPPROTO_TCP,
     .ai_protocol = 0,
     .ai_flags = AI_ADDRCONFIG,
     .ai_canonname = NULL,
     .ai_canonname = NULL,
     .ai_addr = NULL,
     .ai_addr = NULL,
Line 36: Line 76:
* ''service'': numeric port number or a symbolic service name
* ''service'': numeric port number or a symbolic service name
* ''hints.ai_family'': enable dualprotocol, IPv4-only or IPv6-only queries
* ''hints.ai_family'': enable dualprotocol, IPv4-only or IPv6-only queries
* ''hints.ai_socktype'': select socket type (and thus protocol family)
* ''hints.ai_socktype'': select socket type
* ''hints.ai_protocol'': select transport protocol


<code>getaddrinfo()</code> can be futher tweaked with the ''hints.ai_flags''. Other
Socktype and protocol are somewhat duplicate for TCP/IP stack with just TCP
attributes are either not needed (''ai_protocol'') or not supposed
and UDP. <code>getaddrinfo()</code> can be futher tweaked with the ''hints.ai_flags''.
to be set in hints (''ai_canonname'', ''ai_addr'' and ''ai_next'').
Other attributes are not supposed to be set in hints (''ai_canonname'', ''ai_addr'' and ''ai_next'').


On success, the ''error'' variable is assigned to 0 and ''result'' is pointed to
On success, the ''error'' variable is assigned to 0 and ''result'' is pointed to
Line 98: Line 139:
service = "http"
service = "http"
family = socket.AF_UNSPEC
family = socket.AF_UNSPEC
socktype = socket.SOCK_DGRAM
socktype = socket.SOCK_STREAM
protocol = 0
protocol = socket.SOL_TCP
flags = 0
flags = 0


Line 130: Line 171:
* AI_NUMERICSERV: use numeric service, don't perform service resolution
* AI_NUMERICSERV: use numeric service, don't perform service resolution
* AI_CANONNAME: save canonical name to the first result
* AI_CANONNAME: save canonical name to the first result
* AI_ADDRCONFIG: this never really worked, as far as I know
* AI_ADDRCONFIG: to be used with connect(), this never really worked, as far as I know, but [[Networking/NameResolution/ADDRCONFIG|we want to fix it]]
* AI_V4MAPPED+AI_ALL: only with AF_INET6, return IPv4 addresses mapped into IPv6 space
* AI_V4MAPPED+AI_ALL: only with AF_INET6, return IPv4 addresses mapped into IPv6 space
* AI_V4MAPPED: I don't see any real use for this, only returns mapped IPv4 if there are no IPv6 addresses
* AI_V4MAPPED: I don't see any real use for this, only returns mapped IPv4 if there are no IPv6 addresses


==== AI_ADDRCONFIG considered harmful ====
==== Connecting to multiple transport channels ====
 
Some applications need to open several TCP or UDP channels to the same host. The
classic usage of <code>getaddrinfo()</code> returns a linked list of addrinfo
objects for just one channel.
 
Solutions:
 
1) Run <code>getaddrinfo()</code> once per channel. This may for example cause
multiple DNS requests for the same information, which is suboptimal
 
2) Run <code>getaddrinfo()</code> only for the main (or first) channel. When
connection succeeds, reuse the addrinfo structure for the other channels. It
is usually safe to assume that when one channel succeeds, the machine is
available for the other channels, too.
 
An example of such an application is Spice. Thanks to David Jaša for information
on this subject.
 
=== Binding to addresses using <code>getaddrinfo()</code> ===
 
According to the manual page, you should use AI_PASSIVE flag when
you use <code>getaddrinfo()</code> to retrieve addresses to
<code>bind()</code> to. Those are usually stored as user configuration
with NULL being the default value.
 
<code>getaddrinfo()</code> returns a linked list of addrinfo structures.
Developers should not generally assume that it only returns one address
nor that the first address is the best and only one to <code>bind()</code> to.
 
The general idea is that one would loop through <code>getaddrinfo()</code>
structure and <code>bind()</code> one socket to each of them. But this doesn't work
in general. Read on.
 
==== Binding to the INADDR_ANY and/or in6addr_any addresses ====
 
This is the most common option that doesn't limit the service to
a particular set of local addresses.
 
<code>getaddrinfo(NULL, ...)</code> with AI_PASSIVE returns two addresses,
<code>0.0.0.0</code> and <code>::</code>, in this order. If you use
the general rule above, the resulting actions would look like:
 
<pre>
sock1 = socket(AF_INET, SOCK_STREAM, SOL_TCP)
bind(sock1, INADDR_ANY, sizeof (INADDR_ANY))
...
sock2 = socket(AF_INET6, SOCK_STREAM, SOL_TCP)
bind(sock2, in6addr_any, sizeof (in6addr_any))
...
</pre>
 
This won't work. The first <code>bind()</code> will successfully bind
to 0.0.0.0, while the second tries to <code>bind()</code> in a dualstack
manner, taking both <code>::</code> and <code>0.0.0.0</code> (unless
sysctl net.ipv6.bindv6only is enabled) and therefore it will fail
as <code>0.0.0.0</code> is already taken.
 
The addresses are obviously returned in different order than usual
(IPv4 first) and that should probably be fixed in glibc. But even
if it's fixed, it only changes the order of the actions:
 
<pre>
sock1 = socket(AF_INET6, SOCK_STREAM, SOL_TCP)
bind(sock1, in6addr_any, sizeof (in6addr_any))
...
sock2 = socket(AF_INET, SOCK_STREAM, SOL_TCP)
bind(sock2, INADDR_ANY, sizeof (INADDR_ANY))
...
</pre>
 
The first socket succeeds and binds to both addresses. The second one
fails. If the application ignores (or only warns about) the second failure,
it would work without problem.
 
The correct™ way to handle this with <code>getaddrinfo()</code> would be
to prevent the linux kernel from using the ''dualstack hack'' with the
<code>setsockopt()</code> call (yes is an int constant that equeals 1).
 
<pre>
sock1 = socket(AF_INET6, SOCK_STREAM, SOL_TCP)
setsockopt(sock1, IPPROTO_IPV6, IPV6_V6ONLY, &yes, sizeof(yes))
bind(sock1, in6addr_any, sizeof (in6addr_any))
...
sock2 = socket(AF_INET, SOCK_STREAM, SOL_TCP)
bind(sock2, INADDR_ANY, sizeof (INADDR_ANY))
...
</pre>
 
After writing this, I found [http://funcptr.net/2012/08/07/ipv6----getaddrinfo%28%29-and-bind%28%29-ordering-with-v6only/ a resource] from Bert JW Regeer on the same subject.
 
==== Binding to specific addresses by number ====
 
This works well because in this case only one address is ever returned
(if ''socktype'' and ''protocol'' are specified). It is possible
to limit <code>getaddrinfo()</code> to this case using the
AI_NUMERICHOST flag. AI_PASSIVE flag is not used in this case.
 
==== Binding to a list of specific addresses by hostname ====
 
This is just <code>getaddrinfo()</code> resolving. The AI_PASSIVE
flag is not used in this case. Always remember that <code>getaddrinfo()</code>
returns a linked list of addresses. If you support binding by name,
you should always create one socket for each address and <code>bind()</code>
it.
 
==== Proposed solutions ====
 
1) Only support listening on all addresses. Always <code>bind()</code>
to the IPv6 address in dualstack mode.
 
<pre>
sock1 = socket(AF_INET6, SOCK_STREAM, SOL_TCP)
bind(sock1, in6addr_any, sizeof (in6addr_any))
...
</pre>
 
2) Use only numeric addresses and NULL setting. Special case NULL
setting and solve them separately with #1. Only then, if you use
AI_NUMERICHOST and properly
specify the ''socktype'' and/or ''protocol'' fields, you can assume
that <code>getaddrinfo()</code> only returns one result.
 
If result order is fixed in glibc, you wouldn't actually have to special
case the NULL host. But it's more of a hack.
 
3) Support full name resolution. Always create one socket per
resulting address. Set IPV6_V6ONLY on IPv6 sockets to suppres the
transparent dualstack. This works for all cases.
 
There are many other possibilities that seem to work at first glance
but don't behave as expected in many situations.
 
==== Testing code (in Python for simplicity) ====
 
The following test shows how it works:
 
getaddrinfo-test-ai-passive.py:
 
<pre>
#!/usr/bin/python3
from socket import *
hosts = [
    None,
    "localhost",
    "info.nix.cz",
    "www.google.com",
]
for host in hosts:
    print(host)
    for item in getaddrinfo(host, "http", AF_UNSPEC, SOCK_STREAM, SOL_TCP, AI_PASSIVE):
        print("  ", item)
</pre>
 
<pre>
# ./getaddrinfo-test-ai-passive.py
None
  (2, 1, 6, '', ('0.0.0.0', 80))
  (10, 1, 6, '', ('::', 80, 0, 0))
localhost
  (10, 1, 6, '', ('::1', 80, 0, 0))
  (2, 1, 6, '', ('127.0.0.1', 80))
info.nix.cz
  (10, 1, 6, '', ('2a02:38::1001', 80, 0, 0))
  (2, 1, 6, '', ('195.47.235.3', 80))
www.google.com
  (10, 1, 6, '', ('2a00:1450:4016:801::1012', 80, 0, 0))
  (2, 1, 6, '', ('173.194.35.144', 80))
  (2, 1, 6, '', ('173.194.35.145', 80))
  (2, 1, 6, '', ('173.194.35.147', 80))
  (2, 1, 6, '', ('173.194.35.148', 80))
  (2, 1, 6, '', ('173.194.35.146', 80))
</pre>
 
You can clearly see the reversed order for NULL host and multiple results
for hostnames. You can further improve the code with creation and
binding of the sockets.
 
=== Using <code>getaddrinfo()</code> for accesslists ===
 
Some software uses addresses where you can put addresses, hostnames or more
sophisticated filters based on them. Names can be resolved at configuration
time or at check time.
 
Various hosts are connecting to the hostname using IPv4 and IPv6 addresses. Whenever
the administrator uses a hostname in the accesslist, the hostname must point to
all addresses that can be used for the connection.
 
On the other hand, when the administrator puts addresses to the accesslist, he must
put ''all'' possible addresses there, otherwise an unpleasant surprise awaits him
when the host connects using an address that is not in the ACL.
 
''localhost'' is a special case that, on most current distributions resolves to <code>::1</code>
and <code>127.0.0.1</code>, in this order. This is usually only driven by the /etc/hosts configuration file, except the list is reordered by <code>getaddrinfo()</code>.
 
<pre>
127.0.0.1  localhost localhost.localdomain localhost4 localhost4.localdomain4
::1        localhost localhost.localdomain localhost6 localhost6.localdomain6
</pre>
 
For example, when a service has <code>127.0.0.1</code> in the accesslist, it is
illegal to try to connect to it over <code>::1</code>. But that's the first address
<code>getaddrinfo("localhost", ...)</code> returns. This is a configuration problem
but even many administrators skilled in IP networking won't realize that
<code>localhost</code> is not identical to <code>127.0.0.1</code>.
 
==== Proposed solutions ====
 
1) Make administrators fix their configurations. Tell them about the breakage
of identity between "localhost" and "127.0.0.1".
 
2) Workaround: Change client behavior on ''access denied'' error from server and treat
it as a network error. Always try other addresses from the list returned by
<code>getaddrinfo()</code>.
 
3) Workaround: Prefer <code>127.0.0.1</code> over <code>::1</code>. This assumes that
anyone putting <code>::1</code> in an access list knows what he's doing.
 
=== Flag AI_ADDRCONFIG considered harmful ===
 
Current implementation of AI_ADDRCONFIG flag is a source problems and confusion. Detailed description of the problem was moved to a separate article: [[Networking/NameResolution/ADDRCONFIG|Flag AI_ADDRCONFIG considered harmful]].
 
=
 
=== Comments and discussion ===


Filtering of non-DNS addresses in getaddrinfo() has no real use
Please send any remarks and questions to psimerda-at-redhat-dot-com or use [[Talk:Networking]]. Edit with care.
and it only causes problems. There's no reason to filter over the
mere existence of addresses. Filtering over global address existence
may only be desirable for global address resolution, which is DNS. But
that should be done by the DNS resolver that only asks for addresses
that make sense and only accepts addresses that it asks for.

Latest revision as of 09:59, 8 October 2015

Overview

Name resolution topics:

Host and services are often called by names which need to be translated to IP addresses and port numbers.

Input arguments:

  • node
  • service
  • filters (address family, socktype, protocol)
  • flags

On output, we expect a list of address records that can be used for connection and other purposes, each consisting of the following fields:

  • address family and data (network layer)
  • protocol and port (transport layer)
  • socktype (mode of operation)

Additional information can be provided:

  • canonical name

Use cases

  • Generic translation between hostnames and IP addresses (e.g. for ACL purposes)
  • Preparing for connect() or sendto() to contact a service
  • Preparing for bind() to provide a service

Name resolution methods

Using getaddrinfo()

Connecting to services using getaddrinfo()

The getaddrinfo() function is a dualstack-friendly API to name resolution. It is used by applications to translate host and service names to a linked list of struct addrinfo objects. It has its own manual page getaddrinfo(3) in the Linux Programmer's Manual.

Running getaddrinfo()

And example of getaddrinfo() call:

const char *node = "www.fedoraproject.org";
const char *service = "http";
struct addrinfo hints = {
    .ai_family = AF_UNSPEC,
    .ai_socktype = SOCK_STREAM,
    .ai_protocol = IPPROTO_TCP,
    .ai_flags = AI_ADDRCONFIG,
    .ai_canonname = NULL,
    .ai_addr = NULL,
    .ai_next = NULL
};
struct addrinfo *result;
int error;

error = getaddrinfo(node, service, &hints, &result);

The input of getaddrinfo() consists of node specification, service specification and further hints.

  • node: literal IPv4 or IPv6 address, or a hostname to be resolved
  • service: numeric port number or a symbolic service name
  • hints.ai_family: enable dualprotocol, IPv4-only or IPv6-only queries
  • hints.ai_socktype: select socket type
  • hints.ai_protocol: select transport protocol

Socktype and protocol are somewhat duplicate for TCP/IP stack with just TCP and UDP. getaddrinfo() can be futher tweaked with the hints.ai_flags. Other attributes are not supposed to be set in hints (ai_canonname, ai_addr and ai_next).

On success, the error variable is assigned to 0 and result is pointed to a linked list of one or more struct addrinfo objects.

Never assume that getaddrinfo() returns only one result or that the first result actually works!

Using getaddrinfo() results

It is necesary to try all results until one successfully connects. This works perfectly for TCP connections as they can fail gracefully at this stage.

struct addrinfo *item;
int sock;

for (item = result; item; item = item->ai_next) {
    sock = socket(item->ai_family, item->ai_socktype, item->ai_protocol);

    if (sock == -1)
        continue;

    if (connect(sock, item->ai_addr, item->ai_addrlen) != -1) {
        fprintf(stderr, "Connected successfully.");
        break;
    }

    close(sock);
}

For UDP, connect() succeeds without contacting the other side (if you are using connect() with udp at all). Therefore you might want to perform additional actions (such as sending a message and recieving a reply) before crying out „success!“.

Freeing getaddrinfo() results

When we're done with the results, we'll free the linked list.

freeaddrinfo(result);

Using getaddrinfo() in Python

Python's socket.getaddrinfo() API tries to be a little bit more sane than the C API.

#!/usr/bin/python3

import sys, socket

host = "www.fedoraproject.org"
service = "http"
family = socket.AF_UNSPEC
socktype = socket.SOCK_STREAM
protocol = socket.SOL_TCP
flags = 0

result = socket.getaddrinfo(host, service, family, socktype, protocol, flags)

sock = None
for family, socktype, protocol, canonname, sockaddr in result:
    try:
        sock = socket.socket(family, socktype, protocol)
    except socket.error:
        continue
    try:
        sock.connect(sockaddr)
        print("Successfully connected to: {}".format(sockaddr))
    except socket.error:
        sock.close()
        sock = None
        continue
    break

if sock is None:
    print("Failed to connect.", file=sys.stderr)
    sys.exit(1)

Tweaking getaddrinfo() flags

  • AI_NUMERICHOST: use literal address, don't perform host resolution
  • AI_PASSIVE: return socket addresses suitable for bind() instead of connect(), sendto() and sendmsg()
  • AI_NUMERICSERV: use numeric service, don't perform service resolution
  • AI_CANONNAME: save canonical name to the first result
  • AI_ADDRCONFIG: to be used with connect(), this never really worked, as far as I know, but we want to fix it
  • AI_V4MAPPED+AI_ALL: only with AF_INET6, return IPv4 addresses mapped into IPv6 space
  • AI_V4MAPPED: I don't see any real use for this, only returns mapped IPv4 if there are no IPv6 addresses

Connecting to multiple transport channels

Some applications need to open several TCP or UDP channels to the same host. The classic usage of getaddrinfo() returns a linked list of addrinfo objects for just one channel.

Solutions:

1) Run getaddrinfo() once per channel. This may for example cause multiple DNS requests for the same information, which is suboptimal

2) Run getaddrinfo() only for the main (or first) channel. When connection succeeds, reuse the addrinfo structure for the other channels. It is usually safe to assume that when one channel succeeds, the machine is available for the other channels, too.

An example of such an application is Spice. Thanks to David Jaša for information on this subject.

Binding to addresses using getaddrinfo()

According to the manual page, you should use AI_PASSIVE flag when you use getaddrinfo() to retrieve addresses to bind() to. Those are usually stored as user configuration with NULL being the default value.

getaddrinfo() returns a linked list of addrinfo structures. Developers should not generally assume that it only returns one address nor that the first address is the best and only one to bind() to.

The general idea is that one would loop through getaddrinfo() structure and bind() one socket to each of them. But this doesn't work in general. Read on.

Binding to the INADDR_ANY and/or in6addr_any addresses

This is the most common option that doesn't limit the service to a particular set of local addresses.

getaddrinfo(NULL, ...) with AI_PASSIVE returns two addresses, 0.0.0.0 and ::, in this order. If you use the general rule above, the resulting actions would look like:

sock1 = socket(AF_INET, SOCK_STREAM, SOL_TCP)
bind(sock1, INADDR_ANY, sizeof (INADDR_ANY))
...
sock2 = socket(AF_INET6, SOCK_STREAM, SOL_TCP)
bind(sock2, in6addr_any, sizeof (in6addr_any))
...

This won't work. The first bind() will successfully bind to 0.0.0.0, while the second tries to bind() in a dualstack manner, taking both :: and 0.0.0.0 (unless sysctl net.ipv6.bindv6only is enabled) and therefore it will fail as 0.0.0.0 is already taken.

The addresses are obviously returned in different order than usual (IPv4 first) and that should probably be fixed in glibc. But even if it's fixed, it only changes the order of the actions:

sock1 = socket(AF_INET6, SOCK_STREAM, SOL_TCP)
bind(sock1, in6addr_any, sizeof (in6addr_any))
...
sock2 = socket(AF_INET, SOCK_STREAM, SOL_TCP)
bind(sock2, INADDR_ANY, sizeof (INADDR_ANY))
...

The first socket succeeds and binds to both addresses. The second one fails. If the application ignores (or only warns about) the second failure, it would work without problem.

The correct™ way to handle this with getaddrinfo() would be to prevent the linux kernel from using the dualstack hack with the setsockopt() call (yes is an int constant that equeals 1).

sock1 = socket(AF_INET6, SOCK_STREAM, SOL_TCP)
setsockopt(sock1, IPPROTO_IPV6, IPV6_V6ONLY, &yes, sizeof(yes))
bind(sock1, in6addr_any, sizeof (in6addr_any))
...
sock2 = socket(AF_INET, SOCK_STREAM, SOL_TCP)
bind(sock2, INADDR_ANY, sizeof (INADDR_ANY))
...

After writing this, I found a resource from Bert JW Regeer on the same subject.

Binding to specific addresses by number

This works well because in this case only one address is ever returned (if socktype and protocol are specified). It is possible to limit getaddrinfo() to this case using the AI_NUMERICHOST flag. AI_PASSIVE flag is not used in this case.

Binding to a list of specific addresses by hostname

This is just getaddrinfo() resolving. The AI_PASSIVE flag is not used in this case. Always remember that getaddrinfo() returns a linked list of addresses. If you support binding by name, you should always create one socket for each address and bind() it.

Proposed solutions

1) Only support listening on all addresses. Always bind() to the IPv6 address in dualstack mode.

sock1 = socket(AF_INET6, SOCK_STREAM, SOL_TCP)
bind(sock1, in6addr_any, sizeof (in6addr_any))
...

2) Use only numeric addresses and NULL setting. Special case NULL setting and solve them separately with #1. Only then, if you use AI_NUMERICHOST and properly specify the socktype and/or protocol fields, you can assume that getaddrinfo() only returns one result.

If result order is fixed in glibc, you wouldn't actually have to special case the NULL host. But it's more of a hack.

3) Support full name resolution. Always create one socket per resulting address. Set IPV6_V6ONLY on IPv6 sockets to suppres the transparent dualstack. This works for all cases.

There are many other possibilities that seem to work at first glance but don't behave as expected in many situations.

Testing code (in Python for simplicity)

The following test shows how it works:

getaddrinfo-test-ai-passive.py:

#!/usr/bin/python3
from socket import *
hosts = [
    None,
    "localhost",
    "info.nix.cz",
    "www.google.com",
]
for host in hosts:
    print(host)
    for item in getaddrinfo(host, "http", AF_UNSPEC, SOCK_STREAM, SOL_TCP, AI_PASSIVE):
        print("  ", item)
# ./getaddrinfo-test-ai-passive.py
None
   (2, 1, 6, '', ('0.0.0.0', 80))
   (10, 1, 6, '', ('::', 80, 0, 0))
localhost
   (10, 1, 6, '', ('::1', 80, 0, 0))
   (2, 1, 6, '', ('127.0.0.1', 80))
info.nix.cz
   (10, 1, 6, '', ('2a02:38::1001', 80, 0, 0))
   (2, 1, 6, '', ('195.47.235.3', 80))
www.google.com
   (10, 1, 6, '', ('2a00:1450:4016:801::1012', 80, 0, 0))
   (2, 1, 6, '', ('173.194.35.144', 80))
   (2, 1, 6, '', ('173.194.35.145', 80))
   (2, 1, 6, '', ('173.194.35.147', 80))
   (2, 1, 6, '', ('173.194.35.148', 80))
   (2, 1, 6, '', ('173.194.35.146', 80))

You can clearly see the reversed order for NULL host and multiple results for hostnames. You can further improve the code with creation and binding of the sockets.

Using getaddrinfo() for accesslists

Some software uses addresses where you can put addresses, hostnames or more sophisticated filters based on them. Names can be resolved at configuration time or at check time.

Various hosts are connecting to the hostname using IPv4 and IPv6 addresses. Whenever the administrator uses a hostname in the accesslist, the hostname must point to all addresses that can be used for the connection.

On the other hand, when the administrator puts addresses to the accesslist, he must put all possible addresses there, otherwise an unpleasant surprise awaits him when the host connects using an address that is not in the ACL.

localhost is a special case that, on most current distributions resolves to ::1 and 127.0.0.1, in this order. This is usually only driven by the /etc/hosts configuration file, except the list is reordered by getaddrinfo().

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

For example, when a service has 127.0.0.1 in the accesslist, it is illegal to try to connect to it over ::1. But that's the first address getaddrinfo("localhost", ...) returns. This is a configuration problem but even many administrators skilled in IP networking won't realize that localhost is not identical to 127.0.0.1.

Proposed solutions

1) Make administrators fix their configurations. Tell them about the breakage of identity between "localhost" and "127.0.0.1".

2) Workaround: Change client behavior on access denied error from server and treat it as a network error. Always try other addresses from the list returned by getaddrinfo().

3) Workaround: Prefer 127.0.0.1 over ::1. This assumes that anyone putting ::1 in an access list knows what he's doing.

Flag AI_ADDRCONFIG considered harmful

Current implementation of AI_ADDRCONFIG flag is a source problems and confusion. Detailed description of the problem was moved to a separate article: Flag AI_ADDRCONFIG considered harmful.

=

Comments and discussion

Please send any remarks and questions to psimerda-at-redhat-dot-com or use Talk:Networking. Edit with care.