Stupidly naive, but I gotta ask it, because I don’t know the answer. And I should.
OK, I’m the IT person for a smallish company; I’m self-taught on just about everything, so there are occasional yawning gaps in my expertise; most of what I’ve done so far has been oriented around setting up/administering workstations & hardware, developing software, designing and administering databases, with a bit of peer networking and internet stuff thrown in.
I’m determined to exand my expertise on networking and servers - trouble is that there seem to be a few things that everybody just knows - I guess you must learn them really early on - it’s hard enough even to find out how to ask about it - because everybody just takes it all for granted.
OK, today it’s domains. I’ve sent myself on a couple of Linux server courses and they were great - I really understood about 95% of it and I’m quite happy pottering around with Linux now; a bit iffy on installing extra software on it, but that will come. I’ve set up a test server (actually running SME server, which is a very customised/simplified distribution of Linux specifically designed to act as a web/file server and gateway) and I’m playing with it. But I’m not exactly sure what it means when I have to define the primary domain for the server.
Please don’t laugh.
OK, we’ve registered a internet domain name and we’re paying an ISP to host it etc (for simplicity, let’s call this mangetout.com), I want my mail server to collect (or perhaps receive) emails from this ISP and distribute them/make available to clients on the LAN. Lets say those clients are jim@mangetout.com and jill@mangetout.com. Do I have to define the primary domain of my server as mangetout.com? On the one hand, this seems to be how it wants to manage the users in terms of email, but on the other hand, it seems wrong - my server isn’t actually hosting that domain in the same sense that my ISP is hosting for mangetout.com.
I don’t want to have the DNS point to my static IP and host everything myself - I’m quite happy using an ISP right now.
OK, when you’re done marvelling at my ignorance, please put me out of my misery; what does ‘domain’ mean in the context of an intranet?
You can use anything you want as your internal domain name. For simplicity, you might want to use something that won’t exist on the Internet to avoid possible confusion. mangetout.lan or mangetout.local, for instance (I use apartment.local at home).
It’s not that simple. jim@mangetout.com is not a client. It is merely an account on a mail server that a mail client can access. The computer running that mail client program could have the name jim.mangetout.com but that is not exactly the same thing. I would recommend the O’Reilly book DNS and Bind for a comprehensive explanation of how domains work.
Trying to implement DNS without a comprehensive understanding of it is not a good idea. Read the book; you’ll be a better IT administrator for it. Trust me.
Forgive me if I’m telling you stuff you already know. But what do you mean when you say an ISP is hosting your domain name?
First there is the registrar. A company like Network Solutions or gandi.net. They maintain a database that contains your domain name (mangetout.com) and the IP addresses of one or more DNS servers for your domain.
Some computer has to host your DNS records. You have a primary DNS server, where changes to your DNS records are made. You can, and should have secondary servers that just hold copies of the DNS records . The most frequently accessed DNS records are an entry for a machine called “www”, and a mail server (MX) record for you e-mail server.
Probably your ISP hosting your DNS records, your web site, and both an incoming email server (an MTA) and a e-mail message store. Probably on different machines.
For one domain I manage the registrar is hosting the DNS records, and one of my machines hosts www and e-mail. For another, our DSL provider is hosting the DNS, and we’re hosting the web and e-mail services ourselves.
So one approach would be to aim your domain’s MX record at your static IP, while keeping all non-email hosting (DNS, web) on the ISP’s machine. In this case your machine should be named whatever.magnetout.com. It really is a machine (or an alias for one) on the internet just as much as boards.straightdope.com is, and its gotta have a name.
If you’re having an ISP’s server hold mail in a store-and-forward configuration, you could name it whatever you want since it doesn’t need a public name. But again, you might as well name it whatever.magnetout.com. Naming it “boards.straightdope.com” for example could very well cause problems. Better to pick something you know is unique and you have control over - i.e. a machine with your own registered domain name. And you never know, someday you may want to change your configuration and want a publicly usable name.
Well, there’s actually part of the problem - a general confusion over exactly what ISP hosting/registration etc actually does - I know how to ask them to set up what I need. I know how to interact with it once it’s done, but I don’t really know how it works. It’s probably worth mentioning that this is a UK domain, which I understand works a little differently from some other TLDs.
The parts of your post following the above question were very informative, thanks.
Probably not a worthwhile option for us - we’re geogrpahically right on the outer fringe of the broadband reach/radius for our exchange - as a result, bandwidth is limited and sometimes patchy (other connectivity options have been investigated, but are not workable at present); having our ISP queue incoming mails works quite well for us.
This is what I assumed you were trying to do; feel free to correct me. Your hosting company has a mail server that collects up all emails directed to *@mangetout.com (or whatever your real domain name is). You want to set up a server on your local network. You want this local server to periodically connect to your hosting company’s mail server and pull down all your emails to your local server (probably through POP) and sort them into appropriate mailboxes on your local server. You then want your local workstation clients to connect to the local mailboxes on the local server, rather than the hosting server, to download email.
In this case, the domain name of the local box is irrelevant. No one on the public internet will ever be trying to connect to this box; the only people that will connect to this box are local users. You can name it whatever you want. You would then configure all your email clients to access the local box appropriately. For instance, if your hosting company assigns your mail server a fully qualified name of pop.mangetout.com, but on your local LAN the IP of your local box is 192.168.1.2, you would change all the mail clients to point to 192.168.1.2 instead of pop.mangetout.com as the incoming mail server. If you want to be able to enter a name for your local server in the mail clients instead of the IP address, say mail.mangetout.local, then you need to properly configure a local DNS server on your LAN that would map the IP address to the fully qualified name and would also be capable of mapping real world IPs to real world domain names (www.google.com, www.straightdope.com, etc…) See sewalk’s book recommendation.
If the local server needs to be able to serve up email both to users on the LAN and to remote users, then it’s a different story since now your local box must be publicly accessible over the Internet.
That’s pretty much the picture; we actually do all that at the moment, but on a network without a domain - the mail server is just a named machine in the workgroup - it was also the web proxy server until a couple of weeks ago when I installed a router instead
The LAN was previously set up with static local IP addresses and I used to point the client machines at the IP address of the mail server, but the router does DHCP, so it’s all dynamic by host name now.
When I build the new mail server (whcih will be Linux - the old one was… wait for it… Win98!), I’m not quite sure whether change everything again to domain membership, rather than workgroup, and what that might entail - looks like I can do it either way (although the server still wants to know what the local domain is, even if nobody else cares).
I think you are confusing DNS domains with Microsoft Active Directory/Windows NT domains. They’re not the same. If you wanted to a have a AD/NT domain, you’d either have to have a Microsoft server, or a Linux server pretending to be one via samba. The primary advantage of this is unified authentication - an account is created once at the server and anyone can log in as themselves to any workstation.
Assuming you mean the Windows domain, not DNS: a domain, like a workgroup, binds a bunch of computers together under a common group name. Unlike a workgroup, you select one computer to be in charge of the domain (the Primary Domain Controller), authorizing and keeping track of the computers therein.
With a domain, users can log in using their account on the PDC, instead of on their workstations, which is good for a couple things:
[ul]
[li]Common user authentication. You can set up a file share on your computer (or any other PC in the domain) and set the permissions so that only certain users can access it, and they’ll be able to do it no matter which workstation they’re sitting at. With a workgroup, you’d have to create an account for each user on each file server and maintain the separate accounts and passwords.[/li][li]Roaming profiles. You can log in on any workstation in the domain and see the same desktop, registry, My Documents, Start menu, etc. Your settings are copied from the PDC to the workstation when you log in, and from the workstation to the PDC when you log out. This way, you can keep everyone’s profiles backed up just by backing up your PDC’s hard drive.[/li][/ul]
However, for these features to work, you need to be running Windows NT/2k/XP on all the computers in the domain. 95/98/ME don’t play well with domains.