I believe that the ASA will not do dynamic DNS lookup. I gather from my reading that it has static DNS lookup: that is, that at the time it parses the ACL that it'll do a DNS resolution and lock that IP in. But I'm not certain of that; the PIX that it is derived from had no DNS resolution at all.
Yes, you would add statements to the ACL being applied as the crypto-map match-address. The ACLs should use the addresses as they appear
*after* any translation takes place. The most common case is that you have the traffic defined in a nat (inside) 0 access-list ACLNAME which tells the PIX not to use translation for that flow; in that case, the IPs you would use in the crypto ACLs would be the "internal" IPs.
The source IP for the crypto map ACL should be the internal network; the destination should be the remote network.
For example (sorry, the ACLs are in old format as that's what I know)
Assuming a new local server 192.168.1.17 and a new remote server
192.168.99.158 and that the local network is 192.168.1/24 and that the remote network is 192.168.99/24
!then to the bottom of VPN2Albany add access-list VPN2Albany permit ip host 192.168.1.17 192.168.99.0 255.255.255.0 access-list VPN2Albany permit ip 192.168.1.0 255.255.255.0 host 192.168.99.158
If you end up with the access-lists NoNat and VPN2Albany looking identical except for the names, then do NOT try to use the same ACL in both places; if the software doesn't outright block that, it will lead to some subtle bugs.
If you need the case where it is not allowed to use the internal network addresses over the VPN, then let me know and I'll post an example.
Walter thanks for the help so I understood all of what you mentioned as well as now knowing about how the DNS "should" work out. So I should the IP address of these servers and yes i understood and have the NONAT ACL.
So I should not need the fqdn of this server at all because I dont even look at their dns nor is it publicly published.
I think i'm ready to implement this.. Thanks for your help..