Jane Curry wrote:
> This is one of my "soapbox" subjects....
> I struggle a little with organisations who invest in NetView but do not
> invest in
> a reliable DNS infrastructure. [...]
Sometimes the DNS issues are because of the nature of DNS and how the company's
networks are politically divided up. Companies tend to want to assign DNS
names by
department, function, OS, or other some such. DNS doesn't work well for that
scheme
unless network addresses are also assigned in that way. DNS was designed to
work
only in an environment where all addresses in a network are under a single
domain.
For example, a customer may have assigned several machines in a given network to
different DNS domains. Here would be a rather common example:
Lets say that your NetView server exists as netview.netops.company.com, and it's
address is 191.23.30.27. You have a critical server that you want to monitor
with
NetView whose name is bigguy.servers.company.com, and whose IP address is
191.23.30.166. The company has set up DNS servers in each domain to handle the
resolution. You should be able to query DNS to look up the address of
bigguy.servers.company.com, and it will query the servers.company.com domain to
answer correctly. However, when you try to reverse resolve the name for the
address
191.23.30.166, DNS comes back with no such address. It is a valid answer, not a
failure.
DNS basically does reverse name resolution by looking for the name of the IP
address
in the database (IN-ADDR-ARPA files) one domain at a time. When you try to
reverse
resolve 191.23.30.166 in the example above, DNS queries your default domain
(netops.company.com) for the name of the address. The DNS database contains
30.23.191.IN-ADDR-ARPA, but the file contains no entry for the 166 address
because it
is in the servers.company.com database. The search returns no entry, but since
the
network 191.23.30 is in DNS, the answer is valid. It doesn't search all domains
looking for the network address, it stops at the first domain that is handling
that
network, and takes the answer from there.
Of course there are ways to administer DNS to get around this problem, but as
Jane
wrote it is often a political problem: Centralizing DNS in a decentralized
company...
One way to get around this particular problem is by changing the default name
resolution order. In AIX this is defined in /etc/netsvc.conf. In Solaris it is
/etc/nsswitch.conf. The syntax in the files is slightly different, but you can
configure it to look locally (in /etc/hosts) first, then query DNS. Then in the
local /etc/hosts file, only place the local machine's IP addresses, loopback,
and the
IP addresses and fully qualified names of the servers you need to resolve. For
the
above example, this entry would exist:
191.23.30.166 bigguy.servers.company.com
Then forward and reverse name resolution on bigguy.servers.company.com will
work.
Now you are tasked with maintaining /etc/hosts. Life is full of tradeoffs.:-)
--
Ray Schafer | schafer@tkg.com
The Kernel Group | Distributed Systems Management
http://www.tkg.com
|