Questions and Answers

Amy Rich

Q I have a laptop running OS X 10.4.8 that's configured just the same as other laptops in the department. We connect through a wireless network, which hands out IP addresses via a DHCP server. If I look at the Network Configuration Page for the AirPort, it says that I'm configuring IPv4 Using DHCP. No other information, including DNS Servers or Search Domains, is filled in. If I open a Web browser, I can get to, say, yahoo.com just fine. I can ping yahoo.com just fine. When I try to run nslookup or dig, though, I get the following timeout error:

;; connection timed out; no servers could be reached

Why do some of my services work fine while others fail? If I change networks, I have the same problem with a different set of nameservers, so I don't think it's the fault of DHCP. All of the other laptops here behave as normal.

A If the only things that fail to work are nslookup and dig, then most likely your link for /etc/resolv.conf is missing. If you do an ls -al on /etc/resolv.conf, you should see a symlink to /var/run/resolv.conf. If this symlink is missing, or the file has become otherwise modified, recreate the symlink properly by running the following as root:

rm -f /etc/resolv.conf
ln -s /var/run/resolv.conf /etc/resolv.conf

The nameservers for nslookup and dig should now match those obtained from your DHCP configuration.

Q We're in the market to refresh our desktops where I work. We want to be able to boot Linux, Windows, or Solaris. Windows and Linux will run on almost anything, but Solaris is a bit more picky about things like network cards, DVD drives, etc. Is there any way I can tell whether or not the hardware I'm thinking of purchasing will support Solaris?

A There are a few resources that might help you out. I'm going to assume that you're going to be running Solaris 10 on these PCs, since that's probably your best bet for supportability. To begin, take a look at the Hardware Compatibility List at:

http://www.sun.com/bigadmin/hcl/

This includes a list of hardware known to work with Solaris x86/x64 systems. The list is not comprehensive, so you might also want to look at the Third Party I/O Technologies and Solutions page at:

http://www.sun.com/io_technologies/S10List.html

Lastly, if your system is not listed in the HCL, and you have access to the hardware you're considering purchasing (you might be able to get a demo system, especially if you're purchasing a large quantity), try using the Solaris Operating System for x86 Installation Check Tool:

http://www.sun.com/bigadmin/hcl/hcts/install_check.html

The tool is a bootable CDROM image that probes the major PCI devices in your PC and tells you whether there are supported or third-party drivers that it knows about. The report it generates should give you a fairly solid idea of whether you can install Solaris 10 on your machine. If you have a device that claims not to have a driver, there is still some chance that your device might be supported by an existing driver and the check tool is unaware of it.

Q We're running a mix of Solaris 8, 9, and 10 machines at our site. I've just been informed that we'll need some patches to deal with the upcoming DST issue that's going to hit next year. Is there a definitive list of products and patches that I'm going to need to install anywhere?

A I don't know of a definitive list, but your best bet is probably to search sunsolve.sun.com for "U.S. Energy Policy Act of 2005." The OS patches you'll need are:

Solaris 8: 109809-03, 108993-53
http://sunsolve.sun.com/search/document.do?assetkey=1-21-109809-03
http://sunsolve.sun.com/search/document.do?assetkey=1-21-108993-53

Solaris 9: 113225-04, 112874-34
http://sunsolve.sun.com/search/document.do?assetkey=1-21-113225-04
http://sunsolve.sun.com/search/document.do?assetkey=1-21-112874-34

Solaris 10: 122032-02, 119254-06, 118833-17
http://sunsolve.sun.com/search/document.do?assetkey=1-21-122032-02
http://sunsolve.sun.com/search/document.do?assetkey=1-21-119254-06
http://sunsolve.sun.com/search/document.do?assetkey=1-21-118833-17

You'll also want to upgrade Java to one of the following:

,pre> Java SE v1.3.1_18 (or later) Java SE v1.4.2_11 (or later) Java SE 5.0 u6 (or later) and apply the patch for the following firmware revisions on the specified platforms:

114527-03 for firmware rev 5.20.x on the E6900, E4900, E2900, 6800,
4800, 4810, 3800, V1280, Netra 1280, and Netra 1290 platforms.
http://sunsolve.sun.com/search/document.do?assetkey=1-21-114527-03

114526-07 for firmware rev 5.19.6 on the E6900, E4900, E2900, 6800,
4800, 4810, 3800, and V1280 platforms.
http://sunsolve.sun.com/search/document.do?assetkey=1-21-114526-07

114525-07 for firmware rev 5.18.6 on the E6900, E4900, E2900, 6800,
4800, 4810, 3800, and V1280 platforms.
http://sunsolve.sun.com/search/document.do?assetkey=1-21-114525-07

You might also have other applications that will require updates or patching. Anything that uses the system time should be fine after patching the OS, but anything that calculates its own date on the fly will probably have issues.

Q We've decided to change the information for our DNS nameservers to machines that we have control over instead of relying on a third party to handle it for us. I logged into domainsupport.register.com to update the nameserver listings and clicked submit. I got the following error back:

Domain Name Maintenance For
your.domain

*Errors modifying nameservers: Nameserver [foo] cannot be registered*

When I emailed tech support, they responded with what sounded to me like a bogus answer:

The reason that you are unable to point your domain name to 
[foo] is because this DNS is not registered at the registry 
level. In order to point your domain name to new DNS details, 
the DNS have to be registered with the registry.

What does that mean? Are they giving me the runaround to try and get more money out of me (by hosting the nameservers for the domain there)?

A Most likely what they're trying to tell you is that you're missing what's called a glue record for the host you're attempting to list as your nameserver. To understand what a glue record is and why it's necessary, I'll provide a brief explanation of how a DNS query works.

Say that you try to resolve www.google.com. from your desktop machine. First, the query goes to one of your local, recursive nameservers. Assuming that it doesn't have any data cached, the query will be passed onto one of the top level domain name servers, a.root-servers.net though m.root-servers.net.. These servers know about the top-level domains including com, net, org, country domains, etc.

Since www.google.com. is in the com domain, the root nameserver passes a referral to the names and IP addresses of the com domain nameservers (a.gtld-servers.net through m.gtld-servers.net) back to your local recursive resolver. Your local resolver keeps following zone delegations until it finds information that's authoritative for www.google.com.. If you use the trace option to dig, you can view the path of the lookup transaction:

$dig @192.168.1.1 www.google.com +trace

; <<>> DiG 9.2.2 <<>> @192.168.1.1 www.google.com. +trace
;; global options:  printcmd
.                       146099  IN      NS      B.ROOT-SERVERS.NET.
.                       146099  IN      NS      C.ROOT-SERVERS.NET.
.                       146099  IN      NS      D.ROOT-SERVERS.NET.
.                       146099  IN      NS      E.ROOT-SERVERS.NET.
.                       146099  IN      NS      F.ROOT-SERVERS.NET.
.                       146099  IN      NS      G.ROOT-SERVERS.NET.
.                       146099  IN      NS      H.ROOT-SERVERS.NET.
.                       146099  IN      NS      I.ROOT-SERVERS.NET.
.                       146099  IN      NS      J.ROOT-SERVERS.NET.
.                       146099  IN      NS      K.ROOT-SERVERS.NET.
.                       146099  IN      NS      L.ROOT-SERVERS.NET.
.                       146099  IN      NS      M.ROOT-SERVERS.NET.
.                       146099  IN      NS      A.ROOT-SERVERS.NET.
;; Received 436 bytes from 192.168.1.1#53(192.168.1.1) in 2 ms

com.                    172800  IN      NS      C.GTLD-SERVERS.NET.
com.                    172800  IN      NS      D.GTLD-SERVERS.NET.
com.                    172800  IN      NS      E.GTLD-SERVERS.NET.
com.                    172800  IN      NS      F.GTLD-SERVERS.NET.
com.                    172800  IN      NS      G.GTLD-SERVERS.NET.
com.                    172800  IN      NS      H.GTLD-SERVERS.NET.
com.                    172800  IN      NS      I.GTLD-SERVERS.NET.
com.                    172800  IN      NS      J.GTLD-SERVERS.NET.
com.                    172800  IN      NS      K.GTLD-SERVERS.NET.
com.                    172800  IN      NS      L.GTLD-SERVERS.NET.
com.                    172800  IN      NS      M.GTLD-SERVERS.NET.
com.                    172800  IN      NS      A.GTLD-SERVERS.NET.
com.                    172800  IN      NS      B.GTLD-SERVERS.NET.
;; Received 504 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) \
   in 86 ms

google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.
;; Received 168 bytes from 192.26.92.30#53(C.GTLD-SERVERS.NET) \
   in 10 ms

www.google.com.         604800  IN      CNAME   www.l.google.com.
l.google.com.           86400   IN      NS      a.l.google.com.
l.google.com.           86400   IN      NS      b.l.google.com.
l.google.com.           86400   IN      NS      c.l.google.com.
l.google.com.           86400   IN      NS      d.l.google.com.
l.google.com.           86400   IN      NS      e.l.google.com.
l.google.com.           86400   IN      NS      g.l.google.com.
;; Received 244 bytes from 216.239.32.10#53(ns1.google.com) in 88 ms

As shown in the above, google.com.. has four nameservers listed, ns1.google.com.. through ns4.google.com., which are each inside the google.com. domain. If your resolver is following references to determine which nameservers are authoritative, you can imagine having a chicken and egg problem when the authoritative nameservers for a domain are contained within the domain itself. To get around this, the nameservers have glue records in the parent zone.

A glue record is an A record that is created as part of a zone delegation. If a zone is delegated to a name server whose hostname lies within that particular zone, then a glue record for that hostname must be included in the delegation. In the case of google.com., the GTLD nameservers have A records, which map ns1.google.com. through ns4.google.com. to their appropriate IP addresses. You can also use dig to view the glue records as follows:

$dig +norec @a.gtld-servers.net. www.google.com. A

; <<>> DiG 9.2.2 <<>> +norec @a.gtld-servers.net. www.google.com. A
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50719
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; AUTHORITY SECTION:
google.com.             172800  IN      NS      ns1.google.com.
google.com.             172800  IN      NS      ns2.google.com.
google.com.             172800  IN      NS      ns3.google.com.
google.com.             172800  IN      NS      ns4.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.         172800  IN      A       216.239.32.10
ns2.google.com.         172800  IN      A       216.239.34.10
ns3.google.com.         172800  IN      A       216.239.36.10
ns4.google.com.         172800  IN      A       216.239.38.10

The A records displayed in the ADDITIONAL SECTION are the glue records for google.com..

Glue records are generally created through your registrar, but it really depends on the policies of your TLD. Try looking for something like a Register Name Server or Register Host option at you registrar to create glue records for your nameservers.

If you're delegating your own subdomains, you'll need to add glue records to your parent zone. Say you have host.domain and you want to create a subdomain called my.host.domain. The necessary configuration snippet from your BIND zone file for host.domain would look like:

$TTL 2d
$ORIGIN host.domain.
@       IN     SOA   ns1.host.domain. hostmaster.host.domain. (
        2006110100 ; serial number
        2h         ; refresh =  2 hours
        15M        ; update retry = 15 minutes
        3W12h      ; expiry = 3 weeks + 12 hours
        2h20M      ; minimum = 2 hours + 20 minutes
        )
; nameservers
       IN      NS     ns1.host.domain.
       IN      NS     ns2.host.domain.
; A records for nameservers
ns1    IN      A      192.168.1.1
ns2    IN      A      192.168.1.2

; my.host.domain subdomain definition
$ORIGIN my.host.domain.
; two nameservers for the subdomain that reside within the subdomain
@      IN      NS     ns1.my.host.domain.
       IN      NS     ns2.my.host.domain.
; A records for subdomain nameservers only, aka glue records
ns1    IN      A      10.1.1.1
ns2    IN      A      10.1.1.2

If you're looking for further reading, the O'Reilly DNS and BIND book by Paul Albitz and Cricket Liu (http://www.oreilly.com/catalog/dns5/) is an excellent source of information on glue records as well as other general DNS topics.

Amy Rich has more than a decade of Unix systems administration experience in various types of environments. Her current roles include that of Senior Systems Administrator for the University Systems Group at Tufts University, Unix systems administration consultant, author, and charter member of LOPSA. She can be reached at: qna@oceanwave.com.