On Tue, 2008-09-16 at 23:50 -0400, Dan Williams wrote: > On Tue, 2008-09-16 at 13:19 +0200, Nils Philippsen wrote: > > On Tue, 2008-09-16 at 11:05 +0100, Paul Howarth wrote: > > > > > Another problem with modifying resolv.conf is that most processes only > > > read it once, usually shortly after starting up, so any changes that > > > happen after that don't get picked up by existing processes. So for > > > instance you could have a web browser that couldn't resolve names from a > > > VPN tunnel that had been brought up after the browser had been started. > > > > Which is a bug IMO. If applications don't use the glibc supplied > > functions for name-resolving, they should at least reinvent the wheel > > properly and check for changes to resolv.conf. > > Nobody is rolling their own code; they all use gethostbyname. You are very wrong. gethostbyname is useful only for querying A records, DNS is more. > The > problem is that glibc's resolver is too simplistic. I asked the glibc > guys about this about 3 years ago and they said they wanted to keep > glibc's resolver simple and that this should be handled either by lwresd > or a caching nameserver. The core issue was that doing something like > polling /etc/resolv.conf for updates would be unecessary on many > platforms. And I think they are correct, it's not glibc duty to provide a solution to good DNS caching. > So the answer seems to be that glibc will not change it's simple > internal resolver (which has more limitations than just noticing > resolv.conf changes), but the recommendation is that lwresd or a local > caching nameserver be used for more complex DNS setups. A caching nameserver that can be instructed what to do when conditions change is what we really need. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
