How do domain controllers work in server 2003

Is there a context for the information you're after?  Are we talking about more then one DC in different sites?

Having more the one domain controller in a single site has two basic benefits; the first is that because they both keep a copy of the domain information if you lose one you do not lose all your domain information and can recover very easily, the users shouldn't even notice the missing server unless it is doing more then just being a DC.  The second benefit is load balancing; every time you log on to your PC or access a network resource you will be authenticating with a domain controller, this is not a problem on small sites but if you have 2-300 users that one server will become over-loaded.  When you have more then one DC (Domain Controller) they will share the authentication burden in a round-robin approach.
So the more DCs the better the redundancy and performance (assuming sufficient load).

The DCs will talk to each other on an almost constant basis to make sure they both have a full copy of your domain information, this is know as replication.  You can add a new user on any DC and it will shortly be available on all DCs.

Without getting into too much detail all DCs in a domain are essentially equal, there is no primary/master (ignoring FSMO roles which can be ignored for now) role.

Essentially all Domain Controllers in Server 2000, 2003 and 2008 are equal to each other. Information is replicated between each server as per the replication topologies between the servers.

There are then 5 FSMO Operating Roles, which are specific roles which can only be present on one Domain Controller at a time. In Active Directory, there are certain procedures and systems which can only be run by one Domain Controller at a time - if they are run by multiple DCs, there is the possibility of conflicts occurring. If we take the Schema Master role as an example; the server which holds the Schema Master role is the ONLY DC in the domain which can be used to extend the Active Directory schema, and changes are then replicated down to other DCs which hold a read-only version of the schema. This applies similarly to the other FSMO roles, too.

The other role is the Global Catalog which maintains universal group membership across all domains in the forest. This is used at login time to ensure a user has privileges to login, among other things.

All of this is brought together in a special part of the domain's DNS, which keeps track of the DCs and GCs and various other things. DNS is a critical part of Active Directory.

-tigermatt

It is generally a good idea - unless you have a specific reason to do so - to have all Domain Controllers running DNS. You can then ensure that all your DNS zones are Active Directory-integrated, meaning they replicate automatically between DCs without the need for zone transfers. See http://support.microsoft.com/kb/814591 and then http://support.microsoft.com/kb/198437.

Once DNS is on all the servers and you are seeing the same records in both servers' DNS consoles (so you know replication has occurred), then you should set each DC so that its DNS server is itself. Don't use the localhost 127.0.0.1 IP, but the server's full network internal IP address. To suppress certain DNS errors in the event log when one DC is started, I always add at least one other DC as an alternate DNS server, although this isn't mandatory.

>> What if the roles are split between the 2.
By "roles", I am assuming you mean the FSMO roles, as opposed to roles such as DNS, DHCP, file and print server etc. If FSMO roles are split between DCs and one DC goes down for a period of time, it shouldn't cause too many problems, provided it isn't for an extended period. For example, if the DC holding the Schema Master role isn't available, it just means you can't extend the Active Directory schema. The PDC Emulator role will be missed, particularly if you have legacy operating systems on the network (98, NT etc.), but the network CAN survive without this server for a period of time.

If you know a server will be offline for an extended period, it would be a good idea to perform a graceful TRANSFER of FSMO roles to another DC. If a server is taken offline unexpectedly, and you know it will not be going back online, then you will have to SEIZE the FSMO roles to another server, and then perform a metadata cleanup to remove traces of the offline DC from Active Directory. You must never seize the FSMO roles if the offline DC will be coming back online in its previous state, because that will cause problems (two servers will think they hold the same FSMO role...)

-tigermatt

Yes the additional DCs will compensate, you just need to make sure you've considered all the possible outcomes of one of the DCs going offline.  For instance as tigermatt said you should have DNS running on all your DCs and make sure your clients have at least a primary and secondary DNS setting to point them to two or more DCs.  If you have clients pointing to only one DC and it goes down they will pretty much lose server access anyway.
WINS is another service that you should have more then one server doing and replicating, and of course have at least primary and secondary set on clients.
DHCP is another service.  If this is setup on one DC and it goes down some clients will not get IPs and lose network access.  To mitigate this you should at least install and configure DHCP on a second server so if the primary DHCP server goes down you can just start the service on the second, or you can split your DHCP scope of addresses and have both DHCP server running and issues addresses but in different ranges.  eg. DHCP-Server-1 issues address 192.168.1.1-192.168.1.127 while DHCP-Server-2 issues addresses 192.168.1.128-192.168.1.254.
Obviously then you need to consider print services and files shares (DFS can help here).

So yes Active Directory is very resilient when you start adding additional domain controllers, but there are some key services that AD and clients rely on that simply adding more DCs will not help with.

I'd also suggest that you make all of your DCs global catalog servers. Here's how and why :

http://technet2.microsoft.com/windowsserver/en/library/440e44ab-ea05-4bd8-a68c-12cf8fb1af501033.mspx?mfr=true

Personally, I don't implement DHCP on DCs when I can do differently. For this service, which is absolutely not CPU greedy, I use old boxes with a reduced Linux kernel and it works fine, but any windows server will do.

HTH
Cheers