It's no exaggeration to say that DNS resolution without DNSSEC is not trustworthy. DNSSEC requires that authoritative DNS servers sign their responses and prove that they own the zone by handing out digital certificates and digitally signed records.
Windows Server 2008 R2 (and Windows Vista and later clients) had DNSSEC capabilities, but they did not interoperate well with non-Microsoft platforms. Since every DNS server in the chain of a resolution request must be running interoperable DNSSEC, and most of the Internet does not run Microsoft DNS or DNSSEC, this was a problem. Windows Server 2012 solves it, not only making DNSSEC interoperable (supporting the latest RFCs and crypto), but also significantly easier to configure.
To put it bluntly, configuring DNSSEC in Windows Server 2008 R2 was a nightmare! It required superlong command-prompt commands, only worked with static zones, and required re-signing anytime a record was updated. Now DNSSEC is GUI-rich and Active Directory integrated, with automated re-signing. DNSSEC is so significantly updated and easy to use that I expect most enterprises to be enabling it along with their first few Windows Server 2012 DNS servers. There's no reason not to now.
Documents can be automatically classified according to their contents or Active Directory attributes. These classifications can then be used in conjunction with other Windows Server 2012 features that are now classification-aware. For example, the Rights Management Service can automatically encrypt documents that contain certain content or classifications. You can even automatically control which users and groups can access which documents based upon content or classification. This is neat stuff, and it's all built-in.
Dynamic Access Controls and Expression-Based Authorization Rules
Windows Server 2012 features very advanced file and folder permissions, especially in the form of Dynamic Access Controls, Claims, Expression-Based Access Control Entries, and Centralized Authorization and Auditing Rules (known as Central Access Policies).
First, nearly any object -- such as a user, group, computer, and so on -- can have or be given one or more attributes known as claims. Claims are something you either are ("I'm a Dell laptop with MAC address of 00-aa-00-62-c2-06") or any attribute associated or assigned to an object ("a manager in the finance group working from home"). These claims can then be used for authentication and authorization.
For example, only finance users working from home on Microsoft Surface Pro or iMac devices can use the private VPN and access the finance SharePoint server, and within it, only documents with "medium" or lower data classification. Perhaps finance documents with a "high" data classification require users to be onsite using domain-joined and controlled computers. Security decisions support Boolean logic. Compare that to the pre-Windows Server 2012 method where you could only define security decisions based upon the user account and their group memberships.
Kerberos has proven itself to be a robust and secure authentication protocol. Windows Server 2012 improves it for simpler use. Not only does Kerberos support claims and cross-forest (and cloud) authentication, but DCs automatically do group compression and the maximum Kerberos ticket size has been increased to 48KB. Prior to Windows Server 2012, it was easy for users belonging to more than a 100 groups to create something called token bloat, which caused authorization problems. Kerberos Constrained Delegation has been improved to work across domains and forests. Prior to Windows Server 2012, constrained delegation required the front- and back-end servers to be in the same domain. Lastly, Kerberos now supports RFC 6113, otherwise known as Kerberos armoring. Essentially, a protected channel is created between domain-joined clients and the domain controller to protect pre-authentication data, which makes Kerberos even harder to hack.