Ronnie is spot on, depends greatly on the need. Typically we define the DNS servers by Group Policies based on site (or even OU.. so depends on the AD structure too). Also DHCP servers setting the appropriate settings (also either per DHCP server or by policy that applies to set them on DHCP servers the policy applies to). At least this is true for internal clients, at any rate.
For the assignment of DNS servers you often develop an internal strategy for this and build it out. For example, faced with this problem I might do something like set up site level group policy, incidentally often shunned by tribal IT knowledge because issues can become very difficult to detect if you do a poor job with policy. With that said however, say I have a site in the USA and a site in the UK. I may have appropriately named sites in AD Sites & Services. I can go there and create a policy which will apply DNS servers to all the clients based on being members of that; however it ties hand in hand with making sure your network team -- assuming that isn't also you -- is providing you the nitty gritty about all new subnets, because you have to add them to sites and services so that clients know where they are when they are making requests.
Large companies -- meaning like your examples, i.e. global entities -- also often use GSLB, while I call this 'global site load balancing' i am not sure that's what it really stands for as an acronym, to route requests based on origination point. For example, if you access google from the USA you typically get 'google.com' as a response, where if you access from an IP range that is considered from Brazil, for example, you will most likely get redirected to their www.google.com.br site by the load balancing devices.
Does that help?
