How do I change the FQDN?

in the Terminal:

sudo changeip

to learn about it, type in:

man changeip

Check with whomever manages your network, and particularly your local DNS domain.

Most entities running moderate networks have some sort of an authoritative source for network host names and (for static hosts) IP addresses. This could be a web site with a simple database back-end or -- as I encountered inside a global corporation -- a manually-managed Word document file sitting on somebody's PC.

Most companies have a way to pick a name and to register it. Some have policies or site-local norms for names.

You can use bash and the dig utility ("dig xyzzy.example.com", adjusted for your FQDN) to see if a name you'd like to use is taken, if your entity doesn't offer a host name lookup tool. You'll see an address back for a domain in use, or a DNS server if not. (dig output is a little cryptic.)

I'd tend to stay off the .local bonjour stuff with your FQDN, and would pick and use a name registered in the DNS server(s) for your particular domain.

The TLD is the ".com" part.

example.com is a well-known reserved domain, and would not be my choice for a private network or private host name. DNS requests for hosts in that domain probably go to, well, "somewhere", too.

And you're assigning your own (visible) host name, and the local network administration (if that's not you) might take umbrage here. That also only works for routing if you have the entry added into DNS, an extra and separate step.

If you're working at Spacely Sprockets, you might use xserve.spacely as your own TLD for your own FQDN. ICANN is unlikely to use .spacely. (Though they did activate .museum, .pro and a number of other TLDs a while back.)

And out of curiosity, why name the box "xserve"? That name can get problematic just as soon as the second Xserve rolls into your network. Some folks will use functional names ("mail", "dns1", etc), and some use whimsical names ("elroy", "astro"); there's nothing really wrong with naming a host "xserve", though. (But Jane might have to get you out of a predicament that can arise that second Xserve arrives, or if there's a duplicate host name in the local network. 🙂 )

I'd suggest that you contact your network administrator, and get an IP host name and address. If that's you, I might suggest getting somebody in to help you set up DNS (either on your Xserve, on another server, or hosted for you by another organization), and particularly if you're starting to add hosts to a local network; if you're on a growing network. Digging out of a messed-up DNS (having messed up DNS once or twice myself over the years) is no fun.

+Unfortunately, I have ended up as our de facto network administrator.+

Then you'll want to acquire a copy of DNS & BIND book (5th edition is current, when last I checked; Cricket Liu and Paul Albitz), and read it. There's a companion DNS & BIND Cookbook (Liu) available, too.

I do not know how familiar you are with IP and IP routing, but that can be another area you'll necessarily become more familiar with. There are various good books on this topic.

+Based on what you're saying, it sounds like xserve1.local.tca would work for a FQDN, and I guess I simply need a DNS that points that name to 192.168.0.184. But once I set this up and tell all the machines on our network to check the local DNS, how are names resolved for the rest of the net?+

You will want your local DNS configured as authoritative for your local network, and configured to pass along queries to other DNS servers for translations outside its purview. This is how DNS works. How to set this up for your particular case is, well, fodder for a book.

+I'll have to see how much of this I can figure out on my own, I think they're unlikely to pay for a consultant. Luckily our network is very small and will stay so, so nothing complicated is needed.+

A good DNS consultant can get your baseline network established and running correctly in a couple of hours time, and can keep the holes plugged.

From a business perspective, investing in a consultant can save you time and effort and aggravation. From your own personal and career perspective, learning DNS can be a boon. (If you're interested in getting deeper into topics such as DNS and BIND, of course.)

You might get your ISP to provide DNS translations for you. Some will, and some will charge a fee for this. This approach is the least disruptive of your time and effort, and entirely suitable for small and infrequently-changing networks.

Start with Liu's book, if you're going to roll your own DNS experience.

I'll mention the brute-force approach -- and I stress the brute-force usage here -- can involve editing and adding entries into the local hosts file. Each host in your has an entry for each node, and each node has its own copy of the hosts file. For a simple and static network, this might be sufficient. On most Unix and Mac OS X boxes, this file is the /etc/hosts file. Windows has an analog, but I don't remember the exact path. On OpenVMS with TCP/IP Services, use the verb UCX and its command SET HOST to establish the host name and address mapping. Most (all?) other systems have some analog. If/when you scale your local network upwards or if you make frequent changes, this hosts file approach will quickly become unmanageable.

Hi

Sorry to butt in and I’m sure Mr Hoffman will reply to your post with some more sound advice but based on what has gone on before I would not ask your ISP to add an A Record for your private network. They probably would not do it in any case. What happens DNS wise on the private side of your router/firewall has nothing to do with what happens DNS wise on the public side of your router/firewall. Unless, of course, you want it to. If you some manipulation of your Domain's Public DNS Record would be required as well as directing specific external port requests for services to your privately run server. This would be done in the router/firewall.

When configuring internal DNS Services you create an initial NS (or CNAME) record to begin with, this would be the zone name as well as the name of your server. In your case xserve1.local.tca. The A Record gets created when you map xserve1.local.tca to the IP address, in your case 192.168.0.184, providing of course that this address is the fixed, permanently assigned IP address of your server. This address also needs to be the primary (first) address in the DNS Servers field in the Network Preferences Pane. Once this is done a Reverse Pointer Record (PTR) gets created that maps the NS Record to the A Record. This PTR record contains the words in.addr.arpa as well as the first three octets (usually) of the servers fixed IP address in reverse.

If you were to launch terminal you could key in the host command and it would look something like this:

Last login: Wed Nov 28 01:06:00 on console
Welcome to Darwin!
user:~ user$ host xserve1.local.tca
xserve1.local.tca has address 192.168.0.184
user:~ user$ host 192.168.0.184
0.168.192.in-addr.arpa domain name pointer host192-168-0-184.in-addr.xserve1.local.tca.
user:~ user$

This command, provided DNS is configured correctly, qualifies the DNS Service. You could also follow this up by issuing this command:

sudo changeip -checkhostname

If you see a return that basically tells you the server’s hostname (FQDN) along with its IP address and a further message telling you there is nothing to change then that is a pretty good indication that DNS services are configured correctly and everything is resolving as it should be.

You can point local clients away from constantly querying your server when making DNS Requests a number of ways. You could add your ISP’s DNS Server addresses by making a forwarding entry in /etc/named.conf. You can use nano, pico, vi or emacs to do this. You could also, if you feel brave enough, log in as root and manually edit the file using TextWrangler or TextEdit (make sure you configure the application preferences correctly before using TextEdit). As always whenever doing any manual configuration of files either by using the Finder or nano etc make sure you make a back up first as well as stopping the service.

You could keep things really simple and configure the clients to use what DNS addresses are being supplied by the router or you can manually key them in. You could use the router IP address itself. However if you don't have a lot of clients then I can't see it hurting the server overmuch.

Tony

If you choose to ask the the ISP involved, (and the ISP can provide this DNS resolution) you'll probably end up with a public (static) IP address, and a public IP host name. This DNS service can often be part of acquiring (purchasing) a static IP from the ISP.

What your ISP is willing (or even able) to do here can and will vary. Some ISPs are easier and more responsive to these sorts of requests than others in this regard.

Going through the ISP can be involved when you add IP devices, such as a network printer. (This is why various ISPs don't seek to get into this part of the business.)

There are also routing-level issues here that you'll (also) have to deal with if you choose this approach, mixing static (public) addresses and IP addresses from one of the private ranges.

Liu's book -- and it's not a small book, it's a whole lot of detail and a whole lot of reading -- will certainly help you through a DNS configuration. If you choose to head that way.

Again, a little help from a DNS-savvy consultant can save you a whole lot in getting your network set up.