Yes AG support multiple subnets as described here. Also make sure that your data provider supports MultiSubnetFailover .. .NET Framework 4 supports it.
To answer your question ...
IF you use .NET framework 4 or 3.5 then the provider will support it as described here.
Also, a good reference to SQL Server Multi-Subnet Clustering is well documented.
With legacy client libraries or third party data providers, you cannot use the MultiSubnetFailover parameter in your connection string. To help ensure that your client application works optimally with multi-subnet FCI in SQL Server 2012, try to adjust the connection timeout in the client connection string by 21 seconds for each additional IP address. This ensures that the client’s reconnection attempt does not timeout before it is able to cycle through all IP addresses in your multi-subnet FCI.
Elijah. There's two separate questions here:
1. Is DTC supported with AlwaysOn Availability Groups?
You're using SQL Server 2012, and according to Microsoft's Documentation, that answer is no. I totally understand that you want to try it anyway, but keep in mind that you're now putting something into production that Microsoft simply will not support, AND you're using two separate niche features together (AGs and DTC). If anything whatsoever goes wrong, you're going to be in a world of hurt. This just isn't something I'd ever even think about trying in production.
Keep in mind that if your managers find out that you deployed something Microsoft specifically says in big letters, "YOU CAN'T DO THIS," and you have any kind of outage where you have to call Microsoft for support, you're going to have some ugly explaining to do.
Technically, DTC is supported starting with SQL Server 2016 SP2 and later, but it just means that you can pick which database loses data on failover, and the application has no idea data was permanently lost. That's not what a normal database administrator would call DTC support.
2. How should DTC be configured in a multi-node, multi-subnet cluster?
Read Allan Hirt's post on configuring DTC with multiple instances of SQL Server in a cluster, and make sure to read all of the links in the post as well.
Best Answer
Shared or replicated disks, yes. This is because the Disks "move" between servers. Each potential failover target has SQL Server installed locally and the service is started when the local node owns the resources and is given the online command. The local service starts and mounts the database files which are on the shared or replicated disks. This is why you don't need to change or replicate any SQL Server based items (logins, jobs, etc.).
Failover of the Availability Group (not an individual database like Database Mirroring) will happen when the health checks either timeout, fail, or the lease fails to be obtained or renewed. When and under what circumstances is entirely dependent upon the flexible failover policy chosen and the type of issue the instance encounters.
In all of those cases it is entirely dependent upon the configuration of the availability group. If you're set for automatic failover (synchronous commit + synchronized databases + automatic failover set) then in all of those situation the availability group should fail over.
Entirely your choice. To make administration easier, I'd just use default instances.
Only objects at the database level will be replicated as part of the log stream. System databases cannot currently be put in availability groups. Thus, any server level object or objects not contained in the user databases will need to be replicated. Examples include: Logins, Jobs, Server Level Certificates, Proxies, Server Level Configurations, Linked Server Definitions, Security Audits, etc.