-------------------------------------------------------------------------------
ORIGINAL QUESTION:
-------------------------------------------------------------------------------
Subject: Solaris 2.4, DNS-client, Login Delay...
Could someone tell me what Solaris 2.4 is doing with DNS on a network login.
I have just installed a SparcServer1000E with Solaris 2.4 and everthing works
greate...
I created a /etc/resolv.conf and /etc/nsswitch.conf...
nsswitch was the file flavor and all I changed was the "host: files dns"...
I had a typo in my /etc/resolv.conf...which ment my DNS would not work right.
The problem/part I don't understand is that when the "DNS-client" was not
configured correctly I had a long delay on my NETWORK login prompt....
I've played with this a bit and I can re-create the problem at will...
DNS-client working = fast network Login prompt response
DNS-client malformed = sloooow network Login prompt response
Finally the QUESTION: Why/What/Where/When is solaris doing with DNS on a
simple LOGIN? Why would dns have an affect on a simple network login...
I'm not running NIS or NIS+ or any extra security stuff...
What gives?
-------------------------------------------------------------------------------
ANSWER: ?
-------------------------------------------------------------------------------
I don't know if I have receive a complete answer but the REPLYS are some
ideas on what is going on...
I read it as Solaris 2.4 does a reverse lookup via DNS on a login to the
2.4 system over the network...If you DNS 2.4 client is malformed/broke
you will wait for the DNS timeout and then the 2.4 system will write the
login prompt....my best guess is that this check is a hook for C2 or more
other network authentication that could be used...
I put a sniffer on the net and I can see the login requesting the rarp....
Still don't know why Solaris 2.4 does this rarp....?
-------------------------------------------------------------------------------
REPLYS:
-------------------------------------------------------------------------------
From: Chris.Royle@elmail.co.uk (Chris Royle)
This is reasonable behaviour - Solaris may be doing some sanity checks
on the source IP address (ie, by doing a reverse lookup on it,
followed by a forward lookup to see whether the resultant IP address
is the same as the one in the IP packets), so if your DNS isn't
working, it will time out and you might get a delay.
-------------------------------------------------------------------------------
From: Tim Bradshaw <tfb@ed.ac.uk>
Looking up hostnames, IP numbers & so it can put things in wtmp.
Perhaps even looking up its own hostname so it can prompt you `foo
login:'. Anything that does a gethostby* is going to sit around while
the DNS server times out.
-------------------------------------------------------------------------------
Ric (<ric@rtd.com> "Ric Anderson", using RTD's public internet access)
As I recall rlogind is presented a remote host IP number and it
does a gethostbyaddr() on that to get the name to stick in /etc/utmpx.
If DNS is hosed, then you have to wait for the DNS timeout before
the gethostbyaddr returns "Not Found" and rlogind just sticks the
ascii version of the IP number in the remote host name slot.
-------------------------------------------------------------------------------
From: Andy_Feldt@phyast.nhn.uoknor.edu (Andy Feldt)
When you log in over the network, the system attempts to determine the
name of the remote host. A malformed DNS configuration should be expected
to be slow for this.
-------------------------------------------------------------------------------
From: Caspar Arquint <arquint@tau.inf.ethz.ch>
Don't really know a solution or explanation for your problem
because when ever it behaved like that it was a problem
looking the host name up in NIS or NIS+. But one hint to find
out what's going on is to start up `snoop <source host> <target host>'
and in another xterm you execute an rlogin to the target host.
You will then see the dns lookups and possible retries and the like.
-------------------------------------------------------------------------------
From: pars@sysadmin.sequel.net (Nazario R. Parsacala)
Can you send me a summary of the response that you will get.
I have the same problem ...
-------------------------------------------------------------------------------
From: Todd Michael Kennedy <tkennedy@galaxy.csc.calpoly.edu>
It really makes sense once you know the answer. Every time the resolver is
used, it goes through /etc/resolv.conf to connect to a DNS server. When the
addresses in resolv.conf are mangled, the resolver will still try to connect
to those IPs. (After all the resolver doesn't know the entries are bogus)
Since no DNS server exists at the mangled IP address, the resolver must
timeout before returning control to your program. (In this case, `login`)
And, with that long explanation, this is why you experience a long delay
when resolv.conf is mangled (long delay == timeout value) and no delay when
resolv.conf is correct. (short delay == quick DNS server)
Hope this all makes sense. I'm not always that clear when trying to explain
things to people.
-------------------------------------------------------------------------------
From: "Christopher A. Stewart" <allan@mazama.com>
Some modern shells try to get the remote hosts name.. Also, login will
try so it can put it in utmp.
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:30 CDT