|
|
SSH and DNSA short while ago, I noticed logging into crimson via ssh from other machines on my home network was occasionally very slow. I knew that the most common cause of delays in ssh were DNS issues, but (irrationally) I had a hard time believing this was the cause. I thought it more likely that my recent upgrade of crimson to FreeBSD 5.3 was the root of the problem. Well, that opinion was complete bollocks... The reason I suspected the upgrade of being the root cause was due to changes I had made to the kernel configuration. I had stripped everything out of the kernel and world that I did not need, by setting the following make variables in /etc/make.conf: # make.conf for CRIMSON # # Modification History: # Date Who # 20050311 mpw # Added options to prevent unused functionality being built # Added BATCH=true # build for i586 CPUTYPE=i586 # standard CFLAGS CFLAGS= -O -pipe # no profiled libraries NOPROFILE=true # just need a kernel - crimson uses no modules NO_MODULES=true # omit these elements from buildkernel/buildworld NO_BIND=true NO_IPFILTER=true NO_PF=true NO_AUTHPF=true NOATM=true NO_USB=true NO_LPR=true NO_ACPI=true NO_VINUM=true NO_BLUETOOTH=true NO_I4B=true NO_OBJC=true NO_FORTRAN=true NO_GPIB=true NO_SHAREDOCS=true NO_NIS=true # can't use AAAA queries against the Alcatel DNS NOINET6=true # Build ports in unattended mode BATCH=true # added by use.perl 2005-03-09 12:06:02 PERL_VER=5.8.6 PERL_VERSION=5.8.6 I had then found the following sshd error in the system log file for each ssh login: sshd[n]: login_getclass: unknown class 'root' Didn't seem to stop me logging in, but annoying just the same. After a little digging, I found someone else had reported the problem, which turned out to be due to the removal of NIS from the kernel via a custom /etc/make.conf. The default system /etc/nsswitch.conf settings assumed that NIS was present. By modifying the /etc/nsswitch.conf to the contents shown below, the sshd errors no longer occurred. # Modified by mpw # 18/05/2005 - remove nis from settings, as NO_NIS is specified in # /etc/make.conf group: files hosts: files dns networks: files passwd: files shells: files # original settings #group: compat #group_compat: nis #hosts: files dns #networks: files #passwd: compat #passwd_compat: nis #shells: files Back to the topic in hand... One evening, the delays in ssh were really significant, and continued to be reproducible for a long period of time. At last I had a chance to perform some diagnostics. Firstly, to convince myself that the problems were not DNS related, I put the IP addresses of the two machines I was testing into the /etc/hosts file, in order to ensure that DNS would not be used. Hmm, no delays when connecting via ssh. OK, I was convinced it must be a DNS issue. What puzzled me was that using nslookup to check the DNS servers seemed to work fine - no delays or errors were discernable. What was going on? I thought I ought to check that the DNS addresses provided by my ISP were correct. What do you know? They'd changed the addresses and omitted to tell me. Talk about impolite... To check that this was the problem, I hacked the new addresses into /etc/resolv.conf and, as if by magic, the delays disappeared. Obviously the old DNS addresses worked, but were a lot slower to react to the queries from sshd. All I had to do was change the DHCP server (an Alcatel Speedtouch 510) to send the new DNS addresses when giving out a DHCP address to the local network machines. See this article for details.
|