(E-Mail Removed) wrote:
> I'm no expert in networking but I would have **expected** something
> like this,
Your initial post confirms this ... :-) But don't despair -- you just
don't understand how dynamic network connectivity is established and
how it behaves/interacts in different environments.
> I'd like to maintain a list of trusted (optimally, authenticated in
> some way) nameservers. This list can only be added to or removed by
> the local user or adminstrator (someone with write permissions to the
> list anyway...) . When connecting, the local DHCP should make a
> **request** to the user/administrator that the nameserver be added into
> the "trusted" list. If it is, then we use that DNS. If not, then we
> try to use a DNS in the trusted list. If those all fail then we don't
> connect and give a reason why (DNS failure). Doesn't SSH do some
> similar tactic for authentication?
Like Allen, I've never seen anything that _overwrites_ /etc/hosts as a
"default" behavior. I would assume it's due to some config change
introduced by something you're running (locally or on the network --
some setups use the /etc/hosts file for quicker lookups or as a kind of
dns cache).
In terms of what you want (describe above) you can provide a static
list of dns servers and not ask for their IPs via DHCP. Some people do
this and use a "public" dns server as a failover (though not very
secure, FWIW).
You can also resort to dnssec (Secure DNS) if you control the servers
and can administer them. This is the only "standards" based means of
dns authentication.
To attempt to confirm the dns server against a "static" list I _think_
will require a script of your own making. Ie., I'm not confident that
there is a "ready made" way to do this via dhclient.conf. You will
need to look through all the documentation re: dhclient -- some 7-8 man
pages altogether.
> This behavior could be relaxed so that all requests are automatically
> accepted to something like current behavior, but I still don't see why
> DNS information is overwritten in /etc/resolve.conf.
That's one of it's main purposes -- to act as a _resolver_ -- for a
machine without a static configuration.
You might want to look here for the Redhat docs:
http://www.redhat.com/docs/manuals/e...rkscripts.html
http://www.redhat.com/docs/manuals/e...e/ch-dhcp.html
You may want to look at the RH9 docs also, though I think the info
above is pretty complete re: RH manuals.
> Why not a list
> and the most recent addition being tried first? What happens if the
> suggested DNS is not working or is bogus?
It's why you have more than 1 (ususally 2 and sometimes 3 name servers
returned by the DHCP server). Bogus? Depends on the network
design/admin. The info comes from the DHCP server (or is static) and
that _can_ be spoofed but has to be on the local subnet (or the rougue
has _really_ infected the lan).
> I'd like to be made aware of
> the fact that it's down for example and that's why connections are not
> going through.
DNS is a _not_ a requirement for network connectivity but you will
indeed notice when it's offline. That's when you ping the dns server
;-)
> More stringently, if it's bogus, I'd like a way to see
> that it fails some authentication step.
DNSSEC is the only authentication standard aimed at DNS. Like most
network security, it's only a small piece of many inter-related parts
and _very_ few networks deploy DNSSEC.
> Like maybe I encrypt something
> using the DNS server's public key and it tries to decrypt using it's
> private key. Dunno...?
>
> Fedora should be happy that I am using their distribution on a mobile
> device. This is a wave of the future. That the way "they" or DHCP
> rather decides to overwrite my /etc/hosts file
I'm not sure that DHCP _can_ overwrite the /etc/hosts file without much
help from the host configuration/scripts. It's _not_ normal behavior
and is certainly _not_ the default.
> and my
> /etc/resolve.conf
This is what /etc/resolve.conf is for. You don't want it to change?
Don't use DHCP ;-) Or supply static dns IPs and configure dhclient
_not_ to ask for dns IPs.
> which ,in fact, silently and mysteriously breaks my
> software license managers, internet connections etc
Not sure about your laptop setup or the lan(s) you run it on or your
licenses, but these are _not_ Fedora or DNS or DHCP design problems.
There is a misconfiguration and/or conflict somewhere.
>should be something
> they consider for enhancement if they want to remain competitive in the
> mobile market -- yes??
No.
You may also want to see if your laptop is using ifplugd (Hot Plug) to
configure the ethernet port. It's usually quite good, but can have
quirks/problems with some laptops that may require configuring by hand.
You can check here:
http://0pointer.de/lennart/projects/ifplugd/
And you may want to set up different network profiles. As with
ifplugd, laptop/mobile units can make good use of them in many
scenarios.
And you _may_ want to disable Zeroconf in your startup -- especially if
you don't use a wireless connection.
BTW, the lines in your /etc/hosts file are "normal". The first line is
_necessary_ and the second line just injects an additional "host name"
to be associated with the loopback interface. Could also appear on the
first line with localhost like mine does:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 pbrain localhost.localdomain localhost
hth,
prg
Similar Threads
Linear Mode
