There are really two ways to go about deciding what you want to name your domain. You just need to remember that for all intents and purposes you can't change your domain name without starting from scratch. Yes there are ways to rename a domain, but they are dangerous, and can be a little tricky to do right.
Theoretically you can name your domain whatever you like as long as it conforms to (and someone correctly if i'm remembering wrong) RFC1035. However, there are etiquette considerations such as not using a valid domain you don't own (essentially .com, .net, ccTLD based domains, etc) internally. For example using microsoft.com for your internal domain would be bad form as well as making it all but impossible to get to anything hosted by microsoft. The two most common standards are to use either:
a) a subdomain of a domain you own - as an example I would use ad.brokenhaze.com or internal.brokenhaze.com (or anything similar) because i'm the owner of brokenhaze.com
b) $something.local, to use your "testad.com" example if you changed it to "testad.local" you would be perfectly fine. The .local suffix is generally excepted as an internal suffix as well as used by most of the zero-conf protocols.
To answer your comment on MarkM's answer. During AD installation, if it is a new domain it will force you to install DNS, as well as setup all of the records required by AD to work properly. Then you would point your client machine's DNS server to - using your example - 10.0.11.1 (in other words the IP of the DC that is hosting DNS). AD is HIGHLY dependant on DNS so your clients really need to be pointed to an internal server that is hosting the correct DNS records (In smaller installations these are normally the DC(s) )
Also besides reading up on AD, you should really also read up on LDAP - as that is the backbone of AD and all major, modern Central Authentication systems.