This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: resolver with IPv6 transport support


   From: Ulrich Drepper <drepper@redhat.com>
   Date: 22 Jul 2000 19:50:07 -0700

   <venaas@nvg.ntnu.no> writes:

   > I hope someone more experienced can take a careful look at
   > the patch, I might have missed something. The patch can be
   > found at

   I looked at the patch.  In general, it looks good.  But there are a
   few problems:

   - the size of the _res structure changes and also the offsets of elements
     users might access.  It is a horribly stupid idea to let programs use
     _res but that's what the interface demands.

And there is no way IPv6 socket addresses are ever going to fit in the
current structure.

     Eventually we have to change the size of the structure.  This will
     require ugly backward compatibility hacks but might be doable.

An alternative would be to replace (some of) the private members with a
pointer to malloc'ed space.  res_init/res_ninit would allocate the
necessary space for the private members that we removed plus whatever
is necessary for the IPv6 socket addresses.

     What I'm a bit worried about is the memory requirement.  Using
     sockaddr_storage gives you 10 out of ten points for style, but no
     point for efficiency.  The resolver status (especially if you consider
     the sort_list as well) is needed in every thread and therefore size
     counts.

Does the space consideration also enter when using malloc'ed memory?
In that case the memory counts only for threads that actually use the
resolver.

   If you can update your patch for the current CVS version (or wait 'til
   2.1.92) then we'll see what we can do about the _res variable size
   change.

[To Stig]

When doing so, please try your best to minimize the changes with the
origional code as much as possible.  I try to keep it in synch with
BIND 8.  If you look at the current code, you'll see that I've used
some `#ifdef _LIBC' constructs to mark the code that's different.

[To all]

That said, there may be an argument for *not* adding support for
nameservers with an IPv6 address to the stub resolver.  You can always
run a forward only nameserver locally and put 127.0.0.1 as the
resolver in your /etc/resolv.conf.  In fact, with the advent of
DNSSEC, it will be almost essential to have a nameserver really close
by (in the same subnet) since it isn't feasable to implement strong
cryptography in glibc.  If you look at the BIND 9 beta versions you'll
see that the traditional stub resolver has been replaced by a
lightweight resolver library (liblwres) and daemon (lwresd).  The
daemon, a special incarnation of named, runs locally, and indeed can
contact nameservers with an IPv6 address.  I've written a NSS module
for lwresd, which you can get at <http://members1.chello.nl/~m.m.kettenis>.

Mark

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]