PIX 515E ver 7.2 and VPN peers

A 'name' command can use periods in the name, so a 'name' can

I have not been following PIX 7 closely, so there might be a new feature that I have missed, but in PIX 6 there is no way to have DNS lookup done on entered names, not even at the time the name is first entered into the configuration. In order to do something like that, you would need to be able to configure a DNS server to refer to; as best I recall, PIX 7 does not offer that (PIX 6 definitely does not.)

To use FQDN in configurations, you also need well-defined rules about when the address associated with the FQDN will be re-inspected.

Simple "look it up at need" rules do not work, because given a DNS facility, people would expect to be able to use FQDN in ACLs. Every random port-scanning machine, known upon contact only by IP address, -might- be a match for any FQDN, so you can expect that nearly every FQDN in ACLs will need expansion often. But DNS entries change much more often then firewalls get rebooted...

There are semantic issues to deal with if you use a FQDN as a crypto peer. If the IP address associated with the FQDN changes, what should happen to any active tunnel? You might say, "well, only look up the IP address when the tunnel gets triggered", but on an active tunnel, because of automatic renewal, the next trigger might not be until the next reboot (or next network failure). So you might want to impart semantics about checking the IP when a SA (Security Association) lifetime is expiring, but what do you do if the old tunnel is working perfectly and you cannot contact the new IP or cannot authenticate to it? Then too, a SA is a IKE Phase 2 entity but choice of peer is really an IKE Phase 1 matter, so you should deal at Phase 1 renewal instead of at the SA level... which still has questionable semantics re: if the new IP does not work.

You can have multiple crypto peer IP addresses, with fallback semantics well defined. Does that mean that if you get multiple A records back from the DNS lookup, that you should treat all the IPs as if they had been listed as crypto peers? If so, then in what order, considering that DNS servers often randomize the order (in order to distribute load)? If you got one order before and a different order now when it is time for a Phase 1 renewal, then which IP should be renewed against? What additional features need to be added to be able to deduce an ordering preference, since not all of the IP addresses will necessarily be reachable (or optimal) through the interface the crypto map is applied to?