Why are my virtual interfaces all returning as the same address?

All interfaces return as 172.16.57.140???

$ netstat -nr

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
——————– ——————– —– —– —— ———
172.16.56.0 172.16.57.140 U 1 5 bge0:10
172.16.56.0 172.16.57.141 U 1 0 bge0:11
172.16.56.0 172.16.57.104 U 1 0 bge0:6
172.16.56.0 172.16.57.106 U 1 0 bge0:7
172.16.56.0 172.16.57.110 U 1 0 bge0:8
172.16.56.0 172.16.57.121 U 1 0 bge0:9
172.16.56.0 172.16.56.103 U 1 0 bge0
172.16.56.0 172.16.57.126 U 1 0 bge0:1
172.16.56.0 172.16.57.117 U 1 0 bge0:2
172.16.56.0 172.16.57.132 U 1 0 bge0:4
default 172.16.56.18 UG 1 15
127.0.0.1 127.0.0.1 UH 1 0 lo0

you will need to create an additional network or host route.

right now .10 has the priority. first match wins.

A host route trumps a network route
A network route will trump the default.

3.2: How to Add Static Routes

At any time, you can add static routes to your machine via the route command. The standard syntax for adding a network route is:

route add net "remote-network-ip gateway-ip" ‘hop-metric-count’

Diagnosing Network Connectivity Problems

The Symptom

You were working on the Internet and now suddenly you’re facing connectivity problems. Perhaps you can’t telnet out, you can’t ssh in, everything works except for the web server… what’s going on?

If at all possible, boil things down to two machines that won’t talk to each other during a given scenario. You want to be at one, and your buddy at the other; get real time communication happening between you, ideally on a portable phone.

FACT: If it was working, it can work again.

FACT: You might not have changed something, but something changed.

Consequently, your first goal is to find out where the change happened, then what it was, and finally how to put it back.

Start with the utterly obvious

* Is the wall supplying power?
* Does everything plugged in to the wall have power? Hubs and all.
* Is each device powered on?
* Is the evidence the device is operational, and not hung?
* If a network card, is it firmly seated into the CPU bus?
* Are all network cords where they belong?
* Are all the network cords plugged in firmly?

Start with problem machine

* Can you get physical access to the host that’s unreachable?
* Can anyone? It helps to have a remote partner.
* Ping a site that should always be up. like www.Google.com.
Can you get to some hosts but not others?
Yes, the problem is not at your local network.
No, check around your local machine’s network first.
* When you generate network traffic, does your ethernet light flicker?
No, suspect that you don’t have an interface up.
If using a laptop, did you boot docked/undocked correctly?
Yes, you’re sending packets.
* Can it reach the destination machine by using an IP address?
Yes, this may be a DNS problem.

Try an uninterested external machine

* Pick some external machine (let’s call it X) not involved in your communication crisis.
Can your problem host (call it machine A) see machine X?
Yes, your network if good; examine routing and firewall options.
No, examine hardware, cables, and local configuation.
* Can machine X see machine A?
If packets are flowing only half way, suspect your ethernet card needs replacing.
* Can the destination machine (call it B) see machine X?
Yes, the network is good, and machine X has services up.
* Can machine X connect to the destination machine (B)?
Yes, the network is good at machine B’s end and it is running services.
No, suspect the network at the destination machine.

Advanced stuff

* Put a network sniffer on the line. Connect through an Ethernet HUB, not a switch. If using a dual-speed hub, make sure your sniffer machine is at the same speed (10 or 100Mbps) as the machine you’re trying to troubleshoot — dual-speed hubs are actually 2-port switches! (Yes, it’s possible to mirror traffic on some managed switches to do network sniffing; if you know how to do this, your have no business reading this guide.)
Do you see your own outgoing traffic?
No, check your interface.
Yes, make sure that the ethernet card light blinks, as do intermediate hubs. Validate your traffic can be seen by other hosts.
* Do you see incoming traffic to you?
Yes, your card is working. Suspect the remote network.
No, check the local network, suspect the ethernet card.
* Do you see cross talk of traffic on the physical subnet intended for other machines?
Yes, your hardware is working.
No, focus on your local hardware and physical connection.

A NAME="interface">
Ping another host
For Linux, use:
# /bin/ping -v host

For Windows, use:
C:\> ping -t host

The idea is to keep a continuous ping going so that you can see if the other side is responding or not. You may want to use a firewall to see if your requests are getting out and a response is coming back. If you’re only seeing half the traffic, suspect your network card and substitute another in and see what happens. If you are seeing no traffic, examing your routing tables. If you are seeing the traffic, but other kinds of traffic aren’t making it through on different ports, it’s time to suspect a firewall.

Note: some firewalls block ping traffic, considering it a probe to see which machines are answering. You may want to use another service, such as telnet.

Perform a traceroute
For Linux, use:
# /usr/bin/traceroute -n host

For Windows, use:
C:\> tracert -d host

Start by supressing name resolution, as shown above, otherwise DNS problems can look like a lot like slow/no connectivity. Plus when the DNS server is broken, lookups won’t work.

You are looking to see that you can make it from host all the way to another. Long delays, high turn around times, indicate network congestion. Asterisks indicate a host is not responding, or that the firewall isn’t allowing ICMP packets through (you’ll have to try telnet or something else).

If you notice a circular pattern where host A hops to host B, and host B hops back to host A, then someone along the way has a problem with their routers; unless it’s your ISP (who you should call and report this to), there’s not much you can do but wait it out — assume they are aware of it. Most likely their router tables haven’t propagated correctly.

Circular routing often indicates that an endpoint acess router is down and the two upstream routers don’t know where to send the packet since the dynamic route associated with the downed connection has gone away.

If instead the traceroute dies at a particular point, try other hosts serviced by that ISP. The very clever can use whois (or Sam Spade) and ping and try to derive some IP numbers to try. It may be an ISP is down from some reason.

Telnet to another host
For Linux, use:
# /bin/telnet host 23

For Windows, use:
C:\> telnet host 23

Port 23 is the port for logging in. If a host doesn’t allow logins, you can also try port 25 (the mail program) – if the host responds with any text, enter QUIT and hit return. You can also try port 80, if the connection is made you won’t see an error message and instead the system will wait for input (and it may not echo it); enter GET / and hit return. If you see text and are disconnected, you made a connection.

Concerning port 80, a lot of ISPs are using transparent proxy devices, which cache traffic destined for port 80. Same for port 25 (as an anti-spam measure). You’ve got to read the output to make sure you’re talking to the host you intend.

IMPORTANT: If you can make a connection to the remote host and get a reply on any port, then your problem is not connectivity, but firewall rules.

If you suspect a port should be responding, but looks like it isn’t, then try connecting to it from the localhost first. Do this by using the machine’s IP address or 127.0.0.1. Additionally, you may wish to see which services are listing.

Check your Interface
For Linux, use:
# /sbin/ifconfig -a

For Windows, use:
C:\> ipconfig /all

You’re looking to make sure that you have an interface defined for your ethernet, that it has a hardware address (MAC), that the internet address is defined, that there is a broadcast address, and a mask.

Quite often the interface will report metrics, such as how many packets, errors, dropped, overruns, etc. there were.

If you are sending, but not receiving, or receiving, but not sending, be suspicious of your network card; consider replacing it with another and see if the problem goes away.

High errors suggest a faulty line or cable. Too many overruns may mean you have too much on this leg and need to subnet your traffic. Too high of a drop count suggests that a router between you and the other guy is swamped with traffic (or is trying to convert between 10Mbs and 100Mbps) and needs more ram for a large buffer.

Dumping the Routing Table
For Linux, use one of these:
# /sbin/route -n
# /bin/netstat -ar

For Windows, use:
C:\> route print

What you are looking for is that you have a routing table defined, and that the default route points to a gateway, and that the gateway is reachable.

You should be able to ping your gateway.

Dumping the ARP Table
For Linux, use:
# /sbin/arp -n

For Windows, use:
C:\> arp -a

The ARP tables should so the explict MAC address (and corresponding IP address) of any network cards on the physical local subnet. If you can see other machines in this list, besides your own, your network card is functional, and you may have a routing problem.

You can get a general broadcast to all machines on your local subnet by doing a ping 255.255.255.255. This sends a generic message out to every card physically on the same wire and asks them to respond; so you will get duplicate messages. If ping complains, you may need to try a network address or provide an additional switch option on the command line.

Note that broadtcast pings don’t work on all machines/operating systems. Additionally, it often requires root privileges to do it.

Note that HUBs will pass along broadcasts, bridges, switches, routers, and firewalls most likely will not. If you see limited traffic, expect that you have networking hardware to take into account too. Usually if networking hardware is acting up, then all machines on the same physical wire will misbehave in the same way. Do they? If it’s isolated, then suspect the firewall.

Which services are listening
For Linux, use:
# /bin/netstat -an

For Windows, use:
C:\> netstat -a

You’ll see a list that shows your machine at the port it’s listening on (LISTENING), and optionally a connected machine and the port it is using (ESTABLISHED). The status of TIME_WAIT means that a port disconnected and it’s waiting an established period of time before making the port reallocated for use. If you see a lot of TIME_WAIT, you may be under a denial of service attack.

If you see a connection, but do not recognize the port in use, you can interrogate the system as to which process is using it.

The handle tool, from
www.sysinternals.com,
can provide "lsof"-like
functionality under Windows.
List Open Filehandles
For Linux, use:
# /usr/local/sbin/lsof -i :portnumb

Unfortunately, I know of nothing that allows this from Windows.

Even still, the lsof program is not a "standard" Linux utility and must be obtained from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/.

The utility has to be compiled for the particular version of the kernel, since it needs to know how to peek inside the kernel structures (which can and do change).

More often than not, the port number will be listed in /etc/services or be that of an application you installed.

If not, suspect that your system may have an intruder. Head over to www.freshmeat.net and do a search for rootkit to find the latest rootkit detection software.

Whois Services
For Linux, use:
# /usr/bin/whois domainname

WHOIS will tell you who owns the domain, and what name servers are responding. It’s possible that DNS is not operating or is pointing to the wrong machine.

Be sure to use a domain name (foobar.com) rather than a host name (www.foobar.com).

If you are using Windows, another useful toois Sam Spade; it gives you easy access to netblock owner information.

DNS Look Up
For Linux, try any of these options:
# /usr/local/bin/dig host
# /usr/local/bin/dig @dnsserver host
# /usr/local/bin/host host
# /usr/local/bin/nslookup host

For Windows, use:
C:\> nslookup hostname

You can specify either a hostname or an IP address, this will ask the domain name server(s) if they know about the machine. A machine should always respond to it’s IP address, but may not always be listed in DNS. Furthermore, many names may alias back to a single IP address. For this reason, a name may resolve to an IP address, but the IP address may not resolve back to the same name.

If your connection works with an IP address but not with the hostname, then it’s very likey either the DNS server isn’t responding, is populated with bad data, doesn’t have the host listed, the cache has expired, or the negative cache has not expired (DNS machines keep track of which names have no known IPs when you ask them).

Note that nslookup is becoming very obsolete, and that dig and host is the replacement; it does more, better.

Ethernet Sniffer
For Linux, try:
# /usr/local/sbin/tcpdump

There are a number of tools, including snort and ethereal which also capture and display traffic.

The goal is to see if you see any traffic, ideally two way. First from anywhere (such as other machines on the local physical subnet), then from and destined to you, finally over the port your interested in.

Note that you may have to provide various filters, like grep, in order to see just the traffic you’re really interested in.

Change MTU of network interface

Change MTU (Maximum Transmission Unit) of network interface

Maximum Transmission Unit(MTU), the largest physical packet size, measured in bytes, that a network can transmit. Any messages larger than the MTU are divided into smaller packets before being sent.By optimizing the MTU setting you can gain substantial network performance increases, especially when using dial-up modem connections.

Default MTU Size for Different Network Topology
Network MTU(Bytes)
16 Mbit/Sec Token Ring 17914
4 Mbits/Sec Token Ring 4464
FDDI 4352
Ethernet 1500
IEEE 802.3/802.2 1492
X.25 576

To change the MTU of an interface on GNU/Linux, you just need to tell ifconfig to do so, like this for example:

#/sbin/ifconfig eth0 mtu 1492

To change it permanently on Debian, put it in the /etc/network/interfaces file .where almost all network parameters are found. To do this, just add a line mtu to the definition of your interface and save the file.

Example

iface eth0 inet static
address 192.168.0.1
network 192.168.0.0
gateway 192.168.0.254
netmask 255.255.255.0
mtu 1492

Warning: the following is mostly obsolete in Debian Sid and Etch

It seems that the dhcp clients are not configured by default to do the same for dynamically assigned configurations . So, you need to use a tweak to achieve the same. We’re going to use the pre-up feature of /etc/network/interfaces like this:

iface eth0 inet dhcp
hostname “mymachine”
name LAN Interface
pre-up /sbin/ifconfig $IFACE mtu 1492

More common Recommended Values

Dial-up Connections – 576 Bytes
PPPoE Broadband Connections – 1492 Bytes
Ethernet, DSL and Cable Broadband Connections – 1500 Bytes

How-to: Secure a Wireless LAN

How-to: Secure a Wireless LAN

Take your mouse and hover it over the Wifi icon in the bottom right of your computer screen. Go ahead, do it. It will show you the name of your wireless network. If you’re like 80% of Wifi users, the wireless network you are connected to is titled something like, "Linksys (Unsecured)" or "Default (Unsecured)".

An unsecured wireless network is an open invitation to hackers to walk right in to your computer and steal your personal information, upload malware onto your computer, and otherwise terrorize you.

Thankfully, securing your Wifi connection is extraordinarily simple to do. In this article we cover 10 simple steps that will take your wireless network from being a welcome beacon to hackers to the wi-fi equivalent of Fort Knox. So let’s get started…

Changing Administrator Passwords and Usernames

After you’ve taken your Wifi router out of the box and started the setup process, you will be asked to sign on to a specific webpage and are required to enter information such as your network address and account information. In theory, this Wifi setup page is protected with a login screen (username and password).

The Problem: Though the username and password are intended to allow only you to get access to your Wifi setup and the personal information you have entered, the fact remains that the logins provided are usually given to everyone with the same model router, and because most people never change them, they remain an easy target for hackers and identity thieves. In fact, there are sites that list the default usernames and passwords for wireless routers, making a hackers job even easier.
http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php

The Solution: Change the username and password for your Wifi setup immediately after the first login. And if you are going to spend the time changing your password, make sure it is difficult to guess. Your name, birth date, anniversary date, child’s name, spouse’s name, or pet’s name are going to be among the hacker’s first guesses. And because many hackers use a technique called ‘dictionary hacking,’ (running a program that tries common English words as passwords) you should make sure that your password isn’t just a common English word, but rather is a combination of letters and numbers.

Upgrading your Wifi Encryption

If the information sent back and forth over your Wifi network isn’t adequately encrypted, a hacker can easily tap into the network and monitor your activity. When you type personal or financial information into a web-site, that hacker can then steal that information and use it to steal your identity.

The old encryption standard Wired Equivalent Privacy (WEP) can be hacked within 30 seconds, no matter the complexity of the passphrase you use to protect it.
http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
Unfortunately, millions of Wifi users are still using WEP encryption technology to encrypt their information, despite the availability of the vastly superior WPA2 encryption standard.
http://en.wikipedia.org/wiki/WPA2

The Problem: Despite the superior encryption protection that WPA2 provides, most Wifi home users have failed to upgrade their protection because they were unaware of the problem, or simply felt overwhelmed by the technical prospects of upgrading. As a result, many continue to use WEP encryption, which is now so simple to hack that it is widely regarded as little better than no encryption at all.

The Solution: The solution, of course, is to upgrade your Wifi encryption to WPA2. But before you can add WPA2 protection, you will have to complete a few steps in order to update your computer. The first step is to download and install Microsoft’s WPA2 hotfix for Windows XP. http://www.microsoft.com/downloads/details.aspx?FamilyID=662bb74d-e7c1-48d6-95ee-1459234f4483&displayLang=en
You will also likely need to update your wireless card driver. These updates, if needed, will be listed in Microsoft’s Windows Update page under the subheading "Hardware Optional". http://update.microsoft.com

Now that your computer and wireless card are up to date, you will need to log into your router’s administration page through your web browser (this is the page you signed into in order to setup theWifi router the first time you opened it up, the specific URL can be found in your router’s instruction manual.) Once signed in, change the security settings to "WPA2 Personal" and select the algorithm "TKIP+AES". Finally, enter your password into the "Shared Key" field and save your changes.

Changing the Default System ID

When you got your Linksys or D-Link router home from the store and set it up, it came with a default system ID called the SSID (Service Set Identifier) or ESSID (Extended Service Set Identifier). This ID is also commonly referred to as the name of your Wifi setup.

The Problem: Usually, manufacturers assign identical SSID sets to their devices, and 80% of Wifi home users leave their system on the default setting. So that means that 80% of homes have Wifi systems titled, "Default" or "LinkSys" or whatever your provider sets as the default name.

The problem with these default settings is that they serve as strong signals to hackers who have been known to just cruise neighborhoods looking for Wifi networks with default names to hack into. Though knowing the SSID does not allow anyone to break into your network, it usually indicates that the person hasn’t taken any steps to protect their network, thus these networks are the most common targets.

The Solution: Change the default SSID immediately when you configure your LAN. This may not completely offer any protection as to who gains access to your network, but configuring your SSID to something personal, e.g. "The Smith House Wifi Network", will differentiate you from other unprotected networks, and discourage hackers from targeting you. As an added bonus, having a Wifi network with a unique name also means that neither you or your family will make the mistake of connecting through a neighbor’s Wifi network, and thus exposing your computers through their unprotected setup.

MAC Address Filtering

If you’ve had an unsecured Wifi setup in your home in the past, you can be fairly certain that at least one of your neighbors is mooching off your Wifi to connect to the internet. While everyone loves a friendly neighbor, providing an easy resource for others to steal internet access is morally and legally questionable, but even scarier is the harm those moochers can do to your computer.

In order to check who has been using your network, you’ll need to check the MAC address. Every Wifi gadget is assigned a unique code that identifies it called the "physical address" or "MAC address." Your wi-fi system automatically records the MAC addresses of all devices that connect to them. But busting your internet stealing neighbors isn’t all that MAC addresses are good for, they can actually be a great help in securing your WLAN.

The Problem: You are not sure who or what is accessing and endangering your wi-fi network, and once you find out that someone or something is mooching off your network, you want to stop them. But how?

The Solution: Checking the MAC address long for your wi-fi network will give you a quick view of all the devices accessing your network. Anything that isn’t yours, you will want to keep out. To do this, you will need to manually key in the MAC addresses of your home equipment. This way, the network will allow connections only from these devices, so your mooching neighbors will be out of luck. Caution: This feature is not as powerful as it may seem. While it will stop your average neighborhood moocher or amateur hacker, professional hackers use advanced software programs to fake MAC addresses.

Stop Publicly Broadcasting your Network

By now you’ve renamed your Wifi so that hackers won’t see the default name as they sweep for unprotected Wifi setups. But wouldn’t it be even better if hackers and curious neighbors didn’t know you had a Wifi setup at all? Usually, your access point or router is programmed to broadcast the network name (SSID) over the air at regular intervals. While broadcasting is essential for businesses and mobile hotspots to let people find the network, it isn’t needed at home, so eliminate it.

The Problem:Why broadcast to the world that you have a wireless connection? You already know it; why do strangers need to know? For most personal uses, you are better off without this feature, because it increases the likelihood of an unwelcome neighbor or hacker trying to log in to your home network. The broadcast works like an invitation to the hackers who’re searching for just that opportunity.

The Solution: Most Wifi access points allow the SSID broadcast feature to be disabled by the network administrator. If you are using a Linksys router, instructions to disable your SSID broadcast are here, and for those of you using D-Link, your instructions are here (See Figure 1.6 on page 4). Otherwise, you will need to check the manual for your hardware for specific instructions on how to disable broadcasting for your router.

Auto-Connect to Open Wifi Networks?

Most computers provide a Wifi setting that will configure your computer to automatically connect to any open Wifi network without notifying you. While this setting isn’t the default, many individuals select the setting because it makes connecting faster when you are traveling, or connecting at a friend’s house. Even more common, is to have selected ‘connect automatically’ to networks that you regularly connect to. Again, this makes sense, as most people do not want to have to manually type in the name of their wireless network and the password each time they want to sign in at home. Unfortunately, both wi-fi setups can cause major security problems.

The Problem: If you connect to every available Wifi network automatically, you will inevitably end up connecting to dummy Wifi networks designed specifically to catch unsuspecting users and hack their computers.

Similarly, if you automatically connect to your regular Wifi networks (meaning you don’t manually type in your network name and password every time) then you may be setting yourself up for a security breach. That is because 80% of Wifi users have not changed the name of their wireless connection. Therefore, it is very easy for a hacker to create a dummy network entitled "Linksys" or "Default", then sit back and watch 80% of computers automatically connect to the network since it has a ‘trusted’ name.

The Solution: Never select the ‘connect to available Wifi networks automatically’ setup option under your Network Connections window. If you don’t want to have to manually type in the name and password to your Wifi connection each time you sign in (the safest option), at least make sure that you have named your Wifi connection something unique, and that you eliminate all generic titled networks from your ‘preferred networks’ list. That way, you won’t get automatically connected to dummy Wifi networks setup by hackers and given the names, "Default" or "Linksys".

You’ve got a built-in firewall, so use it

Your IT security needs to use a layered approach. While no single layer of your security is enough to withstand every attack, adding layers to your security will help ensure that spyware and malware are kept out. Two important security layers are the router firewall and your individual PC’s firewall.

The Problem: Routers come with built-in firewall capability. However, since there is an option to disable them, they can often be accidentally turned off by someone toggling options.

The Solution: Ensure that your router’s firewall is enabled, along with related built in security featured which block anonymous internet requests or pings. This extra step will help hide your network’s presence to the internet, and thus help protect your network. After all, it’s harder for hackers to infiltrate what they can’t find.

Positioning of the Router or Access Point

Wifi signals don’t know where your house ends and where your neighbor’s begins. This Wifi signal leakage gives hackers and neighbors the opportunity to find your wireless network and attempt to access it.

The Problem: While a small amount of overflow outdoors is not a problem, it is important to keep this leakage to a minimum. This is important because the further your signal reaches into the neighborhood, the easier it is for others to detect and exploit.

The Solution: If you haven’t yet installed your wireless home network, make sure to position the router or access point in the center of the home rather than near windows or doors. If you live in an apartment, consider that a Wifi network is restricted in part based upon the materials that it must pass through, the more walls, doors, and metal the signal passes through, the weaker it is. So if your goal is to reduce leakage, you might consider mounting your Wifi in a closet in order to reduce signal strength.

When to Turn Off the Network

Most of us know that it is impractical to constantly turn devices on and off. Having a Wifi connection is in large part a device of convenience, and having to turn it off every time you aren’t using it, eliminates much of that convenience. Unfortunately, a Wifi connection is vulnerable when it is on; therefore shutting off your wireless signal when not in use would be a huge boon to its security.

The Problem: There is an inherent tension between convenience and security in deciding whether to turn off a wireless access point between connections.

The Solution: Just as you take extra home security measures when taking a vacation, like asking your neighbors to pick up the mail and leaving a light on, so also should you take extra Wifi security measures when your network will not be in use for expended periods of time. Shutting down the network is a basic but effective security measure that can protect your network when you are not around to protect it, and hackers may take the opportunity to mount their attack.

Putting your Improvements to the Test

Now that you’ve made all these changes to your Wifi setup, it would be nice to know that you are secure. Unfortunately, the only surefire test for how secure you are is to wait to see if you get hacked. Trial by fire is no way to test your security, however, so thankfully there is a program to help audit your Wifi security.

The Problem: There is no way for the average home Wifi user to know if the changes they made to upgrade their wireless security will really prove successful in keeping them safe.

The Solution: The Netstumbler utility, by Marius Milner will both determine your network’s vulnerabilities and unauthorized access points. In addition to these security concerns, the downloadable program will also reveal the sources of network interference and weak signal strength, so that you can improve the strength of your wi-fi signal. Netstumbler is free for download, although the author asks that those who find the tool helpful make a donation to support the creation of future utilities.
http://www.pcworld.com/downloads/file/fid,23439-order,1-page,1-c,alldownloads/description.html?findid=51212#

backup Windows XP to Ubuntu, using rsync

How to regularly backup Windows XP to Ubuntu, using rsync

Set up rsync server on Ubuntu
—————————–

1. Run sudo apt-get install rsync (it’s probably already installed)
2. Create a file named rsyncd.conf in /etc
1.

sudo nano /etc/rsyncd.conf

2. Add the following to rsynd.conf, replacing all instances of username with your Ubuntu username:

[usernamebackup]

path = /home/username/backup
comment = Backup
uid = username
gid = username
read only = false
auth users = username
secrets file = /etc/rsyncd.secrets

3.

sudo chmod 644 /etc/rsynd.conf

3. Create a file named rsyncd.secrets in /etc
1.

sudo nano /etc/rsyncd.secrets

2. Add the following to rsyncd.secrets, replacing username with your username and password with a password of your choosing:

username:password

3.

sudo chmod 600 /etc/rsyncd.secrets

4. Open rsync port by editing /etc/default/rsync and setting

RSYNC_ENABLE=true

5. Restart rsync

sudo /etc/init.d/rsync restart

Set up rsync client on Windows
——————————

1. Install Cygwin, making sure Editors > nano and Net > rsync are selected
2. Add C:\cygwin\bin; to the Windows PATH statement
1. Right-click on My Computer and select Properties
2. Switch to the Advanced tab and click the Environment Variables button at the bottom
3. Find the “Path” or “PATH” variable in the System variables list at the bottom and click Edit
4. Add C:\cygwin\bin; to the beginning of the list
3. Create secret file to store password in Cygwin
1. Start Cygwin Bash Shell
2. Create secret file in the filesystem root and enter only the password in rsyncd.secrets above, with no spaces or line breaks

nano /secret

3.

chmod 600 /secret

4.

chown Administrator:SYSTEM /secret

4. Create bat file to run rsync
1. Open Notepad and enter the following command, replacing User Name with your Windows User Name directory, username with your Ubuntu username, and ipaddress with the IP address of your Ubuntu server (e.g. 192.168.0.100):

C:\cygwin\bin\rsync.exe -qrtz –password-file=c:\cygwin\secret –delete "/cygdrive/c/Documents and Settings/User Name" username@ipaddress::usernamebackup

As you may have guessed, the "/cygdrive/c/Documents and Settings/User Name" command line option designates where to start backing up from. As currently configured, this will backup your Windows home directory (Desktop, My Documents, etc). If you want to backup your whole hard drive, change that option to "/cygdrive/c".
2. Save the file as C:\rsync.bat

Create scheduled task to run C:\rsync.bat once a day
—————————————————-

1. Create scheduled task
1. Goto Start > Programs > Accessories > System Tools > Scheduled Tasks
2. From the File menu, select New > Scheduled Task
3. Name this task “rsync backup”
4. Right-click on the task and select properties
5. Enter C:\rsync.bat in the Run field
6. Switch to the Schedule tab and select the time you want the backup to run every day and click Ok
2. Test the scheduled task
1. Create a folder called C:\data and put a few photo files in it
2. Edit C:\rsync.bat and change "/cygdrive/c/Documents and Settings/User Name" to "/cygdrive/c/data"
3. Add the command pause on a new line at the bottom of C:\rsync.bat and save the file
4. Right-click on the “rsync backup” scheduled task and select “Run”—A command window should popup and with either errors or the list of files being transfered. If there are errors, troubleshoot them.
5. Once the scheduled task and C:\rsync.bat appear to be working correctly, change "/cygdrive/c/data" back to "/cygdrive/c/Documents and Settings/User Name" and remove the pause command
6. Finally, edit the scheduled task properties and change “Run as:” to NT AUTHORITY\SYSTEM—this will ensure that the process runs in the background, without popping up a command prompt window

Run your first backup
———————

Run C:\rsync.bat from the command line before going to bed. Backing up 35GB over a wireless-g connection took me over 8 hours. Subsequent backups take less than a minute. Behold the beauty of rsync.

Solaris IPMP

IPMP or IP multipathing is a way to make your Network interface cards redundant, just like bonding with Linux.

##############################################################
# Solaris IP- Multipathing #
# 20060901 #
# adapted from #
# http://docs.sun.com/app/docs/doc/816-4554/6maoq027h?a=view #
##############################################################

IP Multipathing or IPMP is similar to Networkcard (NIC) bonding with Linux.
You can put the Network Interfaces into groups where the Logical interfaces can
switch between all interfaces within one group. Solaris has several methods to
detect a failure.

Note: Solaris names the NICs according to the used driver. I will only use
NICs named ce0 and ce1, please modify this information for you network
interfaces.

In this HowTo I assume, that you have just set up you box, 2 network interface
cards installed and just 1 IP Address configured.

You can use private and unroutable addresses as test-addresses. Solaris just
uses them to determine, whether the link is up. In this example I use
192.168.50.2 and 192.168.50.3 with netmask 255.255.255.0
CAUTION: Some switches can be configured to block data from some Networks (e.g. private IPs). This will prevent IPMP from working!

#####################
#### Enable IPMP ####
#####################

Note: You can choose the name of your IPMP-group freely, it just has to be the
same for all members of one group.

1. Put all logical interfaces (IP Adresses) into /etc/hosts and
/etc/inet/ipnodes

2. Add you network to the /etc/netmasks file.
Note: Don’t forget to add the netmask for the test-addresses.

3. Modify the /etc/hostname.ce0 file.
This file should contain the hostname of your box. Change it to:
[IP- address] + netmask + broadcast group [IPMP-group] up

4. Plumb the second interface
ifconfig ce1 plumb

5. Add a testaddress to your primary NIC.
Add to /etc/hostname.ce0
"addif 192.168.50.2 + netmask + broadcast + deprecated -failover up"

Note: Put all information in one line!

6. Configure your second interface with a testaddress:
Add to /etc/hostname.ce1
"192.168.50.3 netmask + broadcast + deprecated group [IPMP-group]
\ -failover standby up"

Note: If you want to use your second interface for additional logical
interfaces, don’t use the "standby" option.

7. Reboot your box
IMPORTANT!: I tried to activate this setup on a running box, once and
lost all connections to all network interfaces on this box. So please
be sure you can access the OS on a different way. (KVM, Console)

Note: While there are other ways to activate the new Interfaces, this
seems to be the easiest of them.

How to setup your very own zone!

How to setup your very own zone!

The first step here is to get a piece of hardware to test with. You can use an Intel or AMD Opteron unit or a UltraSparc server. For my testing and playing I choose one of many Netra T1 UltraSparc units that I have in a rack. I download the CDROM ISO files from Sun. I then use lofiadm and a few other steps to create a jumpstart server for network booting. Simply put, I did the entire process remotely, from home, with a laptop and a modem. Like I said, Solaris is really slick.

Most admins that work with Solaris are very aware of how to boot a server from across the net and perform an install. That is what I did.

After the initial install of Solaris 10 build 51 I had the following config here at blastwave.org :
bash-2.05b# uname -a
SunOS zoner 5.10 s10_51 sun4u sparc SUNW,UltraSPARC-IIi-cEngine

bash-2.05b# prtconf -v | grep Memory
Memory size: 320 Megabytes

The file system layout looks like so :

bash-2.05b# df -ak
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t0d0s0 371137 74357 259667 23% /
/devices 0 0 0 0% /devices
/dev/dsk/c0t0d0s6 3009594 1708386 1241017 58% /usr
proc 0 0 0 0% /proc
mnttab 0 0 0 0% /etc/mnttab
fd 0 0 0 0% /dev/fd
/dev/dsk/c0t0d0s1 740495 73752 607504 11% /var
swap 1262208 48 1262160 1% /var/run
swap 1262160 0 1262160 0% /tmp
/dev/dsk/c0t0d0s5 1375228 693 1319526 1% /opt
/dev/dsk/c0t0d0s7 2055705 30 1994004 1% /export/home
-hosts 0 0 0 0% /net
auto_home 0 0 0 0% /home
zoner:vold(pid489) 0 0 0 0% /vol

That would be because I chose an old fashioned way of doing things and I split up my basic filesystems across the primary boot disk.

bash-2.05b# isainfo -v
64-bit sparcv9 applications
32-bit sparc applications

$ ifconfig -a
lo0: flags=1000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=1000843 mtu 1500 index 2
inet 192.168.35.200 netmask ffffff00 broadcast 192.168.35.255
hme1: flags=1000843 mtu 1500 index 3
inet 192.168.35.201 netmask ffffff00 broadcast 192.168.35.255

bash-2.05b# psrinfo -v
Status of virtual processor 0 as of: 02/26/2004 10:30:42
on-line since 02/25/2004 23:13:02.
The sparcv9 processor operates at 360 MHz,
and has a sparcv9 floating point processor.

Notice anything new there? It says "virtual processor". Virtual? Seems pretty real to me. Toto, I don’t think we’re in Kansas anymore.

No indeed. We are, in fact, in a the "global zone" of Solaris 10. The zoneadm tool confirms this :

bash-2.05b# zoneadm list -vc
ID NAME STATUS PATH
0 global running /

It is here in the new global zone that we will create our other zones for applications and for users. If we need to isolate an application or a user group from the rest of the world then we simply create a zone for them and then let them run. Simple concept but how do we do it?

The first thing that I do is create a filesystem area for the new zone to reside in. I also mount it under a mount point named /zone/1 and I ensure that only the root user has access to it thus :

$ ls -lap /zone
total 8
drwxr-xr-x 3 root other 512 Feb 26 12:42 ./
drwxr-xr-x 22 root root 512 Feb 26 12:42 ../
drwx—— 5 root root 512 Feb 26 13:27 1/

We use zonecfg to create a new zone. Do this from the global zone and as the root user.

bash-2.05b# zonecfg -z zone1
zone1: No such zone configured
Use ‘create’ to begin configuring a new zone.
zonecfg:zone1> create
zonecfg:zone1> set zonepath=/zone/1
zonecfg:zone1> set autoboot=true
zonecfg:zone1> add net
zonecfg:zone1:net> set address=192.168.35.210
zonecfg:zone1:net> set physical=hme1
zonecfg:zone1:net> end
zonecfg:zone1> info
zonepath: /zone/1
autoboot: true
pool:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
net:
address: 192.168.35.210
physical: hme1
zonecfg:zone1> verify
zonecfg:zone1> commit
zonecfg:zone1> ^D

Simple really. The zonecfg tool is interactive and I specified that I want to "create" a zone. The filesystem that I created is the new "zonepath" and I want this new virtual server to boot along with the global zone when the "real" server boots. Who can tell what is "real" and what isn’t? It won’t matter anymore. I also set the ip address for the zone as well as the interface to bind to. Finally I asked for zonecfg to show me what I just did via the simple "info" command. I then used "verify" and "commit" to ensure that the config is complete. That is all. Nothing fancy.

I then used zonecfg and zoneadm to verify that in fact what I had just done was in fact, er, well, done. Really I just like playing with new technology and so will you!

bash-2.05b# zonecfg -z zone1 info
zonepath: /zone/1
autoboot: true
pool:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
net:
address: 192.168.35.210
physical: hme1

bash-2.05b# zoneadm list -vc
ID NAME STATUS PATH
0 global running /
– zone1 configured /zone/1

The next step to perform is to "install" the zone.

bash-2.05b# zoneadm -z zone1 install
Preparing to install zone .
Creating list of files to copy from the global zone.
Copying <2521> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <808> packages on the zone.
Initializing package <7> of <808>: percent complete: 0%
.
. < this goes on for some time >
.
Initialized <808> packages on zone.
Successfully initialized zone .

bash-2.05b# df -ak /zone/1
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t1d0s0 1972734 76238 1797860 5% /zone/1

Again I use zoneadm to see the results of my actions :

bash-2.05b# zoneadm list -vc
ID NAME STATUS PATH
0 global running /
– zone1 installed /zone/1

See that? The STATUS is now "installed".

Now lets boot that new virtual server that we created!

bash-2.05b# zoneadm -z zone1 boot
bash-2.05b# zoneadm list -vc
ID NAME STATUS PATH
0 global running /
2 zone1 running /zone/1

I now have a virtual server running? Really? Let’s ping it :

bash-2.05b# ping 192.168.35.210
192.168.35.210 is alive

For our further enjoyment let’s nmap port scan it from another server :

# nmap -sS -O -v -v -P0 -T Aggressive -n -oN /tmp/zone1.log zone1

Starting nmap 3.20 ( www.insecure.org/nmap/ ) at 2004-02-26 14:12 EST
Host 192.168.35.210 appears to be up … good.
Initiating SYN Stealth Scan against 192.168.35.210 at 14:12
The SYN Stealth Scan took 443 seconds to scan 1611 ports.
Warning: OS detection will be MUCH less reliable because we did not find at least 1

open and 1 closed TCP port
All 1611 scanned ports on 192.168.35.210 are: closed
Too many fingerprints match this host for me to give an accurate OS guess
TCP/IP fingerprint:
SInfo(V=3.20%P=sparc-sun-solaris2.8%D=2/26%Time=403E474B%O=-1%C=1)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=N)
PU(Resp=N)

Nmap run completed — 1 IP address (1 host up) scanned in 551.944 seconds

As far as anyone can tell, there is a server out there at the required IP address but how do we actually use it?

We now need to login to the zone console via zlogin. When we do we will be presented with the opportunity to "setup" the new server as if we were doing an install only there really isn’t much to install or setup for that matter. The hard work has been done for us :

I now will use zlogin to login to the zone1 console and I will specify

# zlogin -C -e\@ zone1
[Connected to zone ‘zone1’ console]

This is where we are presented with an install sequence that is familiar to all Solaris admins. After you answer the basic config questions for your new virtual server you will see that the virtual server boots :

[NOTICE: zone rebooting]

Version s10_51 64-bit
Copyright 1983-2004 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Hostname: zone1
The system is coming up. Please wait.
starting rpc services: rpcbind done.
syslog service starting
SunOS Release 5.10 Ver
prtconf: devinfo facility not available
prtconf: devinfo facility not available
prtconf: cannot open /dev/openprom: No such file or directory
prtconf: cannot open /dev/openprom: No such file or directory
prtconf: devinfo facility not available
Creating new rsa public/private host key pair
Creating new dsa public/private host key pair
The system is ready.

zone1 console login:

zone1 console login: root
Password:

Feb 27 09:03:55 zone1 login: ROOT LOGIN /dev/console
Sun Microsystems Inc. SunOS 5.10 s10_51 May 2004
#

There you have it! A new virtual server has been born. This new server is neatly wrapped inside the global zone. I don’t have another way to describe it really. Perhaps it is "beside" or "outside". Does it matter? Not really. The new server has a hostname zone1 ( for the sake of simplicity ) but I could have made the main hostname jupiter and the new zone io or europa. The new server is reachable via the net. I run ps -ef and see the usual suspects in place and running :

# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 7530 7424 0 09:01:46 ? 0:00 /usr/sbin/inetd -s
daemon 7451 7424 0 09:01:45 ? 0:00 /usr/lib/crypto/kcfd
root 7516 7424 0 09:01:46 ? 0:00 /usr/lib/autofs/automountd
root 7667 7653 0 09:04:18 console 0:00 ps -ef
root 7424 7424 0 09:01:33 ? 0:00 zsched
root 7521 7424 0 09:01:46 ? 0:00 /usr/sbin/cron
root 7515 7424 0 09:01:46 ? 0:00 /usr/sbin/syslogd
root 7653 7427 0 09:03:30 console 0:00 -sh
root 7588 7424 0 09:02:49 ? 0:00 /usr/lib/im/htt -port 9010 -syslog -message_locale C
root 7427 7424 0 09:01:44 ? 0:00 init
root 7652 7427 0 09:03:30 ? 0:00 /usr/lib/saf/sac -t 300
root 7526 7424 0 09:01:46 ? 0:00 /usr/sbin/nscd
root 7656 7652 0 09:03:30 ? 0:00 /usr/lib/saf/ttymon
root 7641 7424 0 09:02:52 ? 0:01 /usr/sfw/sbin/snmpd
root 7568 7424 0 09:02:49 ? 0:00 /usr/lib/utmpd
smmsp 7658 7424 0 09:03:49 ? 0:00 /usr/lib/sendmail -Ac -q15m
daemon 7476 7424 0 09:01:45 ? 0:00 /usr/sbin/rpcbind
root 7605 7588 0 09:02:50 ? 0:00 htt_server -port 9010 -syslog -message_locale C
root 7636 7424 0 09:02:51 ? 0:00 /usr/dt/bin/dtlogin -daemon
root 7657 7424 0 09:03:49 ? 0:00 /usr/lib/sendmail -bd -q15m
root 7655 7424 0 09:03:30 ? 0:00 /usr/lib/ssh/sshd
#

The filesystems look a bit odd in that they are not actually associated with disk devices or metadevices :

# df -ak
Filesystem kbytes used avail capacity Mounted on
/ 1972734 76154 1797944 5% /
/dev 1972734 76154 1797944 5% /dev
/lib 371137 74367 259657 23% /lib
/platform 371137 74367 259657 23% /platform
/sbin 371137 74367 259657 23% /sbin
/usr 3009594 1708386 1241017 58% /usr
proc 0 0 0 0% /proc
mnttab 0 0 0 0% /etc/mnttab
auto_home 0 0 0 0% /home
-hosts 0 0 0 0% /net
swap 1220032 0 1220032 0% /tmp
swap 1220064 32 1220032 1% /var/run
fd 0 0 0 0% /dev/fd
#

The rest of the config of this virtual server is not surprising at all :

# uname -a
SunOS zone1 5.10 s10_51 sun4u sparc SUNW,UltraSPARC-IIi-cEngine
# psrinfo -v
Status of virtual processor 0 as of: 02/27/2004 09:08:06
on-line since 02/26/2004 11:48:33.
The sparcv9 processor operates at 360 MHz,
and has a sparcv9 floating point processor.
# isainfo -v
64-bit sparcv9 applications
32-bit sparc applications
# prtconf -v
System Configuration: Sun Microsystems sun4u
Memory size: 320 Megabytes
System Peripherals (Software Nodes):

prtconf: devinfo facility not available

# ifconfig -a
lo0:1: flags=1000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme1:1: flags=1000843 mtu 1500 index 3
inet 192.168.35.210 netmask ffffff00 broadcast 192.168.35.255

Special Note : The virtual server in the zone hides the system details. The hardware on which the zone is running is not exposed to the applications or users. This explains why prtconf reveals nothing about the underlying hardware architecture. The isainfo tool clearly tells us that we are able to run 64-bit sparcv9 and 32-bit sparc applications. As far as the user or application is concerned we have a V880 running. Or a 280R. Or a E15K! It really doesn’t matter because we are in a virtual server that could be within any class of hardware.

Well, there we have it. A virtual server. A new zone is born and running. I now create a user account or two and then use the escape character from the zlogin command to exit the console :

# exit

zone1 console login:

zone1 console login: @.
[Connection to zone ‘zone1’ console closed]
#

#

Now we are back in the real world! Or at least we are in the global zone. I log out of the server entirely and nmap port scan the virtual server again:

# nmap -sS -O -v -v -P0 -T Aggressive -n -oN /tmp/zone1.log zone1

Starting nmap 3.20 ( www.insecure.org/nmap/ ) at 2004-02-27 09:34 EST
Host 192.168.35.210 appears to be up … good.
Initiating SYN Stealth Scan against 192.168.35.210 at 9:34
Adding open port 37/tcp
Adding open port 22/tcp
Adding open port 513/tcp
Adding open port 515/tcp
Adding open port 514/tcp
Adding open port 7100/tcp
Adding open port 7/tcp
Adding open port 21/tcp
Adding open port 587/tcp
Adding open port 19/tcp
Adding open port 544/tcp
Adding open port 9/tcp
Adding open port 2105/tcp
Adding open port 111/tcp
Adding open port 13/tcp
Adding open port 79/tcp
Adding open port 540/tcp
Adding open port 25/tcp
Adding open port 543/tcp
Adding open port 23/tcp
Adding open port 512/tcp
The SYN Stealth Scan took 484 seconds to scan 1611 ports.
For OSScan assuming that port 7 is open and port 1 is closed and neither are firewalled
Interesting ports on 192.168.35.210:
(The 1590 ports scanned but not shown below are in state: closed)
Port State Service
7/tcp open echo
9/tcp open discard
13/tcp open daytime
19/tcp open chargen
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
37/tcp open time
79/tcp open finger
111/tcp open sunrpc
512/tcp open exec
513/tcp open login
514/tcp open shell
515/tcp open printer
540/tcp open uucp
543/tcp open klogin
544/tcp open kshell
587/tcp open submission
2105/tcp open eklogin
7100/tcp open font-service
Remote operating system guess: Solaris 9 Beta through Release on SPARC
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=F1B6%IPID=I%TS=100HZ)
T1(Resp=Y%DF=Y%W=C0B7%ACK=S++%Flags=AS%Ops=NNTMNW)
T2(Resp=N)
T3(Resp=N)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=N)
PU(Resp=N)

Uptime 0.914 days (since Thu Feb 26 11:47:32 2004)
TCP Sequence Prediction: Class=random positive increments
Difficulty=61878 (Worthy challenge)
TCP ISN Seq. Numbers: 7D44D7F9 7D46507E 7D49EF7E 7D4E40EC 7D5145C4 7D5426FD
IPID Sequence Generation: Incremental

Nmap run completed — 1 IP address (1 host up) scanned in 517.027 seconds

Essentially all of the usual network services are running on that virtual server. Finally I login to it via ssh :

$ ssh -2 -4 -e\^ -l dclarke zone1
The authenticity of host ‘zone1 (192.168.35.210)’ can’t be established.
RSA key fingerprint is f0:0b:a1:de:ad:be:ef:01:a4:21:53:8d:ae:de:00:00.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘zone1,192.168.35.210’ (RSA) to the list of known hosts.
Password:
Last login: Fri Feb 27 09:53:53 2004 from blaster
Sun Microsystems Inc. SunOS 5.10 s10_51 May 2004
$

What more can I say? I have setup a user account for a developer on the virtual server and he can login. There I can grant access to filesystems and other authorities as required. He can do what ever he pleases and I don’t have to worry about resources being tied up or security being breached. I can give him root access and not be concerned at all. Each zone has its own set of objects including processes, network interfaces, System V IPC objects and a unique root file system. Processes in one zone cannot access or control objects in other zones unless a common access point is shared from the global zone. All I need is a server with the hardware resources that can then be split up across zones. If I want an eight processor V880 to be used more effectively then I will manage the zones and allocate the CPU horsepower as needed.

But that is another topic, that would be under Resource Management. Which has been overhauled and made into a powerful tool within Solaris. The new Solaris 10 release will be feature rich and massively powerful in its ability to swallow up tasks. I look forward to playing with it because it really makes complex situations into a fun process.

Dennis Clarke Admin and Director for blastwave.org
dclarke @ blastwave.org Home of CSW – Community Software for Solaris

SUN NIC driver names

The following are Sun released NIC driver names:

* hme – FEPS chip and 10/100baseT(100Mbps) fast Ethernet
* qfe – Sun Quad FastEthernet
* eri – Sun Ethernet Rio Interface 10/100 Base.
* ce – GigaSwift Gigabit Ethernet 1.x .
* vge – Gigabit Ethernet 1.x ,
* ge – Gigabit Ethernet 2.x/3.x
* gem – Gigabit Ethernet MAC 1000 Base
* bge – The fourth generation of Sun Gigabit Ethernet products
* dmfe – Davicom 10/100Mb Ethernet Drivers(use DM9102A Ethernet chipset)
* e1000g – Intel Gigabit and 82546EB based 1000-baseT driver
* nge – Gigabit Ethernet Driver in Solaris 10 x86

DNS

DNS Configuration

DNS allows systems to look up host names, both within the private network and across the Internet. There are other ways of doing this, for example you could just run identical hosts files on all your machines. But somehow, this is more fun. In addition, Windows 95 machines examine their hosts databases in an odd order which makes using host tables difficult; the win95netbug FAQ rovides information on this, as well as help on how to reconfigure win95 to reorder the lookup order.[24]

You can set up the DNS server on any Unix system. The standard Solaris 2.6 install comes with BIND 4.9.x, suitably altered to deal with the additional Solaris naming systems. However, 4.9.x seems to do a great deal of maintenance work at fairly random times. This is fine if you have a permanent connection, but not so fine with a dialup. As a result, I have got BIND 8.2 from the Internet Software Consortium and installed that instead.[12]

To see if you have bind installed run #pkginfo SUNWinamd

As a result, I’m going to talk about BIND 8.2 here. The version of BIND which comes with Solaris 2.5.1 seems a lot more dialup friendly. So, if you are using an older version of Solaris, you can probably stay with the supplied version; the boot files are considerably different, however, so you will need to examine the documentation.

Compiling BIND 8.2

Compiling BIND 8.2 is fairly straightforward. However, before compiling, you will need to apply any patches to the supplied source code. The command patch < patch1 will apply the patch. To configure the Makefiles, use make depend from the src directory. To make the programs, use make To install, first remove the .settings file and then use make install Installation goes into directories under /usr/local The source code for BIND does not come with any manual pages. A separate documentation download contains man pages. The install Makefile for the man pages, however, expects a BSD-style install and, therefore, you will need to put /usr/ucb at the start of your PATH environment variable if you want a painless install. You may also need to modify the Makefile to remove pre-formatted man pages. DNS Server Configuration To configure the DNS server, you need to set up a number of (text) database files. The DNS server daemon (called named) first consults a boot file. This boot file tells the daemon to consult a series of further database files which gives it enough information to start serving names. Choosing a Domain Before setting up your DNS server, you will need to choose a domain name. Since nobody, except you, will accept your domain as a genuine domain (we hope) you have a reasonable amount of latitude over what domain names you can pick. Since I work for AFS, I have decided to call my domain canberra.afs.net.au I am pretty certain that nobody else is going to use that name. You'll have to decide what domain name to pick. As a suggestion, if you are connecting to ORAC, then a domain of whimsical-name.orac.net.au might be a good idea. On the other hand, I haven't consulted ORAC about this, so it might not. For the purposes of example, I an going to use the domain name flibble.orac.net.au The Boot File The boot file is consulted by named to on startup, so that initial options and data can be loaded. A sample /usr/local/etc/named.conf file for a server is shown in figure 2. Figure 2: Sample named.conf File for BIND # # Boot file for server solaris, primary server # for flibble.orac.net.au. # options { directory "/var/named"; forwarders { 299.18.99.151; 299.8.183.1; }; forward first; dialup yes; heartbeat-interval 1440; }; zone "." { type hint; file "named.ca"; }; zone "flibble.orac.net.au." { type master; file "private.hosts"; }; zone "3.5.10.in-addr.arpa." { type master; file "private.rev"; }; zone "0.0.127.in-addr.arpa." { type master; file "private.local"; }; The meaning of the lines in this file are: directory The directory in which the database files will be found. The /var/named directory is traditional, although inexplicable, since configuration files usually go under pathname/etc forwarders A list of IP addresses to forward queries to. This saves us from doing all the work of working down the domain tree when finding a domain. You can set your forwarders to the name servers supplied by your ISP. forward The forwarding behaviour. Queries are first forwarded to the addresses listed in forwarders. Only if no forwarding server responds will this server do its own work. Setting this option to only means that this server never does its own search. dialup Indicate that this is a dialup machine and that, therefore, maintenance work should be grouped together rather than done at any old time. This option is the main reason for my installing BIND 8.2. heartbeat-interval The interval (in minutes) between performing maintenance activities. This option is set, by default, to 60 minutes. Setting it to 1440 minutes means than maintenance is done once a day. zone Data about a particular domain. The string in double quotes give the domain name, with . being the top-level, root domain. The name server is to be the master server for the domain flibble.orac.net.au (name to IP-address) and the networks 10.5.3 and 127.0.0 (IP-Address to name). type The type of domain data. hint means that the data is there so that the top-level domain servers can be found. master means that this is the master server for this domain. file The file to read the name server data from. These files are discussed below. The /var/named/named.ca File The server, when it is doing its own work, rather than forwarding, needs a start point for searching for domains. This file contains the IP addresses of the servers for the root domain name servers. The base version of this file is shown in figure 3. The first section of this file states that the name servers (NS) for the root domain (.) are the ones listed. The second section says, for each name server, what its IP-address (A) is. The numbers (518400 and 3600000) give the time-outs in seconds for these entries; these figures should be large enough for the time out not to be a problem. Once you have this file, it's a good idea to pick up the most current official version at ftp://rs.internic.net/domain/named.root. Figure 3: Initial named.ca Cache File for BIND ; ; Initial cache data for named servers ; Servers ; . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. ; ; Addresses ; D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 B.ROOT-SERVERS.NET. 3600000 IN A 128.9.0.107 C.ROOT-SERVERS.NET. 3600000 IN A 102.33.4.12 The /var/named/private.hosts file This file contains the IP addresses of the private network. A sample private.hosts file is shown in figure 4. Figure 4: Sample private.hosts File for BIND ; ; Hosts file for domain flibble.orac.net.au. ; ;name ttl class type data ; ; Source of authority @ IN SOA solaris.flibble.orac.net.au. root.solaris.flibble.orac.net.au. ( 2000050201 ; Serial 10800 ; Refresh - 3 hours 3600 ; Retry - 1 hour 432000 ; Expire - 1 week 86400) ; Minimum - 1 day IN NS solaris.flibble.orac.net.au. ; ; Machines for the flibble.orac.net.au domain ; ;name ttl class type data localhost IN A 127.0.0.1 solaris IN A 10.5.3.1 win95 IN A 10.5.3.21 linux IN A 10.5.3.22 ; ; Aliases ; mail IN CNAME solaris www IN CNAME solaris ; ; Domain mailing addresses ; flibble.orac.net.au. IN MX 10 solaris.flibble.orac.net.au. flibble.orac.net.au. IN A 10.5.3.1 Some explanation of the various codes is probably in order: @ Domain. This is a short-hand for the domain given by the named.conf file (flibble.orac.net.au in this case). IN Internet. Indicates that we are talking about the Internet class of records. Supposedly, there are other possible classes here. SOA Source of Authority. This entry contains information on which machine is the primary name server for information about this domain (solaris.flibble.orac.net.au in this case) and who to contact in the case of trouble (root.solaris.flibble.orac.net.au). The serial number is used to indicate where changes have occurred. The other numbers give the time to expiry of the information broadcast by this name server. The serial numbers need to increase with each version of the file. A fairly common practice is to use YYYYMMDDVV with the year, month and day being the date of update and VV being the version number within the day. In the past, serial numbers of the form 1.2 were common, but this is now deprecated. NS Name Server. This line indicates that solaris.flibble.orac.net.au is the name server for this domain. A Address. These lines give the IP addresses of the various hosts. CNAME Canonical Name. These lines give canonical names (aliases) for various common names. These names are not strictly needed, but redirect requests to www.flibble.orac.net.au etc. to solaris.flibble.orac.net.au MX Mail Exchange This line gives the system to which mail addressed to user@flibble.orac.net.au should be sent to (solaris in this case). The /var/named/private.rev file This file allows ``reverse lookup.'' With this file, a system can get the name of a host from its IP address. A sample private.rev file is shown in figure 5. The PTR code allows an IP address. The 10.5.3. part of the address is derived from the entry in the named.conf file (see section 3.4.2). Figure 5: Sample private.rev File for DNS ; ; Reverse address file for domain flibble.orac.net.au ; ;name ttl class type data ; ; Source of authority @ IN SOA solaris.flibble.orac.net.au. root.solaris.flibble.orac.net.au. ( 2000050201 ; Serial 10800 ; Refresh - 3 hours 3600 ; Retry - 1 hour 432000 ; Expire - 1 week 86400) ; Minimum - 1 day IN NS solaris.flibble.orac.net.au. ; ; Machines names ; ;name ttl class type data 1 IN PTR solaris.flibble.orac.net.au. 21 IN PTR win95.flibble.orac.net.au. 22 IN PTR linux.flibble.orac.net.au. The /var/named/private.local file This file allows reverse lookup for the localhost address. This file is not strictly necessary. A sample private.local file is shown in figure 6. Figure 6: Sample private.local File for DNS ; ; Reverse address file for localhost ; ;name ttl class type data ; ; Source of authority @ IN SOA solaris.flibble.orac.net.au. root.solaris.flibble.orac.net.au. ( 2000050201 ; Serial 10800 ; Refresh - 3 hours 3600 ; Retry - 1 hour 432000 ; Expire - 1 week 86400) ; Minimum - 1 day IN NS solaris.flibble.orac.net.au. ; ; Machines names ; ;name ttl class type data 1 IN PTR localhost. Starting the named Daemon Once you have the files for named set up, you can start the /usr/local/sbin/named daemon. This daemon will read the /usr/local/etc/named.conf file for its configuration. You will probably want to make the named daemon start up during startup. To do this, modify the /etc/init.d/inetsvc file so that the lines which read if [ -f /usr/sbin/in.named -a -f /etc/named.boot ]; then /usr/sbin/in.named; echo "starting internet domain name server." fi now read if [ -f /usr/local/sbin/named -a -f /usr/local/etc/named.conf ]; then /usr/local/sbin/named; echo "starting ISC internet domain name server." elif [ -f /usr/sbin/in.named -a -f /etc/named.boot ]; then /usr/sbin/in.named; echo "starting Solaris internet domain name server." fi If you have installed named in an automounted local directory, you may need to delay the starting of the daemon somewhat, until the automounter is running. DNS Client Configuration Once you have set up the DNS server, you will need to configure each system to use the name server. Configuring Solaris Clients To configure a Solaris client properly you will need to edit the /etc/nsswitch.conf so that the DNS server is consulted. Modify the hosts line in so that it reads: hosts: files dns This line means that the Solaris system will first look up a name in the /etc/hosts file (see section 3.3.1). If the name isn't there, then DNS will be used. You will also have to set up the /etc/resolv.conf file so that the correct name servers are consulted. A sample resolver file is: ; ; Resolver for domain flibble.orac.net.au. ; domain flibble.orac.net.au nameserver 10.5.3.1 nameserver 203.30.77.33 The entries in this file are pretty self-evident. The name servers are tried in order, so if the local name server is down, the ORAC name server will be tried instead. The last thing you need to do is set the local domain name. You probably do not have to do this, but neatness demands it. The two commands you need are domainname flibble.orac.net.au and domainname > /etc/defaultdomain where flibble.orac.net.au is replaced by your chosen domain name.

Disabling nscd Cache Refreshes

Solaris 2.6 comes with a name caching daemon, nscd This daemon keeps a cache of recent name queries to allow a more speedy response to common queries.

nscd is all very nice. But, in it’s default configuration, it refreshes the queries in it’s cache every hour or so. If you have a dial-out connection, this means that every hour, your line will come up to re-query any names that are in the cache; not a good thing.

To disable the refresh, alter /etc/nscd.conf so that the line reading keep-hot-count hosts 20 now reads keep-hot-count hosts 0 Then make the nscd daemon re-read it’s configuration file by sending it a HUP signal.

Configuring Linux Clients

Configuring Linux DNS clients is similar to configuring Solaris clients as described above, in section 3.4.3, except that you do not have to configure the /etc/nsswitch.conf file and you only need to configure the domain name if you have NIS installed.

Configuring Windows 95 Clients

To configure DNS for Windows 95, you need to open the Network section of the Control Panel and choose the TCP/IP properties. For the example network, we have:

Tab Field Value
DNS Configuration Enable DNS
Host win95
Domain flibble.orac.net.au
Add 10.5.3.1
Add 203.30.77.33

Testing the DNS Configuration

Once you have the DNS configuration working, you will probably want to test it. The basic tool for testing the server configuration is /usr/local/sbin/nslookup This tool allows you to interrogate the name server and see how it responds to various questions.

Testing the Server

The DNS daemon can be made to provide debugging information by sending it a USR1 signal, via kill. The daemon will start tracing its behaviour by writing records into the file /var/named/named.run Sending the daemon a USR2 signal turns off debugging.

The daemon can be made to dump it’s current state into the file /var/named/named_dump.db by sending it a INT signal.

Testing the clients

For Unix systems, using nslookup to test client behaviour is obvious. Windows 95 does not have a suitable testing package. I used WS_Ping to test my setup.[25] WS_Ping is not freeware.

A first stab at DNS config

A resolving, caching name server.

A first stab at DNS config, very useful for dialup, cable-modem and ADSL users.

On Red Hat and Red Hat related distributions you can achieve the same practical result as this HOWTO’s first section by installing the packages bind, bind-utils and caching-nameserver. If you use Debian simply install bind and bind-doc. Of course just installing those packages won’t teach you as much as reading this HOWTO. So install the packages, and then read along verifying the files they installed.

A caching only name server will find the answer to name queries and remember the answer the next time you need it. This will shorten the waiting time the next time significantly, especially if you’re on a slow connection.

First you need a file called /etc/named.conf (Debian: /etc/bind/named.conf). This is read when named starts. For now it should simply contain:

// Config file for caching only name server

options {
directory "/var/named";

// Uncommenting this might help if you have to go through a
// firewall and things are not working out. But you probably
// need to talk to your firewall admin.

// query-source port 53;
};

zone "." {
type hint;
file "root.hints";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};

The Linux distribution packages may use different file names for each kind of file mentioned here; they will still contain about the same things.

The `directory’ line tells named where to look for files. All files named subsequently will be relative to this. Thus pz is a directory under /var/named, i.e., /var/named/pz. /var/named is the right directory according to the Linux File system Standard.

The file named /var/named/root.hints is named in this. /var/named/root.hints should contain this: (If you cut and paste this file from an electronic version of this document, please note that there should be no leading spaces in the file, i.e. all the lines should start with a non-blank character. Some document processing software will insert spaces at beginning of the lines, causing some confusion. In that case please remove the leading spaces)

;
; There might be opening comments here if you already have this file.
; If not don’t worry.
;
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
;
M.ROOT-SERVERS.NET. 6D IN A 202.12.27.33
I.ROOT-SERVERS.NET. 6D IN A 192.36.148.17
E.ROOT-SERVERS.NET. 6D IN A 192.203.230.10
D.ROOT-SERVERS.NET. 6D IN A 128.8.10.90
A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4
H.ROOT-SERVERS.NET. 6D IN A 128.63.2.53
C.ROOT-SERVERS.NET. 6D IN A 192.33.4.12
G.ROOT-SERVERS.NET. 6D IN A 192.112.36.4
F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241
B.ROOT-SERVERS.NET. 6D IN A 128.9.0.107
J.ROOT-SERVERS.NET. 6D IN A 198.41.0.10
K.ROOT-SERVERS.NET. 6D IN A 193.0.14.129
L.ROOT-SERVERS.NET. 6D IN A 198.32.64.12

The file describes the root name servers in the world. The servers change over time and must be maintained now and then. See the maintenance section for how to keep it up to date.

The next section in named.conf is the last zone. I will explain its use in a later chapter; for now just make this a file named 127.0.0 in the subdirectory pz: (Again, please remove leading spaces if you cut and paste this)

$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR localhost.

Next, you need a /etc/resolv.conf looking something like this: (Again: Remove spaces!)

search subdomain.your-domain.edu your-domain.edu
nameserver 127.0.0.1

The `search’ line specifies what domains should be searched for any host names you want to connect to. The `nameserver’ line specifies the address of your nameserver, in this case your own machine since that is where your named runs (127.0.0.1 is right, no matter if your machine has another address too). If you want to list several name servers put in one `nameserver’ line for each. (Note: Named never reads this file, the resolver that uses named does. Note 2: In some resolv.conf files you find a line saying "domain". That’s fine, but don’t use both "search" and "domain", only one of them will work).

To illustrate what this file does: If a client tries to look up foo, then foo.subdomain.your-domain.edu is tried first, then foo.your-domain.edu, and finally foo. You may not want to put in too many domains in the search line, as it takes time to search them all.

The example assumes you belong in the domain subdomain.your-domain.edu; your machine, then, is probably called your-machine.subdomain.your-domain.edu. The search line should not contain your TLD (Top Level Domain, `edu’ in this case). If you frequently need to connect to hosts in another domain you can add that domain to the search line like this: (Remember to remove the leading spaces, if any)

search subdomain.your-domain.edu your-domain.edu other-domain.com

and so on. Obviously you need to put real domain names in instead. Please note the lack of periods at the end of the domain names. This is important; please note the lack of periods at the end of the domain names.

3.1 Starting named

After all this it’s time to start named. If you’re using a dialup connection connect first. Type `ndc start’, and press return, no options. If that does not work try `/usr/sbin/ndc start’ instead. If that back-fires see the qanda section. If you view your syslog message file (usually called /var/adm/messages, but another directory to look in is /var/log and another file to look in is syslog) while starting named (do tail -f /var/log/messages) you should see something like:

(the lines ending in \ continues on the next line)

Dec 15 23:53:29 localhost named[3768]: starting. named 8.2.2-P7 \
Fri Nov 10 04:50:23 EST 2000 ^Iprospector@porky.\
devel.redhat.com:/usr/src/bs/BUILD/bind-8.2.2_P7/\
src/bin/named
Dec 15 23:53:29 localhost named[3768]: hint zone "" (IN) loaded\
(serial 0)
Dec 15 23:53:29 localhost named[3768]: Zone "0.0.127.in-addr.arpa"\
(file pz/127.0.0): No default TTL set using SOA\
minimum instead
Dec 15 23:53:29 localhost named[3768]: master zone\
"0.0.127.in-addr.arpa" (IN) loaded (serial 1)
Dec 15 23:53:29 localhost named[3768]: listening on [127.0.0.1].53 (lo)
Dec 15 23:53:29 localhost named[3768]: listening on [10.0.0.129].53\
(wvlan0)
Dec 15 23:53:29 localhost named[3768]: Forwarding source address is\
[0.0.0.0].1034
Dec 15 23:53:29 localhost named[3769]: Ready to answer queries.

If there are any messages about errors then there is a mistake. Named will name the file it is in. Go back and check the file. Run "ndc restart" when you have fixed it.

Now you can test your setup. Traditionally a program called nslookup is used for this. These days dig is recommended:

$ dig -x 127.0.0.1

; <<>> DiG 8.2 <<>> -x
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; 1.0.0.127.in-addr.arpa, type = ANY, class = IN ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 1D IN PTR localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa. 1D IN NS ns.penguin.bv. ;; Total query time: 30 msec ;; FROM: lookfar to SERVER: default -- 127.0.0.1 ;; WHEN: Sat Dec 16 00:16:12 2000 ;; MSG SIZE sent: 40 rcvd: 110 If that's what you get it's working. We hope. Anything else, go back and check everything. Each time you change the named.conf file you need to restart named using the ndc restart command. Now you can enter a query. Try looking up some machine close to you. pat.uio.no is close to me, at the University of Oslo: $ dig pat.uio.no ; <<>> DiG 8.2 <<>> pat.uio.no
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUERY SECTION: ;; pat.uio.no, type = A, class = IN ;; ANSWER SECTION: pat.uio.no. 1D IN A 129.240.130.16 ;; AUTHORITY SECTION: uio.no. 1D IN NS nissen.uio.no. uio.no. 1D IN NS ifi.uio.no. uio.no. 1D IN NS nn.uninett.no. ;; ADDITIONAL SECTION: nissen.uio.no. 1D IN A 129.240.2.3 ifi.uio.no. 1H IN A 129.240.64.2 nn.uninett.no. 1D IN A 158.38.0.181 ;; Total query time: 112 msec ;; FROM: lookfar to SERVER: default -- 127.0.0.1 ;; WHEN: Sat Dec 16 00:23:07 2000 ;; MSG SIZE sent: 28 rcvd: 162 This time dig asked your named to look for the machine pat.uio.no. It then contacted one of the name server machines named in your root.hints file, and asked its way from there. It might take tiny while before you get the result as it may need to search all the domains you named in /etc/resolv.conf. Please note the "aa" on the "flags:" line. It means that the answer is authoritative, that it is fresh from an authoritative server. I'll explain "authoritative" later. If you ask the same again you get this: $ dig pat.uio.no ; <<>> DiG 8.2 <<>> pat.uio.no
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUERY SECTION: ;; pat.uio.no, type = A, class = IN ;; ANSWER SECTION: pat.uio.no. 23h59m58s IN A 129.240.130.16 ;; AUTHORITY SECTION: UIO.NO. 23h59m58s IN NS nissen.UIO.NO. UIO.NO. 23h59m58s IN NS ifi.UIO.NO. UIO.NO. 23h59m58s IN NS nn.uninett.NO. ;; ADDITIONAL SECTION: nissen.UIO.NO. 23h59m58s IN A 129.240.2.3 ifi.UIO.NO. 1d23h59m58s IN A 129.240.64.2 nn.uninett.NO. 1d23h59m58s IN A 158.38.0.181 ;; Total query time: 4 msec ;; FROM: lookfar to SERVER: default -- 127.0.0.1 ;; WHEN: Sat Dec 16 00:23:09 2000 ;; MSG SIZE sent: 28 rcvd: 162 Note the lack of a "aa" flag in this answer. That means that named did not go out on the network to ask this time, as the information is in the cache now. But the cached information might be out of date (stale). So you are informed of this (very slight) possibility by the "aa" not being there. But, now you know that your cache is working. 3.2 Resolvers All OSes implementing the standard C API has the calls gethostbyname and gethostbyaddr. These can get information from several different sources. Which sources it gets it from is configured in /etc/nsswitch.conf on Linux (and some other Unixes). This is a long file specifying from which file or database to get different kinds of data types. It usually contains helpful comments at the top, which you should consider reading. After that find the line starting with `hosts:'; it should read: hosts: files dns (You remembered about the leading spaces, right? I won't mention them again.) If there is no line starting with `hosts:' then put in the one above. It says that programs should first look in the /etc/hosts file, then check DNS according to resolv.conf. 3.3 Congratulations Now you know how to set up a caching named. Take a beer, milk, or whatever you prefer to celebrate it.