We've been considering utilizing a third-party recursive DNS provider like OpenDNS (or anyone) to provide a layer of antiphishing and DNSSEC validation (without having to implement those features internally).
To allow internal (Windows domain) DNS to function normally, are these recursive DNS providers typically configured as DNS forwarders in the Windows DNS service?
Are there any other best practices or considerations when outsourcing recursive DNS?
To answer your first question in a word, "yes".
To answer your second, best practices questions are usually very subjective and don't lend themselves well to the Stack Exchange format. The rule of thumb is that there should be an answer, and it should be the right answer, rather than a pool of opinions that you're trying to draw from.
That said, there are two significant caveats to what you are doing, and they are significant enough to where I think it's worth taking a stab at it.
Until validating stub resolvers become more widespread in implementation by OS vendors, a reply packet with the AD (authenticated data) bit set is basically saying this:
"I trusted this data, so you can also trust this data! ...If you trust me, and the network between us."
Read that very carefully. If your goal is to "[avoid] having to implement those features internally", make sure you understand what you're getting out of DNSSEC. Most people don't. It means that you're more resilient to attacks against the remote recursive DNS server, but you're still completely open to poisoning attacks directed against your infrastructure. The probability of someone specifically targeting you is much lower of course, but assuming that you are not the target only scales as well as how much you have to lose and someone's interest in it.
These risks are significantly reduced if the network path between you and the recursive server performing validation does not cross the internet. That's mutually exclusive to outsourcing it though, shy of the traffic itself actually being encrypted.
Side note: OpenDNS does implement dnscrypt if you're interested in leveraging it, but to go that route you'd have to determine that the level of complexity in implementing and supporting it vs. just performing your own DNSSEC validation is worth the cost:benefit ratio.
This is a universal rule to business IT environments. It should be no surprise that it also applies here. If you're introducing an external dependency to your network infrastructure, what happens when that service goes down? What is your remediation path? Who is going to pay for the damages? If the service is working from the perspective of others but is broken in a narrow way that only impacts your environment, how fast can you expect the remote party to take your opinion seriously and perform a repair (SLA)?
If you're going to create this kind of dependency, make sure you're paying for the service in some way. You are always giving up something by adding an external dependency to your network without a subscription of some sort, and the choice to not do so is weighing your odds on the gamble.
I'm a DNS operator for an American MSO. That said, people like me don't really stand to benefit financially from you following this advice. Migrating away from your ISP's DNS cluster is less load on what we manage.
Configure DNS root hints, it reduces your administration and provides better availability on external DNS queries
for Interval queries DNS forwarders works fine
