Hi Gustav,
To address each of your problems:
- I don't want 0/0 distributed from the hubs, that traffic should go out NAT:ed via the local ISP
That's fine - your static default routes at each branch will override anything that OSPF advertises to you. Just make sure you have a static host route to the VPN head-end IPs to ensure you don't accidently advertise something more specific that tears down the tunnel.
- I need more specific routes than the single 192.168/16 from the hubs to the spokes since I want traffic to each domain controller/dns to go the shortest/direct path.
This will be default behaviour if you configure area 1 as a NSSA. Just make sure you don't override this behaviour with the default-metric or no-summaries statements.
- The branch-generated aggregate for the /22 from each branch won't get distributed unless area 0.0.0.1 is either nssa or "normal" area.
Correct - you want an NSSA though because the aggregate will be considered external (i'm assuming you mean you've created a route with protocol aggregate here)
- I don't ever want routes in/from area 0.0.0.0 to be routed via area 0.0.0.1 (I though this was implied when you used different areas but realize that's not the case).
Intra-area routes should be preferred over Inter-Area, but you'll just need to watch your branch aggregates (because they will be External) and which ABR gets used to reach them (eg: DC2 might go via DC1 to get to a branch in certain situations)
- Using area-range at the hub give's undesired results; the /24's from area 0.0.0.1 are installed in the routing table at the hub and the /22 is redistributed in area 0.0.0.0, this however gives an inconsistent view on routers in area 0.0.0.0. So route aggregation at the branch is, just as you pointed out, what I want to go with.
Yes - which is why an NSSA with external aggregates will solve this for you.
Good luck!