This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: resolver with IPv6 transport support
- To: drepper at cygnus dot com
- Subject: Re: resolver with IPv6 transport support
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Sun, 23 Jul 2000 14:15:22 +0200
- CC: venaas at nvg dot ntnu dot no, libc-alpha at sourceware dot cygnus dot com
- References: <20000723020806.A7944@nvg.ntnu.no> <m3wvidwof4.fsf@otr.mynet.cygnus.com>
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