Proposed F19 Feature: DualstackNetworking - proper dual stack IPv4 and IPv6 networking

[Jaroslav Reznik]

As decided by FESCo on 2012-12-05 meeting, all proposed Features are required
to pass through the community review by announcing them on devel-announce list.
FESCo votes on new features no sooner than a week from the announcement.

= Features/DualstackNetworking =
https://fedoraproject.org/wiki/Features/DualstackNetworking

* Detailed description
Fedora supports dualstack global networking. That means the computer with
Fedora is connected to internet using both IPv4 and IPv6 protocols. But many 
important system services and applications either don't do IPv6, do it 
incorrectly, or don't cope with various network conditions.

Unfortunately, while trying to improve IPv6 support, some IPv4 use cases became 
broken as well. That's why the goal of this feature is not only to support IPv4,
but to support all possible real-world cases.

Dualstack-ready software must cope with all possible scenarios including 
IPv4-only connectivity, IPv6-only connectivity and dual connectivity. 
The software must also cope with node-local (aka localhost) networking, which 
as been used by software for decades.

Though it would be nice to have all applications in Fedora fixed to work in 
any of the scenarios, it is not feasible to test that. Therefore this feature
is about major software used in servers, desktops and laptops. The list of such
applications will be completed over the time.

Bugs related to dualstack networking should be added to the following tracker 
bug:

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

Also see: https://bugzilla.redhat.com/show_bug.cgi?id=ipv6blocker 
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Miloslav Trmač]

On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  = Features/DualstackNetworking =
>  https://fedoraproject.org/wiki/Features/DualstackNetworking 
(Sending to the list instead of using the wiki talk page to hopefully
gather more information from networking experts.  The recent-ish
bugzilla activity in this space does suggest that this is a good topic
to revisit in detail, thanks for taking the effort on.)

1. So what is the _precise_ scope of the ''proposed feature''?  For
example, does "glibc: name resolution must work properly" mean that
you have some specific proposals to change glibc?

(https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG
suggests changing glibc as one of the options.  Have you decided which
option you propose?  In general, glibc maintainers' signoff or at
least significant discussion would probably be required for any glibc
change of this kind.  FWIW, historically it was recommended to have
AI_ADDRCONFIG enabled, see
http://www.akkadia.org/drepper/userapi-ipv6.html .)

2. We already have a guideline requiring IPv6
(https://fedoraproject.org/wiki/Packaging:Guidelines?rd=PackagingGuideline...
); to the extent that this feature would propose specific ways to use
the API, the packaging guideline should point to documentation that
describes the correct way.  It would be great to get a wide review of
the proposed approach before any extensive effort to modify many
packages starts.
    Mirek

[William]

On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote: 
>  On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik
> <jreznik(a)redhat.com&gt; wrote:
>  > = Features/DualstackNetworking =
>  > https://fedoraproject.org/wiki/Features/DualstackNetworking 
I think that this is a really good goal. I can identify the following
that probably need work as part of this to improve the user experience.

1) For a user, there is no option in NetworkManager to enable dhcp6c
from the gui. By Default, this option is "not listed" in ifcfg-ethX,
even as a DHCP6C=no, making it hard to find and enable. 

2) Privacy extensions still has no UI to enable / disable from
NetworkManager.

3) dhclient prefix delegation often has issues on pppoe sessions,
meaning that you will often get the pppoe session dropping out, ipv4
will recover correctly, but ipv6 will not re-request a prefix until some
timeout, usually an hour, in which time all ipv6 services are
unavailable. This causes DNS timeouts, webpages to respond slowly, email
accounts to not fetch etc. 

4) For link local to work "nicely", mDNS name resolution should be
installed and available by default. Avahi can provide such a service for
ipv6. 


Perhaps a good way to test this, would be to try and run a system or
network as "ipv6 only", as that will quickly identify short comings of
the system. 


-- 
Sincerely,

William Brown

pgp.mit.edu
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2

[Tomasz Torcz]

On Thu, Jan 03, 2013 at 08:18:19AM +1030, William Brown wrote:
>  > > = Features/DualstackNetworking =
>  > > https://fedoraproject.org/wiki/Features/DualstackNetworking
>  
>  1) For a user, there is no option in NetworkManager to enable dhcp6c
>  from the gui. By Default, this option is "not listed" in ifcfg-ethX,
>  even as a DHCP6C=no, making it hard to find and enable. 
>  
>  2) Privacy extensions still has no UI to enable / disable from
>  NetworkManager.
>  
>  3) dhclient prefix delegation often has issues on pppoe sessions, 
  Does NetworkManager request prefix delegation nowadays? It wasn't
a year ago - https://bugzilla.redhat.com/show_bug.cgi?id=754086

-- 
Tomasz Torcz                 Morality must always be based on practicality.
xmpp: zdzichubg(a)chrome.pl                -- Baron Vladimir Harkonnen

[Pavel Simerda]

----- Original Message -----
>  From: "Tomasz Torcz" <tomek(a)pipebreaker.pl&gt;
>  On Thu, Jan 03, 2013 at 08:18:19AM +1030, William Brown wrote:
>  > > > = Features/DualstackNetworking =
>  > > > https://fedoraproject.org/wiki/Features/DualstackNetworking
>  > 
>  > 1) For a user, there is no option in NetworkManager to enable
>  > dhcp6c 
It's started as a reaction to AdvManagedFlag or AdvOtherConfigFlag in router
advertisements, as mandated by the RFCs.

>  > from the gui. By Default, this option is "not listed"
> in
>  > ifcfg-ethX,
>  > even as a DHCP6C=no, making it hard to find and enable. 
Don't use that.

>  > 2) Privacy extensions still has no UI to enable / disable from
>  > NetworkManager. 
Out of scope of this Feature. But might be suitable for:

https://fedoraproject.org/wiki/Features/NetworkManagerAdvancedIPv6

Probably worth a bug report on gnome-control-center.

>  > 3) dhclient prefix delegation often has issues on pppoe
> sessions, 
Out of scope. No information about that. This would probably need a proper bug report.

>  Does NetworkManager request prefix delegation nowadays? 
IPv6 connection sharing is currently not supported in NetworkManager in any way.

See:

https://bugzilla.gnome.org/show_bug.cgi?id=593815

>  It wasn't
>  a year ago - https://bugzilla.redhat.com/show_bug.cgi?id=754086
>  
>  --
>  Tomasz Torcz                 Morality must always be based on
>  practicality.
>  xmpp: zdzichubg(a)chrome.pl                -- Baron Vladimir Harkonnen
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Peter Robinson]

On Wed, Jan 2, 2013 at 9:48 PM, William Brown <william(a)firstyear.id.au&gt; wrote:
>  On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote:
> > On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
> > > = Features/DualstackNetworking =
> > > https://fedoraproject.org/wiki/Features/DualstackNetworking
>
>  I think that this is a really good goal. I can identify the following
>  that probably need work as part of this to improve the user experience.
>
>  1) For a user, there is no option in NetworkManager to enable dhcp6c
>  from the gui. By Default, this option is "not listed" in ifcfg-ethX,
>  even as a DHCP6C=no, making it hard to find and enable.
>
>  2) Privacy extensions still has no UI to enable / disable from
>  NetworkManager.
>
>  3) dhclient prefix delegation often has issues on pppoe sessions,
>  meaning that you will often get the pppoe session dropping out, ipv4
>  will recover correctly, but ipv6 will not re-request a prefix until some
>  timeout, usually an hour, in which time all ipv6 services are
>  unavailable. This causes DNS timeouts, webpages to respond slowly, email
>  accounts to not fetch etc. 
There's also other issues with NM and ppp/pppoe with IPv6. In the
service provider space this side of IPv6 is still a moving target with
some standards evolving to enable ISPs to push IPv6 subnets out to
consumer routers and the like. There's still bugs like [1] to resolve
in NM, I know it's closed but that was to open individual bugs and I
think there's some bits left to do to properly deal with RFC 5072 for
v6 over ppp.

Peter

[1] https://bugzilla.gnome.org/show_bug.cgi?id=593813

[William]

On Thu, 2013-01-03 at 00:01 +0000, Peter Robinson wrote: 
>  On Wed, Jan 2, 2013 at 9:48 PM, William Brown
> <william(a)firstyear.id.au&gt; wrote:
>  > On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote:
>  >> On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt;
> wrote:
>  >> > = Features/DualstackNetworking =
>  >> > https://fedoraproject.org/wiki/Features/DualstackNetworking
>  >
>  > I think that this is a really good goal. I can identify the following
>  > that probably need work as part of this to improve the user experience.
>  >
>  > 1) For a user, there is no option in NetworkManager to enable dhcp6c
>  > from the gui. By Default, this option is "not listed" in ifcfg-ethX,
>  > even as a DHCP6C=no, making it hard to find and enable.
>  >
>  > 2) Privacy extensions still has no UI to enable / disable from
>  > NetworkManager.
>  >
>  > 3) dhclient prefix delegation often has issues on pppoe sessions,
>  > meaning that you will often get the pppoe session dropping out, ipv4
>  > will recover correctly, but ipv6 will not re-request a prefix until some
>  > timeout, usually an hour, in which time all ipv6 services are
>  > unavailable. This causes DNS timeouts, webpages to respond slowly, email
>  > accounts to not fetch etc.
>  
>  There's also other issues with NM and ppp/pppoe with IPv6. In the
>  service provider space this side of IPv6 is still a moving target with
>  some standards evolving to enable ISPs to push IPv6 subnets out to
>  consumer routers and the like. There's still bugs like [1] to resolve
>  in NM, I know it's closed but that was to open individual bugs and I
>  think there's some bits left to do to properly deal with RFC 5072 for
>  v6 over ppp.
>  
>  Peter
>  
>  [1] https://bugzilla.gnome.org/show_bug.cgi?id=593813 
I don't necessarily mean that NM should support PD for ppp interfaces,
more that "some parts" of the whole IPv6 experience still need work for
them to operate correctly. 

However, saying that, it would be lovely if in my ifcfg-ppp I could just
add a "DHCP6C-PD" option or the like, and have it work .... 



However, as others have said, the "scope" of this work should be
defined. How will the "outcomes" be assessed? It may be a selfish view,
but I would like to suggest that a good goal would be for a fedora
machine to act as a ipv4 and ipv6 router with PD (and minimal fuss), as
well as providing ipv4 and ipv6 services such as radvd, dhcp and dhcp6.
These services should probably be defined as well. As already stated, a
good goal would be to try having an "ipv6 only" system, as this will
quickly highlight many of the issues around ipv6 usage on a network.   

The reason I suggest the "router" is that it is one of the more
'complex' network oriented setups, and will implicitly test basic ipv6
connectivity ie link local, daemons like bind, etc. Perhaps even a
"disconnected" network that relies on link local only?



-- 
Sincerely,

William Brown

pgp.mit.edu
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2

[Pavel Simerda]

----- Original Message -----
>  From: "William Brown" <william(a)firstyear.id.au&gt;
>
>  On Thu, 2013-01-03 at 00:01 +0000, Peter Robinson wrote:
>  > On Wed, Jan 2, 2013 at 9:48 PM, William Brown
>  > <william(a)firstyear.id.au&gt; wrote:
>  > > On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote:
>  > >> On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik
>  > >> <jreznik(a)redhat.com&gt; wrote:
>  > >> > = Features/DualstackNetworking =
>  > >> > https://fedoraproject.org/wiki/Features/DualstackNetworking
>  > >
>  > > I think that this is a really good goal. I can identify the
>  > > following
>  > > that probably need work as part of this to improve the user
>  > > experience.
>  > >
>  > > 1) For a user, there is no option in NetworkManager to enable
>  > > dhcp6c
>  > > from the gui. By Default, this option is "not listed" in
>  > > ifcfg-ethX,
>  > > even as a DHCP6C=no, making it hard to find and enable.
>  > >
>  > > 2) Privacy extensions still has no UI to enable / disable from
>  > > NetworkManager.
>  > >
>  > > 3) dhclient prefix delegation often has issues on pppoe sessions,
>  > > meaning that you will often get the pppoe session dropping out,
>  > > ipv4
>  > > will recover correctly, but ipv6 will not re-request a prefix
>  > > until some
>  > > timeout, usually an hour, in which time all ipv6 services are
>  > > unavailable. This causes DNS timeouts, webpages to respond
>  > > slowly, email
>  > > accounts to not fetch etc.
>  > 
>  > There's also other issues with NM and ppp/pppoe with IPv6. In the
>  > service provider space this side of IPv6 is still a moving target
>  > with
>  > some standards evolving to enable ISPs to push IPv6 subnets out to
>  > consumer routers and the like. There's still bugs like [1] to
>  > resolve
>  > in NM, I know it's closed but that was to open individual bugs and
>  > I
>  > think there's some bits left to do to properly deal with RFC 5072
>  > for
>  > v6 over ppp.
>  > 
>  > Peter
>  > 
>  > [1] https://bugzilla.gnome.org/show_bug.cgi?id=593813
>  
>  I don't necessarily mean that NM should support PD for ppp
>  interfaces,
>  more that "some parts" of the whole IPv6 experience still need work
>  for
>  them to operate correctly.
>  
>  However, saying that, it would be lovely if in my ifcfg-ppp I could
>  just
>  add a "DHCP6C-PD" option or the like, and have it work ....
>  
>  
>  
>  However, as others have said, the "scope" of this work should be
>  defined. 
> From my point of view, it is defined as much as possible. It is all
> about system services and applications that connect, or accept connections over the
> network and, optionally, uses name resolution. 
This is mainly about usage of IP addresses and name resolution.

>  How will the "outcomes" be assessed? It may be a selfish
>  view,
>  but I would like to suggest that a good goal would be for a fedora
>  machine to act as a ipv4 and ipv6 router with PD (and minimal fuss), 
This is out of scope of this feature. But please look at other features
not yet submitted:

https://fedoraproject.org/wiki/Networking#Fedora_feature_pages

Especially:

https://fedoraproject.org/wiki/Features/NetworkManagerAdvancedIPv6

>  as well as providing ipv4 and ipv6 services such as radvd, dhcp and
>  dhcp6. 
These have been tested and work. Major use cases documented here:

https://fedoraproject.org/wiki/Networking/Addressing

>  These services should probably be defined as well. As already
> stated,
>  a
>  good goal would be to try having an "ipv6 only" system, as this will
>  quickly highlight many of the issues around ipv6 usage on a network. 
IPv6-only Fedora also works for me, at least Fedora 17 with the firewalld package
installed.

>  The reason I suggest the "router" is that it is one of the
> more
>  'complex' network oriented setups, and will implicitly test basic
>  ipv6 connectivity 
Unfortunately not. Network testing, and especially IPv6/dualstack testing is much more
complex than just running an IPv6 system. Therefore even having an advanced IPv6 router on
Fedora won't help with that.

Again, please look at:

https://fedoraproject.org/wiki/Features/NetworkManagerAdvancedIPv6

>  ie link local 
When writing this feature, I wasn't brave enough to include link-local. IPv6 zero
configuration networking needs much more work then just fixing a couple of applications
and libraries.

See:

https://fedoraproject.org/wiki/Features/ZeroconfNetworking

>  daemons like bind, etc. 
Bind is a system service and seems to work rather well.

>  Perhaps even a "disconnected" network that relies on link
> local only? 
As above.

Thanks for your feedback,

Pavel Šimerda

[Pavel Simerda]

----- Original Message -----
>  From: "William Brown" <william(a)firstyear.id.au&gt;
>  4) For link local to work "nicely", mDNS name resolution should be
>  installed and available by default. Avahi can provide such a service
>  for ipv6. 
Avahi doesn't work for IPv6 link-local addresses and GLIBC doesn't even allow
nss-mdns to work. This only works with FreeBSD libc and patched Avahi/nss-mdns.

See:

https://bugzilla.redhat.com/show_bug.cgi?id=719178
http://sourceware.org/bugzilla/show_bug.cgi?id=14413

By default, Avahi doesn't work for IPv6 at all, as Lennart swithed it back to
IPv4-only.

https://bugzilla.redhat.com/show_bug.cgi?id=821127

This is what one of the next features will be about:

https://fedoraproject.org/wiki/Features/ZeroconfNetworking

But I can't fix all of that myself and do my regular work in just one release :).

Cheers,

Pavel

[Adam Williamson]

On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote:
>  On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik
> <jreznik(a)redhat.com&gt; wrote:
>  > = Features/DualstackNetworking =
>  > https://fedoraproject.org/wiki/Features/DualstackNetworking
>  
>  (Sending to the list instead of using the wiki talk page to hopefully
>  gather more information from networking experts.  The recent-ish
>  bugzilla activity in this space does suggest that this is a good topic
>  to revisit in detail, thanks for taking the effort on.)
>  
>  1. So what is the _precise_ scope of the ''proposed feature''?  For
Just to second this emotion: I'm very much on the IPv6 train in general,
but it would be very nice if any changes to very sensitive distro
components - glibc, NetworkManager, stuff like that - could be decided
and nailed down *quickly*. I don't mind this being a sort of
'aspirational' feature in general, as it seems to be, but for core stuff
- critpath - it would be very good to have a clearly defined scope well
before we start cutting F19 builds.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Pavel Simerda]

----- Original Message -----
>  From: "Adam Williamson" <awilliam(a)redhat.com&gt;
>  
>  On Wed, 2013-01-02 at 21:06 +0100, Miloslav Trmač wrote:
>  > On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik
>  > <jreznik(a)redhat.com&gt; wrote:
>  > > = Features/DualstackNetworking =
>  > > https://fedoraproject.org/wiki/Features/DualstackNetworking
>  > 
>  > (Sending to the list instead of using the wiki talk page to
>  > hopefully
>  > gather more information from networking experts.  The recent-ish
>  > bugzilla activity in this space does suggest that this is a good
>  > topic
>  > to revisit in detail, thanks for taking the effort on.)
>  > 
>  > 1. So what is the _precise_ scope of the ''proposed feature''?  For
>  
>  Just to second this emotion: I'm very much on the IPv6 train in
>  general,
>  but it would be very nice if any changes to very sensitive distro
>  components - glibc, NetworkManager, stuff like that - could be
>  decided
>  and nailed down *quickly*. I don't mind this being a sort of
>  'aspirational' feature in general, as it seems to be, but for core
>  stuff
>  - critpath - it would be very good to have a clearly defined scope
>  well
>  before we start cutting F19 builds. 
So far I don't intend any modifications to NetworkManager in scope of this feature,
except maybe address configuration format which has already been done.

I am working on thorough modifications to glibc's getaddrinfo, though. It
unfortunately proved to fail in many ways. This is the main priority of the feature,
followed by utility libraries (likeglib), and client and server applications.

Any help with clarification appreciated.

Cheers,

Pavel

[Pavel Simerda]

----- Original Message -----
>  From: "Miloslav Trmač" <mitr(a)volny.cz&gt;
>  
>  On Wed, Jan 2, 2013 at 7:59 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt;
>  wrote:
>  > = Features/DualstackNetworking =
>  > https://fedoraproject.org/wiki/Features/DualstackNetworking
>  
>  (Sending to the list instead of using the wiki talk page to hopefully
>  gather more information from networking experts.  The recent-ish
>  bugzilla activity in this space does suggest that this is a good
>  topic to revisit in detail, thanks for taking the effort on.) 
Thanks!

>  1. So what is the _precise_ scope of the ''proposed
> feature''?  For
>  example, does "glibc: name resolution must work properly" mean that
>  you have some specific proposals to change glibc? 
Yes.

I identified a bunch of problems in glibc and commented on previously identified
problems:

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

Now I'm writing and submitting patches. But it will take time.

>  (https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG
>  suggests changing glibc as one of the options.  Have you decided
>  which
>  option you propose?  In general, glibc maintainers' signoff or at
>  least significant discussion would probably be required for any glibc
>  change of this kind.  FWIW, historically it was recommended to have
>  AI_ADDRCONFIG enabled, see
>  http://www.akkadia.org/drepper/userapi-ipv6.html .) 
It is now pretty clear that we need to do #3 and #4 (in this order) and then start
recommending AI_ADDRCONFIG for connect(), sendto() and other stuff again. But I found more
fundamental problems in getaddrinfo() while playing with the code and while reading
IPv6-related bug reports.

Ulrich's documentation is unfortunately not useful as it was written without practical
IPv6 skills and testing. I recommend to ignore it in favor of the resources on Fedora
Wiki.

>  2. We already have a guideline requiring IPv6
>
> (https://fedoraproject.org/wiki/Packaging:Guidelines?rd=PackagingGuideline...
>  ); to the extent that this feature would propose specific ways to use
>  the API, the packaging guideline should point to documentation that
>  describes the correct way. 
Good point. Specific recommedations that are evolving will be part of this feature.

>  It would be great to get a wide review of the proposed approach
> before any extensive effort to
>  modify many
>  packages starts. 
Actually, it's easier than that.

Most important packages either use getaddrinfo() or are moving towards it. Many of them
(if not most) set AI_ADDRCONFIG. As we are now going to fix AI_ADDRCONFIG to make it
actually useful and not harmful, that would mean only packages that are buggy already
would need fixing.

Thank you for your feedback,

Pavel

[John Reiser]

>  = Features/DualstackNetworking =
>  https://fedoraproject.org/wiki/Features/DualstackNetworking 
I'd like to use ipv6 for my computers,
but my ipv4-only consumer devices (TV, Roku, HVAC, etc.)
and ipv4-because-ipv6-is-buggy devices (mythtv)
must continue to inter-operate to/from/with Fedora.

--

[Reindl Harald]

Am 03.01.2013 02:08, schrieb John Reiser:
> > = Features/DualstackNetworking =
> > https://fedoraproject.org/wiki/Features/DualstackNetworking
>  
>  I'd like to use ipv6 for my computers,
>  but my ipv4-only consumer devices (TV, Roku, HVAC, etc.)
>  and ipv4-because-ipv6-is-buggy devices (mythtv)
>  must continue to inter-operate to/from/with Fedora 
that is what "Dualstack" means

[John Reiser]

On 01/02/2013 05:20 PM, Reindl Harald wrote:
>  Am 03.01.2013 02:08, schrieb John Reiser: 
> > I'd like to use ipv6 for my computers,
> > but my ipv4-only consumer devices (TV, Roku, HVAC, etc.)
> > and ipv4-because-ipv6-is-buggy devices (mythtv)
> > must continue to inter-operate to/from/with Fedora 
>  that is what "Dualstack" means 
Good.  The point is that ipv4 consumer devices explicitly
are part of the deal, and cannot be ignored.  Such devices
tend to persist for several generations, and many cannot
be upgraded.  They don't use Fedora shared libraries.
Luckily most of them require only dhcp4 and http-over-tcp+ipv4,
but their actual implementations which work today in Fedora
must continue to work without change for many releases.
For instance, dual stacking must not change the latencies
of dhcp4.

--

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Jaroslav Reznik]

As the Feature was renamed and the content of Feature has been extended
as requested by FESCo, re-announcing it to the community for re-review.

See https://fedorahosted.org/fesco/ticket/986

= Features/Fix Network Name Resolution =
https://fedoraproject.org/wiki/Features/FixNetworkNameResolution

* Detailed description
Currently the 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.

- Rationale

 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 getaddrinfo() usage
 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 

- Problem statement

 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 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</code> 

 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 

----- Original Message -----
>  As decided by FESCo on 2012-12-05 meeting, all proposed Features are
>  required
>  to pass through the community review by announcing them on
>  devel-announce list.
>  FESCo votes on new features no sooner than a week from the
>  announcement.
>  
>  = Features/DualstackNetworking =
>  https://fedoraproject.org/wiki/Features/DualstackNetworking
>  
>  * Detailed description
>  Fedora supports dualstack global networking. That means the computer
>  with
>  Fedora is connected to internet using both IPv4 and IPv6 protocols.
>  But many
>  important system services and applications either don't do IPv6, do
>  it
>  incorrectly, or don't cope with various network conditions.
>  
>  Unfortunately, while trying to improve IPv6 support, some IPv4 use
>  cases became
>  broken as well. That's why the goal of this feature is not only to
>  support IPv4,
>  but to support all possible real-world cases.
>  
>  Dualstack-ready software must cope with all possible scenarios
>  including
>  IPv4-only connectivity, IPv6-only connectivity and dual connectivity.
>  The software must also cope with node-local (aka localhost)
>  networking, which
>  as been used by software for decades.
>  
>  Though it would be nice to have all applications in Fedora fixed to
>  work in
>  any of the scenarios, it is not feasible to test that. Therefore this
>  feature
>  is about major software used in servers, desktops and laptops. The
>  list of such
>  applications will be completed over the time.
>  
>  Bugs related to dualstack networking should be added to the following
>  tracker
>  bug:
>  
>  http://bugzilla.redhat.com/show_bug.cgi?id=883152
>  
>  Also see: https://bugzilla.redhat.com/show_bug.cgi?id=ipv6blocker
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Sam Varshavchik]

Jaroslav Reznik writes:

>  See https://fedorahosted.org/fesco/ticket/986
>
>  = Features/Fix Network Name Resolution =
>  https://fedoraproject.org/wiki/Features/FixNetworkNameResolution 
Why would this be a Fedora issue or a feature?

Seems to me this falls squarely inside the scope of glibc, and it should be  
taken care of in glibc upstream, rather than in Fedora.

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Pavel Simerda]

>  > = Features/Fix Network Name Resolution =
>  > https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
>  
>  Why would this be a Fedora issue 
Isn't glibc used in Fedora for name resolution?

>  or a feature? 
See https://fedoraproject.org/wiki/Features/FixNetworkNameResolution#Rationale

>  Seems to me this falls squarely inside the scope of glibc 
Not entirely.

See https://fedoraproject.org/wiki/Features/FixNetworkNameResolution#Affected...

>  and it should be taken care of in glibc upstream 
As much as possible, yes, as is the case with many other fedora features.

>  rather than in Fedora. 
For me, the reliability and robustness of fedora networking is fairly important. I'd
say more important than most of the “update package X to version Y” features.

Submitting patches upstream is part of what makes Fedora a good distribution.

Cheers,

Pavel

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Miloslav Trmač]

On Wed, Jan 16, 2013 at 6:38 PM, Sam Varshavchik <mrsam(a)courier-mta.com&gt; wrote:
>  Jaroslav Reznik writes:
>
> > See https://fedorahosted.org/fesco/ticket/986
> >
> > = Features/Fix Network Name Resolution =
> > https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
>
>
>  Why would this be a Fedora issue or a feature?
>
>  Seems to me this falls squarely inside the scope of glibc, and it should be
>  taken care of in glibc upstream, rather than in Fedora. 
The feature page it may be necessary to update applications, either to
take advantage of the fixes, or to remove workarounds.  This might
need cross-package coordination.
    Mirek

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Nick Jones]

On Wednesday, January 16, 2013 10:11 PM, Jaroslav Reznik wrote:
>  As the Feature was renamed and the content of Feature has been
> extended
>  as requested by FESCo, re-announcing it to the community for re-review.
>
>  See https://fedorahosted.org/fesco/ticket/986
>
>  = Features/Fix Network Name Resolution =
>  https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
>
>  * Detailed description
>  Currently the 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.
>  
One feature I would like to see added to future glibc, is a fully 
asynchronous version of getaddrinfo, and also getnameinfo.

Asynchronous for non filesystem fds at least.

The glibc maintainers don't seem to be against this idea and I am 
willing to put time into design and implementation.

I have a number of high level ideas for this project that I would like 
to have documented as starting points.  I am not a fedora community 
member, so someone will need to help me raise bugzillas and paste my 
notes on the wiki.

   Nick

Adding asynchronous name resolution to GlibC (was: Reproposed F19 Feature: Fix Network Name Resolution)

[Björn Persson]

Nick Jones wrote:
>  One feature I would like to see added to future glibc, is a fully 
>  asynchronous version of getaddrinfo, and also getnameinfo.
>  
>  Asynchronous for non filesystem fds at least.
>  
>  The glibc maintainers don't seem to be against this idea and I am 
>  willing to put time into design and implementation. 
May I ask why you want to do that in GlibC? Are such functions
specified by some standard, such as Posix or a new version of ISO C? Or
are you proposing them for inclusion in such a standard?

I mean, I believe some asynchronous name resolution libraries for C
exist already, but if you want to do it better, or just differently,
then sure, no problem, but why in GlibC and not as a separate library?

I know there's a tradition of vendors adding their own nonstandard
extensions to their implementations of the standard C library, sometimes
with identical names but different specifications, but I'd like that
practice to stop. This differentiation of LibC implementations is one
of the big reasons why it's difficult to write portable programs in C,
requiring complex configuration scripts to test for available features
and enable different workarounds on different operating systems. It
would have been much better if all the LibCs had remained
implementations of the C standard and maybe Posix, and not much else.
Additional features could in many cases have been separate libraries.
We have to live with the mess now, but let's not make it worse please.

If your functions get added to GlibC, then they will only be available
in GNU systems (unless other vendors decide to clone them) and programs
that use them will be tied to GNU or will need workarounds in their
configuration scripts in order to be portable. If you make them a
separate, portable library, then they can be installed on all Unix-like
systems, and maybe other operating systems too, and programs that use
them will also be portable. Wouldn't that be better?

Björn Persson

Adding asynchronous name resolution to GlibC (was: Reproposed F19 Feature: Fix Network Name Resolution)

[Lennart Poettering]

On Fri, 18.01.13 20:20, Björn Persson (bjorn(a)xn--rombobjrn-67a.se) wrote:

>  If your functions get added to GlibC, then they will only be
> available
>  in GNU systems (unless other vendors decide to clone them) and programs
>  that use them will be tied to GNU or will need workarounds in their
>  configuration scripts in order to be portable. If you make them a
>  separate, portable library, then they can be installed on all Unix-like
>  systems, and maybe other operating systems too, and programs that use
>  them will also be portable. Wouldn't that be better? 
Yes, let's make our platform as bad as possible, so that people really
have a hard time writing software for it. If they then do write software
for it anyway they will have to do everything on their own, pull in a
gazillion of dependencies for that, and can do that in a thousand
different combinations, because that makes the code better, gets people
to test codepaths better, and just makes their lifes a lot more fun.

For example, I really find it appalling that Linux had proper threads
support (and even in the libc!) so early, at a time where OpenBSD
didn't. I think Linux really hurt the open source ecosystem with
that, as people could write threaded up for Linux that then wouldn't
work on OpenBSD. 

Booh, Linux, bad, Linux!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Adding asynchronous name resolution to GlibC (was: Reproposed F19 Feature: Fix Network Name Resolution)

[Andreas Tunek]

On Jan 18, 2013 8:48 PM, "Lennart Poettering" <mzerqung(a)0pointer.de&gt;
wrote:
>  On Fri, 18.01.13 20:20, Björn Persson (bjorn(a)xn--rombobjrn-67a.se) wrote:
>
>  > If your functions get added to GlibC, then they will only be available
>  > in GNU systems (unless other vendors decide to clone them) and programs
>  > that use them will be tied to GNU or will need workarounds in their
>  > configuration scripts in order to be portable. If you make them a
>  > separate, portable library, then they can be installed on all Unix-like
>  > systems, and maybe other operating systems too, and programs that use
>  > them will also be portable. Wouldn't that be better?
>
>  Yes, let's make our platform as bad as possible, so that people really
>  have a hard time writing software for it. If they then do write software
>  for it anyway they will have to do everything on their own, pull in a
>  gazillion of dependencies for that, and can do that in a thousand
>  different combinations, because that makes the code better, gets people
>  to test codepaths better, and just makes their lifes a lot more fun.
>
>  For example, I really find it appalling that Linux had proper threads
>  support (and even in the libc!) so early, at a time where OpenBSD
>  didn't. I think Linux really hurt the open source ecosystem with
>  that, as people could write threaded up for Linux that then wouldn't
>  work on OpenBSD.
>
>  Booh, Linux, bad, Linux!
>
>  Lennart
>
>  --; 
I think you have a good point, but adding every imaginable featw into glibc
is not really a good solution. Maybe glib is a better place for these kinds
of functions?
>  Lennart Poettering - Red Hat, Inc.
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

Adding asynchronous name resolution to GlibC (was: Reproposed F19 Feature: Fix Network Name Resolution)

[Simo Sorce]

On Fri, 2013-01-18 at 22:49 +0100, Andreas Tunek wrote:
>  
>  On Jan 18, 2013 8:48 PM, "Lennart Poettering" <mzerqung(a)0pointer.de&gt;
>  wrote:
>  >
>  > On Fri, 18.01.13 20:20, Björn Persson (bjorn(a)xn--rombobjrn-67a.se) wrote:
>  >
>  > > If your functions get added to GlibC, then they will only be
>  available
>  > > in GNU systems (unless other vendors decide to clone them) and
>  programs
>  > > that use them will be tied to GNU or will need workarounds in
>  their
>  > > configuration scripts in order to be portable. If you make them a
>  > > separate, portable library, then they can be installed on all
>  Unix-like
>  > > systems, and maybe other operating systems too, and programs that
>  use
>  > > them will also be portable. Wouldn't that be better?
>  >
>  > Yes, let's make our platform as bad as possible, so that people
>  really
>  > have a hard time writing software for it. If they then do write
>  software
>  > for it anyway they will have to do everything on their own, pull in
>  a
>  > gazillion of dependencies for that, and can do that in a thousand
>  > different combinations, because that makes the code better, gets
>  people
>  > to test codepaths better, and just makes their lifes a lot more fun.
>  >
>  > For example, I really find it appalling that Linux had proper
>  threads
>  > support (and even in the libc!) so early, at a time where OpenBSD
>  > didn't. I think Linux really hurt the open source ecosystem with
>  > that, as people could write threaded up for Linux that then wouldn't
>  > work on OpenBSD.
>  >
>  > Booh, Linux, bad, Linux!
>  >
>  > Lennart
>  >
>  > --;
>  
>  
>  I think you have a good point, but adding every imaginable featw into
>  glibc is not really a good solution. Maybe glib is a better place for
>  these kinds of functions? 
It really depends on what is the audience. A lot of software doesn't
link to glib and will not link to this huge lib just for 2 functions.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

Adding asynchronous name resolution to GlibC (was: Reproposed F19 Feature: Fix Network Name Resolution)

[Colin Walters]

On Fri, 2013-01-18 at 22:49 +0100, Andreas Tunek wrote:
>  Maybe glib is a better place for these kinds of functions? 
Already exists:

http://developer.gnome.org/gio/2.34/GResolver.html

Adding asynchronous name resolution to GlibC (was: Reproposed F19 Feature: Fix Network Name Resolution)

[Adam Jackson]

On Fri, 2013-01-18 at 22:49 +0100, Andreas Tunek wrote:

>  I think you have a good point, but adding every imaginable featw
> into
>  glibc is not really a good solution. Maybe glib is a better place for
>  these kinds of functions? 
If glibc didn't already have DNS API, that might be a more reasonable
argument.

- ajax

Adding asynchronous name resolution to GlibC (was: Reproposed F19 Feature: Fix Network Name Resolution)

[Lennart Poettering]

On Fri, 18.01.13 22:49, Andreas Tunek (andreas.tunek(a)gmail.com) wrote:

>  I think you have a good point, but adding every imaginable featw into
> glibc
>  is not really a good solution. Maybe glib is a better place for these kinds
>  of functions? 
Because doing this externally is really hard. I wrote a library for that
named "libasyncns", and glib's async resolver is based on that.

libasyncns is different from other libraries for resolving host names in
that i actually uses the NSS, rather than just implementing DNS on its
own. This has the benefit actually all kinds of hostnames are supported,
including those served from LDAP, NIS, mDNS and whatever the user
prefers. Now, since NSS and the libc APIs around it are inherentlich
synchronous the only way to make them asynchronous without touching
glibc is by running them in a separate thread/process. And doing that
behind the back of the user is kinda problematic from libraries.

So, bypassing NSS is not really an option to fix this properly. And if
you want asynchronous name resolution without involvement of threads and
suchlike then your only option is to make NSS asynchronous in itself,
and you cannot do that without reworking glibc substantially.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Adding asynchronous name resolution to GlibC (was: Reproposed F19 Feature: Fix Network Name Resolution)

[Kamil Dudka]

On Friday, January 18, 2013 23:35:24 Lennart Poettering wrote:
>  On Fri, 18.01.13 22:49, Andreas Tunek (andreas.tunek(a)gmail.com)
> wrote:
>  > I think you have a good point, but adding every imaginable featw into
>  > glibc
>  > is not really a good solution. Maybe glib is a better place for these
>  > kinds
>  > of functions?
>  
>  Because doing this externally is really hard. I wrote a library for that
>  named "libasyncns", and glib's async resolver is based on that. 
libcurl uses threads to wrap the glibc's name resolver two years now and, 
although it is not the default option, it does not generate so many bugs
as the setjmp/longjmp based timeout implementation, or using c-ares.

>  libasyncns is different from other libraries for resolving host names
> in
>  that i actually uses the NSS, rather than just implementing DNS on its
>  own. This has the benefit actually all kinds of hostnames are supported,
>  including those served from LDAP, NIS, mDNS and whatever the user
>  prefers. Now, since NSS and the libc APIs around it are inherentlich
>  synchronous the only way to make them asynchronous without touching
>  glibc is by running them in a separate thread/process. And doing that
>  behind the back of the user is kinda problematic from libraries. 
Yes, some libraries would like to be thread-safe without any locking,
which is currently incompatible with asynchronous name lookups.

Kamil

Adding asynchronous name resolution to GlibC

[Björn Persson]

Lennart Poettering wrote:
>  Because doing this externally is really hard. I wrote a library for
> that
>  named "libasyncns", and glib's async resolver is based on that.
>  
>  libasyncns is different from other libraries for resolving host names in
>  that i actually uses the NSS, rather than just implementing DNS on its
>  own. This has the benefit actually all kinds of hostnames are supported,
>  including those served from LDAP, NIS, mDNS and whatever the user
>  prefers. Now, since NSS and the libc APIs around it are inherentlich
>  synchronous the only way to make them asynchronous without touching
>  glibc is by running them in a separate thread/process. And doing that
>  behind the back of the user is kinda problematic from libraries.
>  
>  So, bypassing NSS is not really an option to fix this properly. And if
>  you want asynchronous name resolution without involvement of threads and
>  suchlike then your only option is to make NSS asynchronous in itself,
>  and you cannot do that without reworking glibc substantially. 
Thank you for presenting a valid argument instead of just ranting
sarcastically.

Björn Persson

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Daniel P. Berrange]

On Fri, Jan 18, 2013 at 09:37:37AM +0800, Nick Jones wrote:
>  On Wednesday, January 16, 2013 10:11 PM, Jaroslav Reznik wrote:
>  >As the Feature was renamed and the content of Feature has been extended
>  >as requested by FESCo, re-announcing it to the community for re-review.
>  >
>  >See https://fedorahosted.org/fesco/ticket/986
>  >
>  >= Features/Fix Network Name Resolution =
>  >https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
>  >
>  >* Detailed description
>  >Currently the 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.
>  >
>  
>  One feature I would like to see added to future glibc, is a fully
>  asynchronous version of getaddrinfo, and also getnameinfo.
>  
>  Asynchronous for non filesystem fds at least.
>  
>  The glibc maintainers don't seem to be against this idea and I am
>  willing to put time into design and implementation. 
Perhaps I'm misunderstanding what you're after, but doesn't
"getaddrinfo_a"
already provide an async version of getaddrinfo ?

    "Asynchronous Hostname Lookup API"
   http://www.akkadia.org/drepper/asynchnl.pdf

That said I don't see the reverse - getnameinfo_a

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Lennart Poettering]

On Mon, 21.01.13 10:25, Daniel P. Berrange (berrange(a)redhat.com) wrote:

>  > The glibc maintainers don't seem to be against this idea and
> I am
>  > willing to put time into design and implementation.
>  
>  Perhaps I'm misunderstanding what you're after, but doesn't
> "getaddrinfo_a"
>  already provide an async version of getaddrinfo ?
>  
>      "Asynchronous Hostname Lookup API"
>     http://www.akkadia.org/drepper/asynchnl.pdf
>  
>  That said I don't see the reverse - getnameinfo_a 
Brrrrh. It's designed around process signal delivery. I am
shuddering. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Dan Williams]

On Wed, 2013-01-23 at 02:46 +0100, Lennart Poettering wrote:
>  On Mon, 21.01.13 10:25, Daniel P. Berrange (berrange(a)redhat.com)
> wrote:
>  
>  > > The glibc maintainers don't seem to be against this idea and I am
>  > > willing to put time into design and implementation.
>  > 
>  > Perhaps I'm misunderstanding what you're after, but doesn't
> "getaddrinfo_a"
>  > already provide an async version of getaddrinfo ?
>  > 
>  >     "Asynchronous Hostname Lookup API"
>  >    http://www.akkadia.org/drepper/asynchnl.pdf
>  > 
>  > That said I don't see the reverse - getnameinfo_a
>  
>  Brrrrh. It's designed around process signal delivery. I am
>  shuddering.  
Ew.  Signals are not an event loop API.  Signals are not an event loop
API.  Signals are not an event loop API.  But apparently that's hard for
some people to understand...

Dan

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Daniel P. Berrange]

On Wed, Jan 23, 2013 at 11:24:25AM -0600, Dan Williams wrote:
>  On Wed, 2013-01-23 at 02:46 +0100, Lennart Poettering wrote:
>  > On Mon, 21.01.13 10:25, Daniel P. Berrange (berrange(a)redhat.com) wrote:
>  > 
>  > > > The glibc maintainers don't seem to be against this idea and I am
>  > > > willing to put time into design and implementation.
>  > > 
>  > > Perhaps I'm misunderstanding what you're after, but doesn't
> "getaddrinfo_a"
>  > > already provide an async version of getaddrinfo ?
>  > > 
>  > >     "Asynchronous Hostname Lookup API"
>  > >    http://www.akkadia.org/drepper/asynchnl.pdf
>  > > 
>  > > That said I don't see the reverse - getnameinfo_a
>  > 
>  > Brrrrh. It's designed around process signal delivery. I am
>  > shuddering. 
>  
>  Ew.  Signals are not an event loop API.  Signals are not an event loop
>  API.  Signals are not an event loop API.  But apparently that's hard for
>  some people to understand... 
I never claimed it was a nice API, just that it provides an async hostname
lookup capability already :-)

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[John Reiser]

On 01/23/2013 09:27 AM, Daniel P. Berrange wrote:
>  On Wed, Jan 23, 2013 at 11:24:25AM -0600, Dan Williams wrote:
> > On Wed, 2013-01-23 at 02:46 +0100, Lennart Poettering wrote:
> >> On Mon, 21.01.13 10:25, Daniel P. Berrange (berrange(a)redhat.com) wrote:
> >>
> >>>> The glibc maintainers don't seem to be against this idea and I am
> >>>> willing to put time into design and implementation.
> >>>
> >>> Perhaps I'm misunderstanding what you're after, but doesn't
> "getaddrinfo_a"
> >>> already provide an async version of getaddrinfo ?
> >>>
> >>>     "Asynchronous Hostname Lookup API"
> >>>    http://www.akkadia.org/drepper/asynchnl.pdf
> >>>
> >>> That said I don't see the reverse - getnameinfo_a
> >>
> >> Brrrrh. It's designed around process signal delivery. I am
> >> shuddering. 
> >
> > Ew.  Signals are not an event loop API.  Signals are not an event loop
> > API.  Signals are not an event loop API.  But apparently that's hard for
> > some people to understand...
>  
>  I never claimed it was a nice API, just that it provides an async hostname
>  lookup capability already :-) 
The signal handler can write a packet into a pipe from the process to itself,
and that can be hooked up to an event loop API.

--

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Dan Williams]

On Wed, 2013-01-23 at 09:48 -0800, John Reiser wrote:
>  On 01/23/2013 09:27 AM, Daniel P. Berrange wrote:
>  > On Wed, Jan 23, 2013 at 11:24:25AM -0600, Dan Williams wrote:
>  >> On Wed, 2013-01-23 at 02:46 +0100, Lennart Poettering wrote:
>  >>> On Mon, 21.01.13 10:25, Daniel P. Berrange (berrange(a)redhat.com) wrote:
>  >>>
>  >>>>> The glibc maintainers don't seem to be against this idea and I
> am
>  >>>>> willing to put time into design and implementation.
>  >>>>
>  >>>> Perhaps I'm misunderstanding what you're after, but doesn't
> "getaddrinfo_a"
>  >>>> already provide an async version of getaddrinfo ?
>  >>>>
>  >>>>     "Asynchronous Hostname Lookup API"
>  >>>>    http://www.akkadia.org/drepper/asynchnl.pdf
>  >>>>
>  >>>> That said I don't see the reverse - getnameinfo_a
>  >>>
>  >>> Brrrrh. It's designed around process signal delivery. I am
>  >>> shuddering. 
>  >>
>  >> Ew.  Signals are not an event loop API.  Signals are not an event loop
>  >> API.  Signals are not an event loop API.  But apparently that's hard for
>  >> some people to understand...
>  > 
>  > I never claimed it was a nice API, just that it provides an async hostname
>  > lookup capability already :-)
>  
>  The signal handler can write a packet into a pipe from the process to itself,
>  and that can be hooked up to an event loop API. 
Clearly.  But then you have to deal with signal handling and all the
things you're not able to do from a signal handler like allocate memory,
figure out any locking that may be required, and deal with signal
handler re-entrancy.  It's much easier for consumers of your library to
give them an API that can be easily integrated into their event loop
using select().  But of course that requires that you design your
library in an asynchronous manner too [1], which is just good practice
anyway so neither you nor your API clients don't have to deal with this
stuff.

Dan

[1] eg, client asks for a name lookup and hands your library a callback
function, your library constructs and sends the DNS request, then gives
control back to the caller and lets them select() on the UDP socket, and
when data is available they call back into your library so you can
handle the response, and when you have one you call the client's
callback

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Lennart Poettering]

On Wed, 23.01.13 12:35, Dan Williams (dcbw(a)redhat.com) wrote:

>  > >>> Brrrrh. It's designed around process signal
> delivery. I am
>  > >>> shuddering. 
>  > >>
>  > >> Ew.  Signals are not an event loop API.  Signals are not an event loop
>  > >> API.  Signals are not an event loop API.  But apparently that's hard
> for
>  > >> some people to understand...
>  > > 
>  > > I never claimed it was a nice API, just that it provides an async hostname
>  > > lookup capability already :-)
>  > 
>  > The signal handler can write a packet into a pipe from the process to itself,
>  > and that can be hooked up to an event loop API.
>  
>  Clearly.  But then you have to deal with signal handling and all the
>  things you're not able to do from a signal handler like allocate memory,
>  figure out any locking that may be required, and deal with signal
>  handler re-entrancy.  It's much easier for consumers of your library to
>  give them an API that can be easily integrated into their event loop
>  using select().  But of course that requires that you design your
>  library in an asynchronous manner too [1], which is just good practice
>  anyway so neither you nor your API clients don't have to deal with this
>  stuff. 
Yeah, signal handlers are really hard to get right. I am pretty sure
that if somebody took the time to go through the Fedora packages and
would just check how many signal handlers forget to save/restore errno
and write patches for those he'd get himself way up in the Ohloh
statistics of people with the most patches in various projects. He'd
probably even be able to get his name into a number of CVEs as a side
effect...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[John Reiser]

On 01/23/2013 10:35 AM, Dan Williams wrote:
>  On Wed, 2013-01-23 at 09:48 -0800, John Reiser wrote: 
> > The signal handler can write a packet into a pipe from the
> process to itself,
> > and that can be hooked up to an event loop API. 
>  Clearly.  But then you have to deal with signal handling and all the
>  things you're not able to do from a signal handler like allocate memory,
>  figure out any locking that may be required, and deal with signal
>  handler re-entrancy.   
In cases like this one, it is easy to avoid all those problems.
The packet is fixed length [and in this case probably includes
both the actual request and the result], declared locally in the handler,
allocated on the stack.  A plain write() of the packet requires
no locking (small writes on a pipe are atomic), and no concerns
about re-entrancy (order cannot matter).  The most that could matter
is filling the pipe, but on linux you get at least 64kB before
that happens, which should be enough for hundreds of packets
that have not yet been processed by the main loop.
If it matters, then use one atomic counter keep track of how many
packets the pipe contains; you get to decide what to do if it overflows
(probably: log the occurrence, then drop the packet.)

>  It's much easier for consumers of your library to
>  give them an API that can be easily integrated into their event loop
>  using select().    <<snip>> 
>  [1] eg, client asks for a name lookup and hands your library a
> callback
>  function, your library constructs and sends the DNS request, then gives
>  control back to the caller and lets them select() on the UDP socket, and
>  when data is available they call back into your library so you can
>  handle the response, and when you have one you call the client's
>  callback 
This is exactly what the signal+pipe scheme facilitates;
you get to write a couple dozen lines of straight-line code.
The main loop gets notified that the pipe has a packet,
then calls the NM callback.  All the NM callback has to do is
read the fixed-length packet from the pipe, unwrap the answer,
and feed it to the client's callback.

--

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Pedro Alves]

On 01/23/2013 07:31 PM, John Reiser wrote:
>  On 01/23/2013 10:35 AM, Dan Williams wrote:
> > On Wed, 2013-01-23 at 09:48 -0800, John Reiser wrote:
>  
> >> The signal handler can write a packet into a pipe from the process to itself,
> >> and that can be hooked up to an event loop API.
>  
> > Clearly.  But then you have to deal with signal handling and all the
> > things you're not able to do from a signal handler like allocate memory,
> > figure out any locking that may be required, and deal with signal
> > handler re-entrancy.   
(...)

This is known as the self-pipe trick.  Doing a web search for that
term will find lots of advice on how to use it properly.

>  This is exactly what the signal+pipe scheme facilitates;
>  you get to write a couple dozen lines of straight-line code.
>  The main loop gets notified that the pipe has a packet,
>  then calls the NM callback.  All the NM callback has to do is
>  read the fixed-length packet from the pipe, unwrap the answer,
>  and feed it to the client's callback. 
Right.  The issue with signal based interfaces is that
they're fundamentally bad for multi-threading and
libraries -- signal dispositions/handlers are global per
process, not per thread.  If two different libraries loaded
into a process want to use/reserve the same signal (which also
steals a signal from the main program), you're
in trouble.  See this 4 blog series about exactly this issue
around wait/SIGCHLD in Qt/glib for example:

http://www.macieira.org/blog/2012/07/forkfd-part-4-proposed-solutions/

-- 
Pedro Alves

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Nick Jones]

On Mon, Jan 21, 2013 at 6:25 PM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote:
>  On Fri, Jan 18, 2013 at 09:37:37AM +0800, Nick Jones wrote:
> > On Wednesday, January 16, 2013 10:11 PM, Jaroslav Reznik wrote:
> > >As the Feature was renamed and the content of Feature has been extended
> > >as requested by FESCo, re-announcing it to the community for re-review.
> > >
> > >See https://fedorahosted.org/fesco/ticket/986
> > >
> > >= Features/Fix Network Name Resolution =
> > >https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
> > >
> > >* Detailed description
> > >Currently the 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.
> > >
> >
> > One feature I would like to see added to future glibc, is a fully
> > asynchronous version of getaddrinfo, and also getnameinfo.
> >
> > Asynchronous for non filesystem fds at least.
> >
> > The glibc maintainers don't seem to be against this idea and I am
> > willing to put time into design and implementation.
>
>  Perhaps I'm misunderstanding what you're after, but doesn't
> "getaddrinfo_a"
>  already provide an async version of getaddrinfo ?
>
>      "Asynchronous Hostname Lookup API"
>     http://www.akkadia.org/drepper/asynchnl.pdf
>
>  That said I don't see the reverse - getnameinfo_a
>  
In the summary of this Fedora feature for fixing name resolution is
this snippet: "Fedora could be seen as the leader in linux networking"

getaddrinfo is important for Linux systems, and the existing issues
with it's implementation are well worth fixing, but when it comes to
DNS, getaddrinfo is holding Fedora and Linux back.

Even though DNS is not the only source of 'names' that getaddrinfo
can return, it is the most important, and in the context of DNS,
getaddrinfo will not let Fedora reach the above stated goal.

It's not just the lack of support for asynchronous usage, getaddrinfo
is a very feature poor resolver:
- No support for alternative DNS record types: mx, txt ((ab)used for
  a lot of things)
- No support for DNSSEC
- No TCP fallback for that matter, which is essential for the above
- Probably lot more, I'm no expert on dns

What is needed for networking leadership is:
- a feature rich resolver, supporting the above as well as query
  and response filtering, ala AI_ADDRCONF
- an implementation of an IPv6 migration strategy along the lines
  of Happy Eyeballs
- can be used both asynchronously or synchronously
- ideally pulls in no dependencies outside libc, except perhaps
  libidn
- ideally the DNS packet parsing routines use only ANSI C
- can be used by both C and C++ applications, and is easily
  bound to other scripting languages, even in the async case
- provides reverse lookup
- more I can't think of right now but I hope others will add more

The question is does this all get added into glibc?
1) Yes:
- glibc getaddrinfo gets updated to support this through
  the addition of new hints flags and return values, or a new
  function interface is created instead of shoehorning into the
  old interface, in any case the old getaddrinfo interface will
  always be callable using traditional, existing semantics and
  run time linking to existing apps will not be broken
- the nss layer gets rewritten to support asynchronous usage
  (and decent error reporting and additional lookup domains
  maybe samba?)
- perhaps the resulting work gets packaged into a proposed
  extension to POSIX

2) No:
- simply say: forget it, lets do proper DNS outside of libc

I say 1) could be possible over the course of a few years but
for now, 2) is more realistic.

As a quick summary: I would suggest, in addition to addressing
the outstanding bugs and issues covered by the Fedora feature,
a flag be added to the set of getaddrinfo parameters that
instructs it NOT to do DNS lookups, only perform alternative
resource lookups supported by nss.  This flag would be something
like: AI_NODNS

This will allow application developers to make use of
getaddrinfo for resolving names using non dns sources (hosts
file is DNS, so this means ldap and others), then perform
internet domain lookups using an alternative DNS library that
is standardised in Fedora.

Given that in most systems, the nss alternatives are local file
based, and given the option of using nsscache, these lookups
could be considered reasonably constrained therefore NOT in
need of asynchronous implementations.

Over time, the alternative DNS library could be considered for
inclusion in the core c library, and could replace the DNS
lookup aspect of getaddrinfo, at least for A and AAAA lookups,
and more if additional query flags are defined for getaddrinfo
or if an alternative function interface is defined.

In addition, work can be done to make the nss layer
asynchronous, or at least constrain it to local file resources and
standardise on the use of nsscache.

Or use this effort to re implement a switched name service
lookup library, including DNS aspect, outside of glibc.

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Miloslav Trmač]

Hello,
just a minor point, not getting into the wider "should getaddrinfo()
be the primary interface" debate...

On Tue, Jan 29, 2013 at 4:58 AM, Nick Jones <nick.fa.jones(a)gmail.com&gt; wrote:
>  As a quick summary: I would suggest, in addition to addressing
>  the outstanding bugs and issues covered by the Fedora feature,
>  a flag be added to the set of getaddrinfo parameters that
>  instructs it NOT to do DNS lookups, only perform alternative
>  resource lookups supported by nss.  This flag would be something
>  like: AI_NODNS
>
>  This will allow application developers to make use of
>  getaddrinfo for resolving names using non dns sources (hosts
>  file is DNS, so this means ldap and others), then perform
>  internet domain lookups using an alternative DNS library that
>  is standardised in Fedora. 
That's unnecessarily difficult for the application developers.
Application should have a single API to call; if they have to call two
separate APIs, some of them won't.
    Mirek

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Nick Jones]

On Tue, Jan 29, 2013 at 9:47 PM, Miloslav Trmač <mitr(a)volny.cz&gt; wrote:
>  Hello,
>  just a minor point, not getting into the wider "should getaddrinfo()
>  be the primary interface" debate...
>
>  On Tue, Jan 29, 2013 at 4:58 AM, Nick Jones <nick.fa.jones(a)gmail.com&gt; wrote:
> > As a quick summary: I would suggest, in addition to addressing
> > the outstanding bugs and issues covered by the Fedora feature,
> > a flag be added to the set of getaddrinfo parameters that
> > instructs it NOT to do DNS lookups, only perform alternative
> > resource lookups supported by nss.  This flag would be something
> > like: AI_NODNS
> >
> > This will allow application developers to make use of
> > getaddrinfo for resolving names using non dns sources (hosts
> > file is DNS, so this means ldap and others), then perform
> > internet domain lookups using an alternative DNS library that
> > is standardised in Fedora.
>
>  That's unnecessarily difficult for the application developers.
>  Application should have a single API to call; if they have to call two
>  separate APIs, some of them won't.
>      Mirek 
Admittedly there is a problem with adding the AI_NODNS flag, in
addition to what you mentioned.  That is, what happens when an
application compiled to use AI_NODNS is run against an older
libc.  The binary interface is the same but not the behavioural
interface, therefore the application will run but will perform two
dns lookups.

One way to get around this is by adding a versioned symbol for
getaddrinfo, which is no different from the current non versioned
symbol.  It will be present for enforcement of runtime and rpm
build time compatability.

Another way is to add a new functional interface like:
getnondnsaddrinfo, except with a better name, which performs
non dns lookups only.

Adding new interfaces to glibc is only done when necessary so
a lot of justification for either would be needed, rightly so.

I agree that splitting name resolution into two parts is an added
complication for application developers, but I feel getaddrinfo
itself is split into two of parts:
- name resolution using databases such as ldap via nss
- name resolution using a dns A or AAAA record lookup

Making getaddrinfo and nss fully asynchronous will not happen
soon, but my suggestion is to split the behaviour to allow an
application to be able to resolve names from non-dns sources
(which is an important function) then make use of a more
modern dns resolver.

The behaviour of existing binaries run against the a libc
will not be changed in any way.  They will continue to use
getaddrinfo as they have always done.

New applications will have the freedom to lookup a name
using getaddrinfo first, then perform the specifically A or
AAAA record lookup using a dedicated dns library that is
fully asynchronous, and also supports richer dns functionality,
thus can be re-used for other purposes.

Nick

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Miloslav Trmač]

On Wed, Feb 6, 2013 at 4:57 AM, Nick Jones <nick.fa.jones(a)gmail.com&gt; wrote:
>  On Tue, Jan 29, 2013 at 9:47 PM, Miloslav Trmač <mitr(a)volny.cz&gt;
> wrote:
> > On Tue, Jan 29, 2013 at 4:58 AM, Nick Jones <nick.fa.jones(a)gmail.com&gt; wrote:
> >> As a quick summary: I would suggest, in addition to addressing
> >> the outstanding bugs and issues covered by the Fedora feature,
> >> a flag be added to the set of getaddrinfo parameters that
> >> instructs it NOT to do DNS lookups, only perform alternative
> >> resource lookups supported by nss.  This flag would be something
> >> like: AI_NODNS
> >>
> >> This will allow application developers to make use of
> >> getaddrinfo for resolving names using non dns sources (hosts
> >> file is DNS, so this means ldap and others), then perform
> >> internet domain lookups using an alternative DNS library that
> >> is standardised in Fedora.
> >
> > That's unnecessarily difficult for the application developers.
> > Application should have a single API to call; if they have to call two
> > separate APIs, some of them won't.
>
>  Admittedly there is a problem with adding the AI_NODNS flag, in
>  addition to what you mentioned.  That is, what happens when an
>  application compiled to use AI_NODNS is run against an older
>  libc. 
Precisely what should happen:
>    if (hints->ai_flags
>        & ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST|AI_ADDRCONFIG|AI_V4MAPPED
>  #ifdef HAVE_LIBIDN
>            |AI_IDN|AI_CANONIDN|AI_IDN_ALLOW_UNASSIGNED
>            |AI_IDN_USE_STD3_ASCII_RULES
>  #endif
>            |AI_NUMERICSERV|AI_ALL))
>      return EAI_BADFLAGS; 

>  I agree that splitting name resolution into two parts is an added
>  complication for application developers, but I feel getaddrinfo
>  itself is split into two of parts:
>  - name resolution using databases such as ldap via nss
>  - name resolution using a dns A or AAAA record lookup
>
>  Making getaddrinfo and nss fully asynchronous will not happen
>  soon, but my suggestion is to split the behaviour to allow an
>  application to be able to resolve names from non-dns sources
>  (which is an important function) then make use of a more
>  modern dns resolver. 
If I understand you correctly, you want to split the queries
that
return "immediately" vs. those that may take a long time.  In that
case the split should not be DNS/non-DNS - in particular NIS/LDAP
belong to the asynchronous ("DNS") case.
   Mirek

Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Pavel Simerda]

----- Original Message -----
>  From: "Nick Jones" <nick.fa.jones(a)gmail.com&gt;
>  In the summary of this Fedora feature for fixing name resolution is
>  this snippet: "Fedora could be seen as the leader in linux networking" 
Yep. My intention to improve the overall networking features is not limited to what is
described in FixNetworkNameResolution.

>  getaddrinfo is important for Linux systems, and the existing issues
>  with it's implementation are well worth fixing, but when it comes to
>  DNS, getaddrinfo is holding Fedora and Linux back. 
When it comes to DNS, it's absolutely necessary to run a local resolver like dnsmasq
or unbound (the latter supporting DNSSEC) to achieve some of the advanced features like
split lists of DNS name servers (e.g. for VPNs). But at least dnsmasq is already supported
by NetworkManager.

>  Even though DNS is not the only source of 'names' that
> getaddrinfo
>  can return, it is the most important, and in the context of DNS,
>  getaddrinfo will not let Fedora reach the above stated goal. 
I'd be happy to discuss the details, probably in a separate discussion from this
feature. Maybe IRC some time?

>  It's not just the lack of support for asynchronous usage,
> getaddrinfo
>  is a very feature poor resolver:
>  - No support for alternative DNS record types: mx, txt ((ab)used for
>    a lot of things) 
True enough. I was thinking about implementing at least SRV records.

>  - No support for DNSSEC 
True enough. And also no support for DNS lifetimes. There probably should be a more
coprehensive API for that while getaddrinfo would work on top of it.

>  - No TCP fallback for that matter, which is essential for the above
This should be handled in the DNS daemon (or supplementary tools) anyway.

>  - Probably lot more, I'm no expert on dns 
Possibly.

>  What is needed for networking leadership is:
>  - a feature rich resolver, supporting the above as well as query
>    and response filtering, ala AI_ADDRCONF 
Agreed.

>  - an implementation of an IPv6 migration strategy along the lines
>    of Happy Eyeballs 
I'm afraid this is not limited to DNS.

>  - can be used both asynchronously or synchronously 
That would be nice. Communication with a daemon over sockets works asynchronously for
free.

>  - ideally pulls in no dependencies outside libc, except perhaps
>    libidn 
That would require a custom communication protocol for the async part.

>  - ideally the DNS packet parsing routines use only ANSI C
>  - can be used by both C and C++ applications, and is easily
>    bound to other scripting languages, even in the async case 
That again suggests a daemon with IPC.

>  - provides reverse lookup 
Sure.

>  - more I can't think of right now but I hope others will add more
It would be better to maintain such information on a wiki page or something. Nobody will
come back to the e-mails now and then.

>  The question is does this all get added into glibc?
>  1) Yes:
>  - glibc getaddrinfo gets updated to support this through
>    the addition of new hints flags and return values, or a new
>    function interface is created instead of shoehorning into the
>    old interface, in any case the old getaddrinfo interface will
>    always be callable using traditional, existing semantics and
>    run time linking to existing apps will not be broken
>  - the nss layer gets rewritten to support asynchronous usage
>    (and decent error reporting and additional lookup domains
>    maybe samba?)
>  - perhaps the resulting work gets packaged into a proposed
>    extension to POSIX 
Even if this could be done, it looks like a very-long-term project and needs more than
just dropping suggestions to a mailing list.

>  2) No:
>  - simply say: forget it, lets do proper DNS outside of libc 
We already can do proper DNS outside libc. There's no problem with that. The more
complicated part is getting all sorts of resolution methods together.

>  I say 1) could be possible over the course of a few years but
>  for now, 2) is more realistic.
>  
>  As a quick summary: I would suggest, in addition to addressing
>  the outstanding bugs and issues covered by the Fedora feature,
>  a flag be added to the set of getaddrinfo parameters that
>  instructs it NOT to do DNS lookups, only perform alternative
>  resource lookups supported by nss.  This flag would be something
>  like: AI_NODNS 
I'm not in favor of adding this flag, as DNS is not IMO as specific.

>  This will allow application developers to make use of
>  getaddrinfo for resolving names using non dns sources 
What for?

>  (hosts file is DNS, 
This is a huge mistake. Many of the bugs are results of treating the /etc/hosts the same
way as DNS resolution. While the /etc/hosts file often overrides the information that
would otherwise be recieved through DNS, it is no DNS at all, just a way to specify static
mapping between names and addresses.

>  so this means ldap and others), then perform
>  internet domain lookups using an alternative DNS library that
>  is standardised in Fedora. 
I don't think this is a good solution.

>  Given that in most systems, the nss alternatives are local file
>  based, 
Not at all. And even less in the future.

>  and given the option of using nsscache, these lookups
>  could be considered reasonably constrained therefore NOT in
>  need of asynchronous implementations.
>  
>  Over time, the alternative DNS library could be considered for
>  inclusion in the core c library, and could replace the DNS
>  lookup aspect of getaddrinfo, at least for A and AAAA lookups,
>  and more if additional query flags are defined for getaddrinfo
>  or if an alternative function interface is defined. 
Spliting out DNS from other host name resolution more than it is now, would IMO be a huge
mistake. There's not just DNS out there.

>  In addition, work can be done to make the nss layer
>  asynchronous, or at least constrain it to local file resources and
>  standardise on the use of nsscache. 
This is something that could be discussed after fixing up the current synchronous API.

>  Or use this effort to re implement a switched name service
>  lookup library, including DNS aspect, outside of glibc. 
Also worth discussing later.

Cheers,

Pavel