Simo Sorce wrote:
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.
Isn't it a little late to redesign the internet so names and addressing
aren't delegated hierarchically?
What would this mean ?
What it would mean is that could have duplication of names and addresses
and different nameservers give different results on purpose. This
happens with private lans with private addresses and non-registered
domains and you can sort-of deal with it as long as the private space
you see is all coordinated and has no overlap with the public.
But let me ask a question in your own style: do you understand the
difference between a normal DNS server and a local cache ?
I'm not sure what you mean by the question. It is very normal for any
DNS server to also be a local cache. The issue here is about 'when
conditions change', which in the context of public DNS is basically
never - that is, any resolver anywhere will give the same result unless
you go out of your way to localize it. I think what we were talking
about are situations where you have one or more private LAN segments
with their own private name servers (that can probably also resolve
public DNS) and your machine is a roaming laptop or you arbitrarily make
and break VPN connections among the private segments. In the simple
roaming case you would let DHCP give you DNS servers that are primary or
secondary for their private space as well as public resolvers. In the
more complicated setup, you can configure named to use different
forwarders for different private zones. You won't be able to resolve
names if your VPN to a forwarder is down, but you wouldn't be able to
connect there anyway so it's not a big loss.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
