Questions and Answers

Bjorn Satdeva

The InterNIC, which is the office that keeps track of assigned IP addresses and domain names, apparently continues to be in a mess. On one hand, they have their work cut out for them with the enormous growth in the number of second-level domain names over the past 2 years. On the other hand, they started to charge a yearly fee for this service a year ago. I do not want to restart the discussion of the appropriateness of this, especially as a modest fee for this service probably is appropriate. However, the income from those charges was supposed to be used to improve the service from the InterNIC and also be invested into backbone. Lately, I have had a small problem with the InterNIC, as I got charged for a fee for sysadmin.com, dating back to 1989, the first year of that domain's existence. When I inquired about this and asked if they now had a policy of charging domain name holders retroactively to the date of creation of their domain, I never got an answer. I did however get a new invoice (still by email, in spite of my request to receive this by U.S. mail), this time for the current year, although it is dated back in March.

The InterNIC has a large task in front of them and is working on inproving their system to provide a more reliable service. However, it may serve the rest of us well to stay on top of how they handle our domains. I know of at least one case in which a domain was changed over to a new organization in spite of the previous organization's having had it for several years. So for now, look out.

I have forwarded to MIC the required paperwork for a change in our domain registration, but don't recall any place where they ask for MX hosts that will point to this domain. Our site receives email through UUCP, and we need this information in our domain configuration. Did I miss something?

MX records are not handled by the InterNIC. A UUCP site can send and receive email from sites that are on the Internet using what is called a forwarder. This was a common practice a few years ago, when direct Internet connections were less common and much more expensive than they are today. UUCP is still around, though, and will probably be for some time, as it is inexpensive and all the needed software comes with the system. Let me, therefore, briefly explain the steps:

You will need a forwarder, which is a site that is directly connected to the Internet, and that is willing to intercept email for your site and forward it to UUCP. To do this, they need to make a slight change to their sendmail configuration, so any email they receive for your site will be queued up for transmisson by UUCP.

The rest of the Internet will know to route email for you to your forwarder through the MX record for your domain. MX records (Mail eXchange) are nameserver records used for directing the flow of email. These records have other purposes than just handling UUCP forwarders, but the general mechanism is the same. The MX record for your domain will point to your forwarder, and the mail delivery agents on the Internet will therefore know to route email for you to your forwarder. This is completely transparent, and the users who send the email will be unaware of the fact that they are sending email to a UUCP site.

The Internic is not directly involved in the MX record business. They only provide the information that goes to the root servers, and that information only contains a pointer to nameservers that know about your domain. Those nameservers will need to have an MX record pointing to your forwarder. Typically, the forwarder will be the maintainer of the nameserver that contains your MX record, just because this is a practical way of doing it. Technically, your MX record can be handled by any nameserver (as long as the root nameservers have delegated your domain to them).

This scheme will allow anybody on the Internet to send email to you by actually sending to your forwarder, using the MX record. This is all done automatically. The only problem is that your email addresses will still use the ugly old UUCP bang (!) addresses. If you get smail3 and use it instead of sendmail, it can use what is known as "batched SMTP" for sending and receiving email. If your forwarder supports batched SMTP, you will be able to send and receive email, using SMTP end to end, and nobody will be any wiser.

I have been told that my nameserver contains "Lame Delegations." What is that?

A "lame delegation" is when you delegate authority for a domain or part of a domain to a nameserver which does not have that information. Delegation of authority is what makes the nameserver paradigm work. For example, the root nameservers have delegated the domain sysadmin.com to my nameserver heimdal.sysadmin.com.

The typical lame delegation occurs when nameserver N is delegated as authoritative for domain D. However, when you ask N about D, it returns nonauthoritative data or no data at all. Nonauthoritative data is nameserver speak for, "I have the information you asked for, but it is second-hand information."

The real problem with lame delegations is that they can generate substantial traffic on the Internet, but without being able to resolve the names or IP addresses that the users of the name service are attempting to get.

The Domain Name System FAQ offers a more technical examination of "Lame Delegation." It is available at the system administration ftp archives at:

ftp://ftp.sysadmin.com/pub/dns

I read the man pages and my O'Reilly book on the dump command, and just can't get it right. All I want to do is dump a directory to a file on another disk. I am testing the capacity of a 9 Gb disk with the dump command. I already used the tar command. I want to copy the /usr directory to another mounted disk. It seems simple, could you help or point me to a place that will explain?

What you are trying to do is to use dump to archive some files. However, dump was not written as an archiving program, and does not work well when used for that purpose. Use dump for your regular backups, and tar for archiving purposes. It does not matter for this discussion if your image is on tape or on the hard disk.

If you are a bit confused about the difference between backups and archives, you are not alone. Your backup is a (hopefully daily) snapshot of your computer. It does not care about the purposes of the data, as the goal is to be able to do a full or partial restore of the data contained on the disk in case of a disaster of some kind. Note that disaster has a wide meaning here; it can be a disk crash, a user accidentally removing important files, or it can be a cracker that intentionally alters data. The purpose of the backup is to make sure if you lose data you can get it back as fast as possible. Archives, on the other hand, are typically snapshots of data related to a single or group of users. One example is an archive containing all the files related to the development of an application. You can restore one or more lost files from an archive tape, but the main purpose is to get a snapshot of the state of the application on a given date (i.e., when a certain milestone has been reached).

When copying directories, you can use tar, but if the directory is identical to a filesystem, you are again better off using dump. For one thing, most versions of tar are unable to handle files with "holes," such as dbm files. When restored, the file's real size will become identical to its virtual size, which often is many, many times bigger, making it impossible to restore such files to the hard disk.

To use dump for copying an entire filesystem, you can use

dump 0f - /usr | (cd /mnt; restore xf -)

This will cause dump to write the content of the dump archive to stdout, and read by restore from stdin. You can create a similar pipe from tar, but make sure that you set the correct options for tar, so owner, group, access mode, and last modification time is preserved (the specific options vary slightly between versions, so check your man page).

About the author

Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at bjorn@sysadmin.com; or by phone at (408) 241-3111.