NFS help (.. is definitely needed)

[Otto Haliburton]

> -----Original Message-----
> From: redhat-install-list-bounces at redhat.com [mailto:redhat-install-list-
> bounces at redhat.com] On Behalf Of Jeff Kinz
> Sent: Sunday, August 28, 2005 12:44 PM
> To: redhat-install-list at redhat.com
> Subject: Re: NFS help (.. is definitely needed)
> 
> 
> There is, apparently, a great deal of confusion about the relationship
> between the dynamic host control protocol, "DHCP" and the domain name
> service, "DNS".
> 
> The relationship between these two is very simple and can be summed up
> in as follows:
> 
> "They have no relationship. DNS and DHCP have no intersecting messages.
> They never communicate with each other."
> 
> 
> On Sun, Aug 28, 2005 at 08:32:22AM -0500, Otto Haliburton wrote:
> 
> > If your server has a static address it is reporting that to the DNS and
> that
> > address will be reported.  The DNS only reports what is reported to it
> as
> > the address.  The assignment of dynamic addresses is done by the DHCP
> and
> > that is the relationship.  So what you are saying is confused and
> frankly
> > out of sorts.  That is why I don't understand what you are saying.
> There is
> > a relationship between all elements of the network, but the main element
> is
> > to resolve addresses so that you can send messages where ever you have
> > access freely so
> 
> 
> > if your server changes it IP address it will get reported
> > with the new address and the DNS is not broken your server is broken.
> The
> > DNS does not assign addresses get it.
> 
> 
> This statement is neither correct nor incorrect.  It is simply too
> vague.
> 
> Point No. 1: Most servers do not get their IP addresses assigned
> dynamically.  Most servers have static IP addresses.  (We will not
> bother discussing the special needs of clusters of load sharing servers
> which are all accessed through a specially constructed Internet
> facing network interface)
> 
> Point No. 2: when a server does exist which has a dynamically assigned
> IP address, such as in the case of Kinz.org, it is the responsibility
> of the human administrator to update the IP address information with the
> domain name registrar: In this case dyndns.org.  Dyndns.org is a company
> which evolved specifically to address the special needs of people who
> wished to have a domain name, but whom were unfortunately saddled with
> a dynamically assigned IP address.
> 
> Point No. 3: No "server" automatically reports its new IP address to
> it's domain name registrar. Because of the huge headaches involved when
> a server or domain name changes its IP address, most site administrators
> avoid, as strenuously as possible, having their servers' IP addresses
> change.
> 
> For years, all the IP address information which the domain name service,
> DNS, reported was all entered by hand into the DNS "databases" (mostly
> text files).
> 
> The notion that a server automatically updates the DNS system
> whenever it's dynamically assigned IP address changes conveys a huge
> mis-perception about how the Internet actually works. By and large most
> servers maintain the same IP address for long periods of time. These are
> statically assigned IP addresses, not dynamic.
> 
> Dynamically assigned IP addresses are, in main, used for end-users
> dynamically connecting and disconnecting from their various ISP's
> networks.  In other words, every desktop and laptop accessing
> the Internet through a dial-up, cable, DSL, or even satellite, and even
> on an internal corporate LAN, usually has a dynamically assigned IP
> address and does not have a domain name so there would simply be no
> point in communicating its "new" IP address to the domain name system.
> 
> Consider the large number of possible IP addresses available with just
> IP4 (four octets): if any significant fraction of these addresses were
> to begin to change dynamically it could quite literally overwhelm the
> DNS system.  By far, the vast majority of addresses which are registered
> in the DNS system are almost completely static.  And the many site
> administrators struggle mightily to keep them that way.
> 
> One of the security issues, discussed in small dark backroom's, by
> nervous large site administrators, security personnel for large
> financial organizations as well as government officials associated with
> keeping the banking and economic infrastructure functioning smoothly is
> the notion of a failure of the DNS system caused by an attack on the DNS
> system using the application of large numbers of address assignment
> changes as a "denial of service" style of attack.
> 
> Today there are tools, mostly small scripts, which can be run on servers
> that will automatically send IP address up-to-date information to the
> domain name registrar of that server. Dyndns.org provides such tools.
> 
> However, these tools are specifically built to access a custom interface
> which exists only at Dyndns.org and you can't depend on these tools to
> work with any other registrar. Furthermore these tools are only useful
> on the few domains which are being operated on systems which have
> dynamically assigned IP addresses.  Because of the way information is
> propagated, (slowly), through the DNS system, this only works at all
> because relatively few domains have dynamically assigned IP addresses.
> 
> one last note, at large Web hosting companies which are also domain name
> registrars for their customers, custom-built tools exist to manage
> updating IP address assignment to the DNS system for their customer's
> domains.  When using virtual hosting, on a large number of machines it
> is quite easy to understand that one machine may host a few hundred
> valid domain names, and therefore all of those domains will have the
> same IP address. Imagine what happens when that machine fails.  Those
> hundreds of domains must be redistributed to the other virtual servers
> owned by that Web hosting company and the IP address for each of those
> domains must be updated.  This is an absolute pain in the neck to do by
> hand.  Naturally the first thing a lazy administrator does is to read
> the script or some other tool which automates or eases that workload.
> 
> (Being lazy is a virtue in a programmer :-))
> 
> Clearly using Dragon NaturallySpeaking's speech recognition software
> is making it too easy to run on about this.
> 
> I'll stop here.
> Sincerely yours, Jeff "Lefty" Kinz
> 
> --
> speech recognition software was used in the composition of this e-mail
> Jeff Kinz, Emergent Research, Hudson, MA.
> ¡Ya no mas!
> 
not wanting to get into a heavy discussion on this issue, I will just state
this simply.  My ISP assigns me a IP address, I have a router and through
the DHCP my computer is assigned a local IP address and since I have
connected to my local address I have up to 5 local IP addresses(could have
many more if I liked) under this standard each of the 5 IP addresses are
translated to go out the one address assigned by the ISP.  When it assigns
me the one IP address it assigns my IP address to two DNS IP addresses and
it also assigns a gateway.  The ISP can change the IP address it assigns to
me(this assignment is a dynamic assignment) anytime it wants and it will be
transparent to me because the DNS to which this IP is assigned is updated
with the IP address and since it is transparent somebody in China can still
send a message or connect to my network and they don't need to have the new
IP address that is assigned.  Now on my local network I can have the same
setup.  I can have my own DNS server that I assign my local IP to and it
resolves the issues for my local network.  On local networks arbitration
goes on and somebody declares I'm the boss and I will handle all of this
info and if he drops out then the arbitration happens again and somebody
else becomes boss, etc etc.  The DNS declares himself to be the boss of the
5 computers on my local and does all of the resolutions for my network and
communicates with the outside world to resolve the issues.  One of the
issues that you mention is true for domains like .com, .net, and etc. but
that is only part of the answer the other part is the routing and routing
tables and these are important in the address resolution.  While I don't
disagree with you completely.  There are definitely holes, I am not a
expert, but you can check any ISP assignment to see that the structure I
presented above is alive and working.  SNMP is a part of what you presented
so I am not completely positive about all of this but there is chaos going
on when you decide to send a message, cause a route has to be setup and it
is this arbitration between the DNS that determine how to setup this route.